I'm attempting my first NuGet package, and I'm running into some trouble. I have a fairly simple project, and a very simple .nuspec file:
<?xml version="1.0"?>
<package >
<metadata>
<id>$id$</id>
<version>$version$</version>
<title>$title$</title>
<authors>$author$</authors>
<owners>$author$</owners>
<description>$description$</description>
</metadata>
</package>
When I run NuGet pack with this command line:
NuGet.exe pack mylibrary.csproj -Verbosity detailed -Properties Configuration=Debug
I get this error:
NuGet.CommandLineException: Unable to find '#(_OutputPathItem->'%(FullPath)mylibrary.dll')'. Make sure the project has been built.
at NuGet.Commands.ProjectFactory.BuildProject()
at NuGet.Commands.ProjectFactory.CreateBuilder(String basePath)
at NuGet.Commands.PackCommand.BuildFromProjectFile(String path)
at NuGet.Commands.PackCommand.BuildPackage(String path)
at NuGet.Commands.PackCommand.ExecuteCommand()
at NuGet.Commands.Command.Execute()
at NuGet.Program.Main(String[] args)
The output files are definitely in the bin\Debug folder, but NuGet is apparently not finding them.
This apparently only happens when the .csproj file's ToolsVersion is set to 3.5 or lower. Setting ToolsVersion to 4.0 resolves the problem.
It seems that MSBuild 3.5 returns the unexpanded property value when calling _project.GetPropertyValue("TargetPath") (ProjectFactory.cs ~296), where MSBuild 4.0 returns the expanded property value.
We had the same problem. adding
-Prop Platform=AnyCPU
to the command line made it work for us.
This apparently only happens when the .csproj file's ToolsVersion is set to 3.5 or lower. Setting ToolsVersion to 4.0 resolves the problem.
I have created an issue for the NuGet project team here: https://nuget.codeplex.com/workitem/4012
This could also have the same error if the .NET Framework version is set to 4.0 for the assembly.
Related
I have following after_build definitions in my appveyor.yml:
after_build:
- cmd: nuget pack "%project_file%" -properties "Configuration=%configuration%" -version "%GitVersion_NuGetVersion%" -symbols
- cmd: nuget pack "%extras_project_file%" -properties "Configuration=%configuration%" -version "%GitVersion_NuGetVersion%" -symbols
Now, I have those two .proj-files, which contain a corresponding .nuspec-file:
<?xml version="1.0"?>
<package >
<metadata>
<id>$id$</id>
<version>$version$</version>
<authors>$author$</authors>
</metadata>
</package>
Finally, I have a little addition for the extras_project_file:
<?xml version="1.0"?>
<package >
<metadata>
<id>$id$</id>
<version>$version$</version>
<authors>$author$</authors>
<dependencies>
<dependency id="***project_name***" version="$version$" />
</dependencies>
</metadata>
</package>
Actually, project_name is replaced with a hardcoded value for simplicity reasons - no injection with -properties yet. Secondly, any project related elements, such as description and authors, have been omitted to provide a neutral question, despite being mandatory for the actual packing.
project_file is packed succesfully:
Attempting to build package from 'Caliburn.Micro.Contrib.Controller.csproj'.
MSBuild auto-detection: using msbuild version '14.0' from 'C:\Program Files (x86)\MSBuild\14.0\bin'.
Packing files from 'C:\projects\dotnet-caliburn-micro-contrib-controller\src\Caliburn.Micro.Contrib.Controller\bin\Release'.
Using 'Caliburn.Micro.Contrib.Controller.nuspec' for metadata.
Found packages.config. Using packages listed as dependencies
Successfully created package 'C:\projects\dotnet-caliburn-micro-contrib-controller\Caliburn.Micro.Contrib.Controller.0.1.0-unstable0068.nupkg'.
Whereas extras_project_file fails:
Attempting to build package from 'Caliburn.Micro.Contrib.Controller.Extras.csproj'.
MSBuild auto-detection: using msbuild version '14.0' from 'C:\Program Files (x86)\MSBuild\14.0\bin'.
Packing files from 'C:\projects\dotnet-caliburn-micro-contrib-controller\src\Caliburn.Micro.Contrib.Controller.Extras\bin\Release'.
Using 'Caliburn.Micro.Contrib.Controller.Extras.nuspec' for metadata.
Found packages.config. Using packages listed as dependencies
Versions using SemVer 2.0.0 are not supported: 0.1.0-unstable.68+Branch.develop.Sha.7f85e35f315f7fe3ecd35762b65802e5467a57c2.
I am not even sure that this feature (token replacement in <dependencies>) is actually available.
If not, how else can I package two .csproj-files into two separate .nupkg-files, where one has a dependency on the other one with a specific version (same version as the package to build)?
I have found a way for this scenario - but it misses %AssemblyInformationalVersion% being stamped into the final .dll-file as an attribute (so I'll need to inspect the GitVersionInformation-class for the actual value).
I added assembly-informational-format: '{LegacySemVerPadded}' to GitVersion.yml.
Next, I removed the additional dependencies-element in .nuspec, so both match again (=reset).
Finally, I adapted my after_build:
after_build:
cmd: nuget pack "%project_file%" -properties "Configuration=%configuration%" -symbols
cmd: nuget pack "%extras_project_file%" -properties "Configuration=%configuration%" -IncludeReferencedProjects -symbols
During an automated build, my nuget package needs to be non framework dependent, however I keep finding that the nuget package getting added is incorrectly adding a HintPath.
Within my nuspec I've defined the files that are part of the package:
<files>
<file src="lib\xyz.dll" target="lib\xyz.dll" />
<file src="lib\xyz.xml" target="lib\xyz.xml" />
</files>
However whenever I add the package to my project/solution, it incorrectly adds a hint path specifying:
<Reference Include="xyz, Version=11.0.0.0, Culture=neutral, PublicKeyToken=4a3c0a4c668b48b4">
<HintPath>..\packages\xyz.11.0.0.0\xyz.dll</HintPath>
<Private>True</Private>
</Reference>
This is causing the automated build server to not find the assembly and fail to build. I can manually fix the hint path, but would rather not.
I took a look at this post (Failed to add NuGet package) but I don't find it relevant. This post (NuGet package install uses specific assembly version in csproj files) seemed to be referring to the same problem but with no answer. Anybody have any thoughts?
You can work around this by using a custom MSBuild task.
Instead of adding the assembly to the lib directory create an MSBuild .targets file named after the package id and put your xyz assembly next to it.
\build
\Net45
\MyPackage.targets
\xyz.dll
\xyz.xml
Then in the MSBuild .targets file add the reference exactly how you want it to be. Something like:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup>
<Reference Include="xyz">
<HintPath>$(MSBuildThisFileDirectory)\xyz.dll</HintPath>
</Reference>
</ItemGroup>
</Project>
The above shows how to specify a hint path relative to the MSBuild .targets file. You said that you do want to use a hint path so you could remove that if xyz.dll can be resolved by MSBuild somehow, such as it being in the GAC.
I cannot get nuget pack X.csproj to recognize package dependencies in a project. Amazingly, when packaging, the diagnostic message “Found packages.config. Using packages listed as dependencies” is printed, but in the end the <dependencies/> tag in the .nuspec file inside the package is empty.
The packages.config for the project does indeed contain references:
<packages>
<package id="SmartAction.Logger" version="1.0.2.0" targetFramework="net40" />
<package id="SmartAction.Pervasive" version="1.0.1.0" targetFramework="net40" />
</packages>
To narrow the problem down, I removed my own parallel .nuspec file, and mostly all switches from the nuget pack command:
> nuget pack libToneDetection.csproj -prop Configuration=Release
MSBuild auto-detection: using msbuild version '14.0' from 'C:\Program Files (x86)\MSBuild\14.0\bin'.
Attempting to build package from 'libToneDetection.csproj'.
Packing files from '[snip]\Core\ToneDetection\libToneDetection\bin\Release'.
Found packages.config. Using packages listed as dependencies
Successfully created package '[snip]\Core\ToneDetection\libToneDetection\SmartAction.Audio.ToneDetection.1.0.0.0.nupkg'.
NuGet Version: 3.3.0.212
The only difference I can spot with this project is that its name is different from package name (I am trying to maintain them in sync but this is older stuff I am repackaging).
I doubt I had ever seen this before. I am finding questions on SO from people trying to prevent references in packages.config from becoming dependencies of the package, but none from those trying, like me, to beat the reverse problem. Help!
Addendum. I copied the project out of the solution with other projects to a temporary directory and rebuilt the package from there. Now one of the two dependencies from packages.config was added to the package:
<dependencies>
<dependency id="SmartAction.Logger" version="1.0.2.0" />
</dependencies>
Thinking of the differences between the two, the SmartAction.Logger package depends on SmartAction.Pervasive. But the package I am compiling really uses both.
To me, either behavior looks incorrect. Am I hitting a nuget bug, or a cryptic complex feature?
Xref: Opened https://github.com/NuGet/Home/issues/1867
I am currently creating a nuget package with a nuspec file but getting the following error:
An item with the same key has already been added.
My command I am using is:
nuget pack "MyProject.csproj" -o "..\Packages"
This is my nuspec file:
<?xml version="1.0"?>
<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
<metadata>
<id>$id$</id>
<version>$version$</version>
<title>$title$</title>
<authors>$author$</authors>
<owners>$author$</owners>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>$description$</description>
<language>$language$</language>
</metadata>
<files>
<file src="bin\MyLibrary*.dll" target="lib\net45" />
</files>
</package>
The nuspec file I am using is also used when packaging other packages withing the same library. Could this be the reason why the above error is occurring? Any ideas?
It might be that you are adding files in nuspec that are also getting added when you call pack on the .csproj (files/dlls referenced by the csproj). If so you can remove the file references from the nuspec file and give it a try.
how does your nuspec file look like?
I created it with the following steps
1. create the Mylibrary project
2. let me add a dependency, I installed ninject package to the project
3. build
4. nuget spec mylibrary.csproj
5. nuspec file generated, I didn't add any file or dependency manually to the file
6. nuget pack mylibrary.csproj
7. nuget pack would automatically add ninject as a dependency and also add mylibrary.dll into the correct folder
8. http://npe.codeplex.com/ is a nice tool to open the nupkg file and see what got generated inside the package.
I had this error trying to use the package visualizer and it ended up that my packages.config had the same package name in it more than once with different versions.
Is there some way to make a NuGet package using code compiled in release mode? Or is there some reason I should only publish (make available locally, in this case) packages compiled in debug mode?
Every time I call nuget pack from my project directory, where I have the nuspec file below, on code I have only compiled in release mode, it complains about not finding the DLL in the debug folder ("\bin\Debug\SomeProject.dll"). If I compile it in debug mode, those files are there and it packs them up as it should.
<?xml version="1.0"?>
<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
<metadata>
<id>$id$</id>
<version>$version$</version>
<authors>$author$</authors>
<owners>$author$</owners>
<iconUrl>http://somewhere/project.png</iconUrl>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>$description$</description>
</metadata>
</package>
You can solve it like this:
NuGet.exe pack Foo.csproj -Prop Configuration=Release
(reference)
If you are using a post-build event and you want to create a package whether using Debug or Release configuration you can setup the post-build event commandline like so:
"<path to nuget tools>\NuGet.exe" pack "$(ProjectPath)" -Prop Configuration=$(ConfigurationName)
To have NuGet automatically use Release mode when you run nuget pack, do the following:
Open your .csproj file in a text editor.
Find the following line:
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
In this line, replace Debug with Release.
Save changes.
The answers here are good, but I was having a lot of problems with this for a .NET Standard project. I had a project that was only going to publish Release binaries, but it wasn't respecting my default build output path.
I added this to my CSProj which then enabled me to use the accepted answer here.
<PropertyGroup Condition="'$(Configuration)' == 'Release'">
<OutputPath>$(SolutionDir)bin\$(PlatformTarget)\Release</OutputPath>
</PropertyGroup>
Chiming in here.
My build profile would build the DLLs to bin\<arch>\Debug|Release.
I was able to point to my folders by running the nuget command as follows:
Notice how I used the -p option.
PS > nuget pack -p Configuration="x64\Release"
Attempting to build package from ...
...
Found packages.config. Using packages listed as dependencies
...
- Add a dependency group for .NETFramework4.7.2 to the nuspec
Successfully created package...