Hi. I need some help with a problem I run into randomly. I will get the following error sometimes…
,
30>MSBUILD : OctoPack error OCTONUGET: Can not access a closed Stream. [C:\MyProject\Web.csproj]
30>MSBUILD : OctoPack error OCT-1805672349: There was an error calling NuGet. Please see the output above for more details. Command line: ‘C:\MyProject\packages\OctoPack.3.0.31\tools\NuGet.exe’ pack C:\MyProject\obj\octopacking\Web.nuspec" -NoPackageAnalysis -BasePath C:\MyProject" -OutputDirectory C:\MyProject\obj\octopacked" -Version 1.0.4377 [C:\MyProject\Web.csproj]
30>MSBUILD : OctoPack error OCT-1805672349: System.Exception: There was an error calling NuGet. Please see the output above for more details. Command line: ‘C:\MyProject\packages\OctoPack.3.0.31\tools\NuGet.exe’ pack C:\MyProject\obj\octopacking\Web.nuspec" -NoPackageAnalysis -BasePath C:\MyProject" -OutputDirectory C:\MyProject\obj\octopacked" -Version 1.0.4377 [C:\MyProject\Web.csproj]
MSBUILD : OctoPack error OCT-1805672349: at OctoPack.Tasks.CreateOctoPackPackage.RunNuGet(String specFilePath, String octopacking, String octopacked, String projectDirectory) in y:\work\46cfb6001f03d701\source\OctoPack.Tasks\CreateOctoPackPackage.cs:line 520 [C:\MyProject\Web.csproj]
MSBUILD : OctoPack error OCT-1805672349: at OctoPack.Tasks.CreateOctoPackPackage.Execute() in y:\work\46cfb6001f03d701\source\OctoPack.Tasks\CreateOctoPackPackage.cs:line 189 [C:\MyProject\Web.csproj]
,
I should point out that I use ProGet as my NuGet server. If I retry MSBuild, usually it goes away but it seems to happen once every few builds. Is this a more of a problem with Octopus not closing a stream or ProGet not opening the stream in time? If it is an Octopus problem, is there a workaround (besides retrying the build until it works) or a fix?
Thanks for getting in touch! Sorry for the delay in getting back to you. From what we can see with the error we believe the part that the error is coming from is between Nuget.exe and ProGet. The stream we believe it is referring to is when NuGet tries to move the package to the folder. I wonder if you changed from OctoPackPublishPackageToFileShare to OctoPackPublishPackageToHttp and see if it makes a difference at all.
We also have this problem. It happens quite often. We don’t use ProGet.
I see this problem when I build from command line with OctoPackPublishPackageToFileShare.
Update: I also get this when I run without the OctoPackPublishPackageToFileShare property and just plain RunOctoPack. I’ve a situation now where one project fails almost every time. To me this looks like a NuGet.exe issue
Another update: Our build contains a lot of solutions. Some of these are top level applications that are packaged with OctoPack. To speed up the build process we build these in parallel. Works fine, except for OctoPack. In our case this seem to be what is causing the “Can not access a closed Stream” issue in NuGet/OctoPack. If I change the build to run everything in sequence then it always works. Running in parallel with runoctopack=true fails very often with “Can not access a closed Stream”. Running the build in parallel with runoctopack=false also work fine, but that is not what we want.
We use TFS 2013 Build server and I have the same issue as Jan.
We have one solution with multiple projects and we do OctoPackPublishPackageToHttp. I suspect tht this is a Nuget issue.
How do I pack and publish using Octo.exe and Nuget? I think we will have to do it this way in a post build script…
I have created an issue in GitHub to investigate that you can track here: https://github.com/OctopusDeploy/Issues/issues/1684
We will see if we can figure out if its only NuGet or Octopack or if there is a workaround that can be used.
Hi all,
Is this only happening through TFS Build Server? I have manually run OctoPack via the command line with multiple large packages. I’m setting the OctoPackPublishPackageToFileShare parameter as specified by @Jan and so far been unable to reproduce when running in multiple command windows. By the sounds of things this is a NuGet.exe issue but until we can reproduce it will be difficult to make an effective fix.
Thanks for your feedback.
Cheers,
Rob
This happens from command line(and GUI) with a build using FinalBuilder. FinalBuilder makes it easy to run for parts of the build in parallel.
I believe I also observed the same problem when I experimented with parallel builds using powershell and Invoke.Build.
This looks like a race condition in nuget.exe to me. It does not happen the same place every time, but in a build producing 40+ nuget packages it happens almost every time.
Jan,
Are you able to reproduce with just Nuget.exe in a command line? If we can isolate and reproduce the specific scenario we might be able to work around it. I have been manually calling
and so far been unable to get the Can not access a closed Stream error.
When you run it manually and can see the NuGet.exe output, does it appear to happen during the nupkg creation or when it gets published, in this case to a file share?
Cheers,
Rob
Hi All,
Thanks for the detailed logs.
This definitely appears to be something fishy going on within NuGet itself. If I just run the NuGet.exe pack command across several completely different packages in parallel then I get the Cannot Access A Closed Stream error.
I have added these details to a Git Hub Issue on the NuGet repository
I will take a look at the NuGet source itself to see if there is anything obvious that I’m missing but it looks like there is something going on in NuGet which will need to be sorted for this issue to go away.
Will keep an eye on the ticket with the NuGet team and update this thread accordingly.
Sorry for the bad news guys,
Cheers,
Rob
Sweet! In the meantime, since this seems to be a problem when running several nuget pack commands in parallell, Is there a workaround when calling OctoPack to make it run the nuget pack commands sequentially? Like a parameter…?
I mean I would rather have a OctoPack command running slow but succesfully than having our gated-checkins fail because Nuget cant handle multi threading.
Hi jonas,
At the moment we would advise the standard work around to be to just run the offending builds in sequence. As this is a failure in NuGet’s library we are trying to get the fix on their side working first. Please comment on the ticket that has been raised on their queue (https://github.com/NuGet/NuGet.CommandLine/issues/18) to ensure its importance is brought to their attention.
Hopefully you are able to get your builds working again. Let us know if you have any further difficulties with this.
Cheers,
Rob
Ok, I just checked the logs and it seems that the build is done with MultiProc= True so I added the msbuild parameter /m:1 and so far we have not seen any failed build due to “can not access closed stream”.
I’m going to try that parameter out. We’ve since upgraded to TFS 2015 and the problem seems to be even more frequent now, with a single build taking 3 or 4 tries to succeed.
