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).
Related
I am building a netstandard2.0, with a series of sub-dependencies, including Azure.Data.Tables. I have found that Azure.Data.Tables on >=12.3.0 is not compatible with 2.2 projects, but version 12.0.0 is (or at least it doesn't crash my .Net Core 2.2 application).
Based on these premises the resolution was simple: put version 12.0.0 in the netstandard library dependencies. There's only one problem, that when I install this library using Visual Studio into my Net Core 2.2 project I get that visual studio decides to install 12.3.0.
I have checked documentation around enforcing certain versions using the allowed wildcards(https://learn.microsoft.com/en-us/nuget/concepts/package-versioning#version-ranges-and-wildcards), such as:
<PackageReference Include="Azure.Data.Tables" Version="[12.0.0]" />
Which produces this package description just before pressing "install".
But it doens't seem to work, Visual Studio simply carries on with the 12.3.0 installation.
It turns out Visual Studio was just using the nuget cache for my locally generated packages. If I either changed the version of the packaged package then the sub-dependencies would change. As well, another way of getting the precise package would be to clear nuget's cache locally: nuget locals all -clear.
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.
We have a number of .NET Framework projects with a "nuget pack MyProject.csproj" command in the post-build step. We have been using VS2010 (:O I know) until now, and it has been happily spitting out nupkg files.
We recently updated our build tools to the 2019 version (running the new version of varsall.bat before calling msbuild), and the "nuget pack" command now fails:
Error NU5012: Unable to find 'MyProject.dll'. Make sure the project has been built.
What I've tried:
Adding a "nuget spec" step before packing
Upgrading the nuget CLI executable to the latest version
Updating from packages.config to PackageReferences
This allows you to use MSBuild -t:pack. However, two issues:
When running this in the post-build step on my machine, it starts dozens of cmd & MSBuild processes and pegs my CPU.
Our developers are stuck on VS2017 for now, but the 2017 build tools are no longer available for our build server (so we use 2019). The 2017 & 2019 installs put MSBuild in different locations. We could set path variables for all the machines, but that seems brittle.
I'm playing with upgrading one of the projects to the new csproj format, but it is rather involved. Upgrading all of our projects will be an effort all its own, and I'm still exploring the ramifications.
Is there something simple I'm missing which will allow this to work without large modifications?
Error NU5012: Unable to find 'MyProject.dll'. Make sure the project
has been built.
This message indicates that the nuget.exe can't find the output assembly. So you must make sure the assembly is created successfully.
And one point you need to take care, normally we use command like nuget pack foo.csproj -Properties Configuration=Release to pack the assembly built in release mode. If you use command like nuget pack xx.csproj in post-build-event, no matter which configuration you use msbuild to build the project, nuget will always try to find the assembly in ProjectDir/bin/debug.
So when you deploy the project to remote server without bin and obj folders, if you try to use command like msbuild xx.csproj /p:Configuration=Release, the build is in release mode while nuget.exe will search the bin\debug instead of expected bin\release. You should check if you're in same situation.
Why does NuGet pack break with VS2019 build tools?
This issue is not about the build tools package. Since the error message you got came from nuget. Msbuild just help call the nuget.exe, and the cause of the issue is nuget.exe can't find the needed assembly by one specific path. Please check if the path in the error message is right, and then check if the assembly is in that path.
I also ran into the same issue during our TFS upgrade to Azure Devops. The new Nuget task doesn't have the switch for -Build. The fields in the Nuget task screen for Pack also doesn't allow you to add this switch, that's why it's complaining about not finding the dll or the output of the build. I modified the nugetpack.js file on the agent's task folder to test the theory and now the pack options build successfully.
This is the line I added to the js file (towards the bottom of the page):
nugetTool.arg("-Build");
what would be nice is to have this option represented as check box to cover if there is use case to call Nuget pack without -Build switch
I've been having an adventure with the new u-sql msbuild support, fighting dragons etc in the lands of "preview build".
I realised many of the gotchas were due to discovering inconsistencies between running the build in VS2017 v.s. running msbuild from the command line.
Against my better judgement I added some diagnostic messages by altering the nuget download directly:
\packages\Microsoft.Azure.DataLake.USQL.SDK.1.3.1019-preview\build\runtime\USqlSDKBuild.targets
I realise now that USQLSDKPath doesn't override what version is used in visual studio.
And that USQLTargetType* isn't supported within visual studio at the time of writing.
*USQLTargetType is needed if you want to compile scripts without checking for pre-existing schema objects, to avoid a chicken and egg scenario.
The versions I've found on my machine are:
C:\Users[user name]\AppData\Roaming\Microsoft\DataLake\MsBuild\1.0\
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\Extensions\Microsoft\ADL Tools\2.3.3000.5\
And the one installed via nuget relative to my sln.
Can I assume the first in AppData is installed as part of the Visual Studio installation and the second is the visual studio extension from the marketplace?
I've been battling for a few days on various elements so wondered how far others have got in this direction? I also realise this is in preview mode, so has rough edges.
Am I safe to alter:
<Import Project="UsqlSDKBuild.targets" Condition="'$(BuildingInsideVisualStudio)' != 'true' And Exists('UsqlSDKBuild.targets')" />
<Import Project="$(USQLSDKPath)\UsqlSDKBuild.targets" Condition="'$(BuildingInsideVisualStudio)' != 'true' And !Exists('UsqlSDKBuild.targets') And '$(USQLSDKPath)' != '' And Exists('$(USQLSDKPath)\UsqlSDKBuild.targets')" />
<!-- backward compatible with IDE build -->
<Import Project="$(AppData)\Microsoft\DataLake\MsBuild\1.0\Usql.targets" Condition="'$(BuildingInsideVisualStudio)' == 'true'" />
To force using a later version in the IDE as well?
Forcing Visual Studio to use the nuget downloaded USQL SDK doesn't seem viable at the moment.
Even if I deleted all statements at the bottom of the usqlproject and tweaked USqlSDKBuild.targets to allow the project to be loaded without error (I had problems with the UsingTask)....
I discovered that Visual Studio was overriding the USQLSDKPath back to:
USQLSDKPath='C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\Extensions\Microsoft\ADL Tools\2.3.3000.5\U-SQLSDK'
Meaning I'm unable to use the nuget version reliably.
In that same directory I did notice "USqlDBProject.targets" (what sounds like the new upcoming project type) and that USqlSDKBuild.targets has more options. Both indicating that the nuget package is infact older than the extension's SDK.
I'm considering that infact the one bundled with the Visual Studio extension is infact newer than the nuget version!
EDIT
After semi concluding there are different versions at play, I went back to basics and - doh - realised that the nuget package is out of date!
I made this mistake because the u-sql project doesn't support the nuget in Visual Studio so I needed to add it by hand to the packages.config, hardcoding it to "Microsoft.Azure.DataLake.USQL.SDK.1.3.1019-preview" as mentioned in https://blogs.msdn.microsoft.com/azuredatalake/2017/10/24/continuous-integration-made-easy-with-msbuild-support-for-u-sql-preview/
I wrongly assumed the the blog post was up to date, due to it being linked to within the relatively recently promoted spring 2018 release notes. But double checking the blog post obviously pre-dates the release notes. My bad for coding tired.
I have an asp.net core project, which was working great few day earlier. I have it on github in a private repo. Yesterday it stopped working after installing an update from VS. I have searched all over the net and github, can't find any solution to this. The image of warning i am getting is attached. The warning description is as follows from Microsoft,
NU1603
Issue A package dependency specified a version that could not be found. A
higher version was used instead, which differs from what the package was
authored against.
This means that restore did not find the best match. Each restore will float
downwards trying to find a lower version that can be used. This means that
restore goes online to check all sources each time instead of using the
packages that already exist in the user package folder.
Common causes The package sources do not contain the expected lower bound
version. If the package expected has not been released then this may be a
package authoring error.
Example message NuGet.Packaging 4.0.0 depends on NuGet.Versioning (>= 4.0.0)
but 4.0.0 was not found. An approximate best match of 5.0.0 was resolved.
I don't know how can i solve this ? it seems there is no solution out there, I have even reinstalled VS, cleared nuget cache, deleted packages from global folder but my solution isn't working.
Any help in regard will be highly appreciated.
I guess you have NuGet 4.3 with VS 2017 15.3.
The coded NuGet warnings and errors are part of the 15.3 release which is basically the NuGet.exe 4.3 release.
Basically you have 2 options to solve this issue:
Fixing the dependency tree by manually updating System.ComponentModel.TypeConverter package with version 4.1.0 or higher
Use NoWarn to ignore/suppress this warning like described here, by editing you csproj file like below.
<PackageReference Include="Castle.Core" Version="4.0.0">
<NoWarn>NU1603</NoWarn>
</PackageReference>
i know this old ticket and i was getting the same issue. However the accepted answer did not solve in my case. so what i did was:
Close Visual Studio
Delete all "bin" and "obj" folders for all projects
Delete all Castle.* folder in the C:\Users[user acc].nuget\packages\Castle.*
Open Visual Studio, Clean Solution, and then Rebuild
If you want to suppress these warnings for all package references in a given project, add/modify your *.csproj to include NU1603 under the PropertyGroup tag for each target you want to suppress it under.
Here is an example:
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
<NoWarn>1701;1702;1705;NU1603</NoWarn>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
<NoWarn>1701;1702;1705;NU1603</NoWarn>
</PropertyGroup>
As mentioned by #user2771704 this is documented here.