For some reason in the nuspec file a single file from the is added.
File name : "C:\windows\assembly\GAC\stdole\7.0.3300.0__b03f5f7f11d50a3a\stdole.dll"
We don’t need it on deploy and because of this file the build fails with the following message:
Any ideas how to avoid it ?
Target path 'C:\windows\assembly\GAC\stdole\7.0.3300.0__b03f5f7f11d50a3a\stdole.dll' contains invalid characters.
There was an error calling NuGet. Please see the output above for more details. Command line: 'D:\B\130\3504\Sources\EQ\packages\OctoPack.3.0.31\tools\NuGet.exe' pack "D:\B\130\3504\Sources\EQ\Site\obj\octopacking\Site.nuspec" -NoPackageAnalysis -BasePath "D:\B\130\3504\Sources\EQ\Site" -OutputDirectory "D:\B\130\3504\Sources\EQ\Site\obj\octopacked" -Version 188.8.131.52
System.Exception: There was an error calling NuGet. Please see the output above for more details. Command line: 'D:\B\130\3504\Sources\EQ\packages\OctoPack.3.0.31\tools\NuGet.exe' pack "D:\B\130\3504\Sources\EQ\Site\obj\octopacking\Site.nuspec" -NoPackageAnalysis -BasePath "D:\B\130\3504\Sources\EQ\Site" -OutputDirectory "D:\B\130\3504\Sources\EQ\Site\obj\octopacked" -Version 184.108.40.206
at OctoPack.Tasks.CreateOctoPackPackage.RunNuGet(String specFilePath, String octopacking, String octopacked, String projectDirectory) in y:\work\46cfb6001f03d701\source\OctoPack.Tasks\CreateOctoPackPackage.cs:line 520
at OctoPack.Tasks.CreateOctoPackPackage.Execute() in y:\work\46cfb6001f03d701\source\OctoPack.Tasks\CreateOctoPackPackage.cs:line 181
Thanks for getting in touch! As very general advice you can define exclusions for files included in a NuGet package as part of your NuSpec file.
Such as the following:
<file src="tools\**\*.*" exclude="**\stdole.dll" />
I could offer something more specific if you would like to provide a copy of your NuSpec and the output from your build, this will allow me to help tailor a specific solution for you.
Let me know how this goes!
David, any luck solving your issue with the GAC assembly? I am having some similar issues with some Office GAC assemblies.
Did you use a files element like mentioned in Vanessa’s reply?
Yes it did helped
But the logic for the exclude file enforce me to declare which files I want to include…
This is imo wrong.
I agree. I am trying to properly determine the command line parameters for either msbuild or nuget (whichever is appropriate) to exclude COMReference references that point to Office assemblies in the GAC.
I really do not want to fall back to the files element and have to begin manual maintenance of dependencies.
Hi Jesse and David,
This may help (it may not!) but when you define the files tag in your NuSpec, you then also have to include everything in the files tag, but not with OctoPack.
If you see the following documentation page - it gives an example of defining the files tag for inclusion or exclusion, but then also defining a variable to pack up all the other build files.
So it allows you to use the files tag sparingly, and pack everything else as well.
Update: We changed our GAC assemblies to Copy Local and added them to a “lib” folder within our solution and reference from there. This was for MS Office GAC assemblies. Works great, of course. You may or may not be able to do this for your situation.
I’m having a similar problem. I’ve upgraded to OctoPack 3.0.42 and OctoPack started packaging files from the GAC, in my case:
49> OctoPack: Add binary files to the bin folder
49> OctoPack: Added file: bin\WINDOWS\assembly\GAC_MSIL\Microsoft.Vbe.Interop\220.127.116.11__71e9bce111e9429c\Microsoft.Vbe.Interop.dll
I don’t have any files listed in my .nuspec and I’m letting OctoPack decide what to package for my website. It doesn’t matter if I reference this DLL or not, and if it’s in Libraries or not, and if it’s set to CopyLocal or not. I am referencing Microsoft.Office.Interop.Excel.dll from my Libraries folder though.
Why would OctoPack be packaging this file?
Hi David. Once we moved to locally referenced Office assemblies, not just setting Copy Local, but actually extracting the needed assemblies from the GAC, then referencing them from a “lib” directory that is added to source, but not added to a project, we stopped having issues.
Once the Office DLLs are normal references, Octopack will include them in the package as any other.
It’s not 100% ideal, but it works just fine and we are sticking with it.