1
Vote

File path too long for deployments

description

The file paths generated at build when attempting to publish are longer than 248 / 260 characters. This makes it a pain to build and deploy the module.
Ideally, the module directory should be something like Lombiq.AppInsights and then all the files in the lib dir should be stored in the root or in folders with shorter names.

comments

Piedone wrote May 5, 2015 at 1:26 PM

Which files/directories specifically cause issues? Because we had the same problem, that's why the longest ones where shortened. It's really sad that this medieval issue is still preventing us from using appropriate folder names.

dcinzona wrote May 5, 2015 at 1:55 PM

"Medieval issue" describes it perfectly.

The longer directory names in the libs folder cause problems. I also renamed the root to Lombiq.AppInsights and change the binary DLL name to match (as well as the project name).

The folders in the Libs folders are:
Microsoft.ApplicationInsights.Log4NetAppender
Microsoft.ApplicationInsights.RuntimeTelemetry
Microsoft.Diagnostics.Tracing.EventSource.Redist

The issue is that they have a bunch of sub-directories with long file name DLLs as well. I'm not sure why these affect the deployment process... maybe the project is set to copy all files in the project folder?

dcinzona wrote May 5, 2015 at 3:05 PM

So, this could be happening because the Orchard.Web project in the solution is set to copy all files in this project folder. That will include the Libs folder in the App Insights module. This could be what is initiating that.

Would it be possible to convert the Libs into Nuget packages, so that those libs are, instead, stored in the "packages" directory and not copied with the module?

Piedone wrote May 5, 2015 at 11:58 PM

Using packages would be possible but it was a conscious choice not to leverage NuGet so even without NuGet (or build) support it will work (think about installing the module from a package via the admin).

I'll take a look into shortening those folder names. Do you know where are the limits? I.e. how much it needs to be shaved down?

dcinzona wrote May 6, 2015 at 11:03 AM

I've had success with renaming the application project root directory and the output DLL (and making sure the project source was on the root of the drive. If you are running the project source out of your user documents folder, which is where VS puts new solutions by default, you'll run into problems.

I think your issue about installing the module via the admin portal brings up an interesting problem. Perhaps there needs to be support via the admin package installer for scenarios like this. I'm not sure how to go about making sure it pulls the libraries from a trusted location like NuGet, but it would be interesting if that were possible (i.e. download and install the package via the admin portal and during this process, binary libraries required from NuGet are also downloaded and stored in the bin directory).

I know you want to keep the libs directory organized, but maybe only include the DLLs required for the project to run and store all of them in the root of the libs directory folder? It would reduce package size as well. Since they all get copied to the bin directory anyway (and then from there to the app_data dependencies), they will all have unique file names.

Then just add instructions prompting users on how to update those files directly if they want to (this would only apply when building the module from source, obviously).

Piedone wrote May 6, 2015 at 7:39 PM

I'll take a look into this.

Piedone wrote May 16, 2015 at 11:47 PM

I've shortened library paths. Does it help?