Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Publishing failure due to package path name being too long #790

Closed
pekkah opened this issue Aug 3, 2015 · 8 comments
Closed

Publishing failure due to package path name being too long #790

pekkah opened this issue Aug 3, 2015 · 8 comments

Comments

@pekkah
Copy link

pekkah commented Aug 3, 2015

I'm trying to publish a dnx cmd application as azure web job by copying the output to the correct location under my web project. This was working in beta4 but after upgrading to beta6 I'm getting following exception with the Visual Studio Online build script.

Sarcasm 'I thought ONLY npm has long path names for modules'

Adding NuGet package C:\Users\buildguest\.dnx\packages\Microsoft.Framework.Configuration.EnvironmentVariables\1.0.0-beta6\Microsoft.Framework.Configuration.EnvironmentVariables.1.0.0-beta6.nupkg to C:\a\3504c0ed\staging\out\release\Web.UI\wwwroot\App_Data\jobs\continuous\FactoryEventProcessor\approot\packages
System.ArgumentException: The name can be no more than 260 characters in length.
at System.Threading.Semaphore..ctor(Int32 initialCount, Int32 maximumCount, String name, Boolean& createdNew, SemaphoreSecurity semaphoreSecurity)
at System.Threading.Semaphore..ctor(Int32 initialCount, Int32 maximumCount, String name, Boolean& createdNew)
at Microsoft.Framework.Runtime.Internal.ConcurrencyUtilities.<ExecuteWithFileLocked>d__2`1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.Framework.PackageManager.NuGetPackageUtils.<InstallFromStream>d__0.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.Framework.PackageManager.Packages.AddCommand.<Execute>d__1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.Framework.PackageManager.Publish.PublishPackage.Emit(PublishRoot root)
at Microsoft.Framework.PackageManager.Publish.PublishRoot.Emit()
at Microsoft.Framework.PackageManager.Publish.PublishManager.Publish()
at Microsoft.Framework.PackageManager.PublishConsoleCommand.<>c__DisplayClass0_0.<Register>b__1()
at Microsoft.Framework.Runtime.Common.CommandLine.CommandLineApplication.Execute(String[] args)
at Microsoft.Framework.PackageManager.Program.Main(String[] args)
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at Microsoft.Framework.Runtime.Common.EntryPointExecutor.Execute(Assembly assembly, String[] args, IServiceProvider serviceProvider)
at dnx.host.Bootstrapper.RunAsync(List`1 args, IRuntimeEnvironment env, FrameworkName targetFramework)
at dnx.host.RuntimeBootstrapper.ExecuteAsync(String[] args, FrameworkName targetFramework)
at dnx.host.RuntimeBootstrapper.Execute(String[] args, FrameworkName targetFramework)
@stajs
Copy link

stajs commented Oct 6, 2015

I'm hitting that exception from a slightly different angle; not in Azure or Visual Studio Online but just from dnu publish. However, do they both use MsBuild under the covers?

dotnet/msbuild#53

@YEVHENO
Copy link

YEVHENO commented Oct 14, 2015

I'm trying execute following command line: "%userprofile%.dnx\runtimes\dnx-coreclr-win-x64.1.0.0-beta7\bin\dnu.cmd publish src\myproject --runtime %userprofile%.dnx\runtimes\dnx-coreclr-win-x64.1.0.0-beta7" and getting same exception: System.ArgumentException: The name can be no more than 260 characters in length. If I move source file to directory with short name like "C:\Temp", works as expected. This is beta7.

@mqueirozcorreia
Copy link

To solve that problem in aspnet 4.5 you could change the *.pubxml file adding IntermediateOutputPath (http://stackoverflow.com/questions/19411136/website-publish-failing-due-to-file-path-being-too-long).

The same solution doesn't work for aspnet 5 RC1. I'll still look for a solution or workaround to keep using visual studio ide.

@mqueirozcorreia
Copy link

I have just found the solution for aspnet5.
You can edit the publish file (*.pubxml) and add this tag:

<PublishTempFolderName>pubtmp</PublishTempFolderName>

Solution reference:
microsoft/dotnet#234

@pellelauritsen
Copy link

pellelauritsen commented Nov 8, 2016

I still get this error in asp core 1.0.0, using .net 4.5.2

First publish is fine, but second time I get a bin-folder containing my views in a couple of directories down Release\Views.

If I publish yet again I get a new set inside so now the bin-folder structure is \bin\Release\bin\Release\Views. This goes on until VS cant build the project because of the above mentioned error!

Except that I get the bug from Microsoft.TypeScript.targets, even though I havent got a single ts-file in my project.

@derekpec
Copy link

derekpec commented Jun 7, 2017

@pellelauritsen I'm having the exact same problem that you have described. Did you find a workaround for this bug? Asp.net core 1.0.1 .net framework 4.5 (portable-net45+win8)

@pellelauritsen
Copy link

@derekpec I just publish to a Temp-directory, and then delete the folder every time before publish.

@derekpec
Copy link

derekpec commented Jun 7, 2017

@pellelauritsen Thanks for your response. I have found moderate success with that approach and I have to keep my fingers crossed each time! I think this may be a problem with MSBuild, so I filed dotnet/msbuild#2185.

@pekkah pekkah closed this as completed Jun 9, 2017
ryanbrandenburg pushed a commit that referenced this issue Nov 26, 2018
…master

[automated] Merge branch 'release/2.2' => 'master'
@ghost ghost locked as resolved and limited conversation to collaborators Dec 4, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants
@pekkah @stajs @pellelauritsen @mqueirozcorreia @YEVHENO @derekpec and others