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.
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.
I am trying to build Microsoft.AspnetCore.Identity from sources. The instructions are here: https://github.com/dotnet/aspnetcore/blob/master/docs/BuildFromSource.md. I am trying to run their command "restore.cmd" and hitting the following error:
error : Version 3.1.10 2 of the .NET Core SDK requires at least version 16.3.0 of MSBuild. The current available version of MSBuild is 16.0.46
1.62831. Change the .NET Core SDK specified in global.json to an older version that requires the MSBuild version currently available.
The error message's suggestion of changing the .Net Core SDK version seems absurd. Surely the solution is to install MSBuild 16.3.0. But how do I do that?
As an aside which may or may not be relevant, the instructions also have a script for installing the "exact required" version of VS. But it seems to install a new one that goes side-by-side with my existing version. Their "startvs" command then starts the existing one, rather than the new one. It has to be better to add everything needed to the existing installation. But I'm missing how to add MSBuild 16.3.0.
The error message's suggestion of changing the .Net Core SDK version
seems absurd. Surely the solution is to install MSBuild 16.3.0. But
how do I do that?
1) Please make sure that you have run ./eng/scripts/InstallVisualStudio.ps1 to install the required tools.
2) If you have VS2019, try to enable the option Use previews of the .NET Core SDK(require restart) under Tools--> Options-->Environment-->Preview Features.
a) If you have VS2019 at your agent, just update it to the latest version so that you will get the latest version about MSBuild.
b) Download the latest version of Build Tool for VS2019. You can download it under Tools for Visual Studio 2019 from this link. If you have already downloaded it, please update it to the latest version in vs installer. Also, make sure that you have install the workload Net Core build tools. After that, you can build net core projects with it.
3) Then try to run .\restore.cmd in developer command prompt.
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).
I am using teamcity for creating nuget packages that are being feed to a octopus deploy server. I ran into a problem regarding the dll versions that are installed as a nuget dependency, more precisely they are updated to the latest version instead of the specified version, even though in csproj, it checked the option specific version.
I don't know where it is the problem, on the local machine the build does not upgrade the dll, only on teamcity.
Is it msbuild related, or some set up to the nuget installer step, when I restore the nuget package.
Thanks in advance.