I have a simple .NetCoreApp 1.1 Class Library, currently open in Visual Studio 2017 15.2 (26430.13).
I'd like to create a NuGet package on build, and have configured the "Package" tab of my project settings; including the "Generate NuGet package on build".
On that tab I set the "Package id" and "Package version".
I see the Package id stored in the CSPROJ<PackageId> element.
However, I do not see the Package version being stored in the <PackageVersion> element.
The NuGet package gets built using the CSPROJ<PackageVersion> value; and the different value shown in the project properties "Package" tab is stored in some magical location I cannot find.
Is this a bug?
-John
The PackageVersion is defaulted to Version if it isn't set explicitly in the project itself, so editing Version alone will also set the resulting nuget package's version. In addition, Version - in contrast to PackageVersion - will also be used as a default for the autogenerated AssemblyInfo.cs so in many cases, you'd want to set Version anyway to affect both assembly metadata and the nuget's package version.
If you think that this behaviour is incorrect - especially when you define a custom PackageVersion in the project itself - this can be considered a bug, or a missing feature for the case when you set PackageVersion manually. You could open an issue on the project system's GitHub repo to discuss this behaviour.
Related
I want to package some tools as a nuget and am using the Microsoft.Build.NoTargets project SDK format to achieve the same.
As mentioned in the docs, NoTargets is used when the project file does not compile any assembly. However, it needs a TargetFramework property to be set.
msbuild fails with NETSDK1013 if I don't specify some TargetFramework property.
Why does msbuild mandate that TargetFramework be specified for the NoTargets SDK csproj?
Currently this is required for it to load in VS: VS checks if the project contains TargetFramework or TargetFrameworks in the xml to load sdk-based projects in the "new" project system (the thing that powers the IDE integration of the project). Otherwise it would use the legacy system that would not understand the features the SDK uses and either not load or give you a bad experience.
The MSBuild errors could be fixed in the SDK by defaulting the property but that will still fail IDE integrations.
Also note that the SDK imports other SDKs that are meant for .NET projects (language-independent over F#/C#/VB) and so you should get features like NuGet restore or packing working without much friction when a TargetFramework is set (even if it could be defaulted to whatever the SDK is basdded on in the NoTargets itself as mentioned)
having spent the better part of two days on this, time to get some help.
I am reworking our CI build, and have a VS2017 solution which was on .net 4.6.1, using packages.config style nuget refs, and TeamCity was using the NuGet runner v3.4.4 to restore the packages. It was originally build probably using VS2008 or 10, then converted to 2017 in 2018. Someone checked in the packages directory and it's been that way for years.
Time to bring it up to more modern standards. I converted the projects to use packageReference, and now am using msbuild and the restore;build target to restore my packages and build the solution. Works well EXCEPT for this one package.
Even in VisualStudio 2017 15.8.7, the build (which does the restore of course) is failing to restore the smtp-impostor package using a packageReference with the following error:
NU1202: Package smtp-impostor 2.0.8 is not compatible with net461 (.NETFramework,Version=v4.0). Package smtp-impostor 2.0.8 supports: netframework40 (.NetFramework 4.0,Version=v0.0)
I can't get Google to find a single useful post when searching for "netframework40".
If I use nuget3.4.4 CLI, it works fine (it seems to call msbuild 4.0). If I use nuget 5.6 CLI, I get the error message; it's using the msbuild that comes with Visual Studio 2017.
I see a lot of posts on how to get nuget to use a different version of msbuild, but I don't see how to tell msbuild to use an earlier version of nuget!
I have tried:
retargeting the solution to v4.0 - same error occurs - first part of error just changes to net40
setting the ToolsVersion in the csproj file tag to 14.0
Setting the PlatformToolsVersion property in the csproj file to 14.0.
No dice.
I really don't want to stay with packages.config for this project (and an extra CI build step) nor checkin the single DLL for the package into my repo. It's looking more like I'll jsut have to scrap the packageReference upgrade and stick with the old style nuget runner package restore.
Anyone ever seen this? Any ideas where "netframework40" comes from and why newer nuget can't match it with net40?
Thank you in Advance!
Newer versions of NuGet.exe can't resolve framework match when
restoring older packages (net40, netframework40)
The issue is that this nuget package smtp-impostor 2.0.8 is not compatible with the new PackageReference format and has nothing to do with Nuget V3.4.4 or Nuget V5.6.x.
Actually, the package was published on 2011 and the new package management format PackageReference was used since VS2017.
Besides, the author did not make any changes to the package to accommodate the new Packagereference. And I faced the same issue in my side.
Suggestion
As a workaround, you have to use packages.config to install this nuget package rather than PackageReference.
Since VS2017, VS adds the new PackageReference nuget management format and for your old VS2008, it uses Packages.config.
Or you could contains the author of the nuget package to change it.
I have been setting the package references in my .csproj files to accept any minor version of dependent NuGet packages (see NuGet Package Versioning reference examples). An example of this might be as per the below:
<!-- Accepts any 6.2.x version. -->
<PackageReference Include="ExamplePackage" Version="6.2.*" />
However, whilst this appears to work (i.e. the latest release version of 6.2.2 is restored), the NuGet package manager GUI built into Visual Studio appears to read the package reference as 6.2.0 and prompts me to upgrade to 6.2.2.
Performing a restore from the command line appears to download 6.2.2 but I cannot get the VS Package Manager to play ball.
Is there any way to get the VS Nuget Package Manager GUI to accept that 6.2.2 is what has actually been restored?
However, whilst this appears to work (i.e. the latest release version of 6.2.2 is restored), the NuGet package manager GUI built into Visual Studio appears to read the package reference as 6.2.0 and prompts me to upgrade to 6.2.2
This is a known issue about the PackageReference versioning with wildcard.
It seems use a wildcard * is the correct way for NuGet Restore to float to a higher version. However, the NuGet package manager GUI still takes the lowest version. The current workaround is update the nuget package to the latest version via NuGet package manager GUI, but this way will remove the wildcard *.
For tracking this NuGet issue, I recommend that you vote on and follow the earlier reported issue for updates and fix notifications:
https://github.com/NuGet/Home/issues/3788
Hope this helps.
In Visual Studio 2017, there is a new format for netstandard libraries that makes generating nupkg reasonably straight-forward. It looks like this:
In the csproj, it looks like this:
Is there a way of telling msbuild what the package version should be in such away that projects across the sln are updated simultaneously so that the nuspec ends up having the right version dependency? It is probably bug, but when I use msbuild /p:Configuration=Release /p:PackageVersion=3.1.7 and the original hand-typed version is 2.0.0. If I have an alpha and beta project, with beta dependent on alpha, I'll end up with
alpha-3.1.7.nupkg
beta-3.1.7.nupkg dependent on alpha-2.0.0
Perhaps the only way is regex substitution on the csproj, but it would be nice if I could avoid that.
Also, this PackageVersion method does not update the real version:
Currently, the versions are locked during restore and not during the build.
As a workaround, you can use
msbuild /restore /p:Version=1.2.3
(Recommended, requires MSBuild 15.5+)
or
msbuild /t:Restore;Pack /p:Version=1.2.3
(Version will also affect the generated assembly version, but you can use PackageVersion to only change the generated nupkg version).
See this GitHub issue for tracking the underlying NuGet issue (currently, the plan is that the dependency versions will be updated during the build in a future release).
Before Visual Studio 2015, it was trivial to setup your project to automatically generate NuGet packages. Specifically, you did:
Add a .nuspec file to your project
Enable NuGet Package Restore in the Solution right-click context menu
Edit the project .csproj file and set the build property <BuildPackage> to true
And that was it!
However, starting from VS 2015, MSBuild-integrated package restore has been removed and replaced by the new Automatic Package Restore. While these are all good news, it seems that setting the build property <BuildPackage> to true no longer triggers an automatic package build.
This is a major break of functionality! Is there a way to setup automatic builds of NuGet without using post-build events? Specifically, I'm looking for an MSBuild solution, as it forms the backbone of my build workflow.
Try OctoPack: https://www.nuget.org/packages/OctoPack/
Just add nuget package to your project.
If you want to build it every time you build release, add
to section <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|Whatever' ">
next line:
<RunOctoPack>true</RunOctoPack>
More information about finetuning can be found here: https://github.com/OctopusDeploy/OctoPack
There is a move to Class Library Packages in VS2015 which makes it incredibly easy to create NuGet packages. I've blogged about this before, but essentially it's just a few steps. Note that this is just a RC1 at the moment and not a stable release yet.
Install the ASP.NET and Web Tools 2015 (RC1 Update 1) update to VS2015.
Open VS2015 and create a new Class Library Package project.
Add your code to the library and configure the project.json file with any changes you may need. A default project.json file is used as an example.
Right-click on the project and select the Properties menu item. In the Build tab select “Produce outputs on build”. Build the project.
You’re done. Go to the artifacts folder in your project, in my case “artifacts\bin\AwesomeSoft.TextConverter\Debug”.
You should see the NuGet package already created, and the folders targeting each framework specified earlier.
There is another alternative called NuPack :
How-to-create-a-nuget-package-on-each-Visual-Studio-with-NuPack
It is a nuget package that automatically generate nuget package on build time.
VS4MAc already supports this and you can get it as a extension for VS on Windows
https://github.com/NuGet/NuGet.Build.Packaging