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.
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.
I'm trying to understand how the roll-forward mechanism with Microsoft.AspNetCore.App is supposed to work along with other nuget packages.
My understanding so far is that any time I publish my app, .netcore will automatically publish the app on the latest patched version that I have installed. This doesn't sound like a good practice to me. I think the application should be deployed on the .net version that it was developed on.
I recently ran into a problem where my build server has a newer SDK installed than I have on my development machine, so it tried to publish the app with a newer .netcore version.
This caused the build to break with the following error:
error NU1605: Detected package downgrade: Microsoft.EntityFrameworkCore.Design from 2.1.8 to 2.1.4. Reference the package directly from the project to select a different version.
I have explicitly specified that I want version 2.1.4 of Microsoft.EntityFrameworkCore.Design because that was the latest version that was available when I originally developed the application.
I feel like I'm missing something here. Am I supposed to make sure that I always
have the same SDK installed locally as the build server and that all of my apps are updated to the latest SDK every time I need to make a change? What if a co-worker wants to write a .netcore app targeting a newer version of the framework so they request that a new SDK be installed on the build server? Surely I shouldn't have to also update my app to the latest patch version.
You experienced the problem because when you reference the versionless Microsoft.AspNetCore.App you shouldn't reference packages which already are pulled in by the metapackage.
Because the metapackage already contains Microsoft.EntityFrameworkCore.Design and you specified a hard version you got a version conflict.
This usually happens when you have one project with the metapackage in another (for example test project) have a specified version. What happens then is that when building it will determine the highest version and use that but when it gets to the test project it will need to downgrade (because of the specified version) and will throw a build error. The recommended way until 3.0 is to add <Project Sdk="Microsoft.NET.Sdk.Web"> to the test project and also use the metapackage.
As far as I know it works like this: When you reference Microsoft.AspNetCore.App it will take the lowest possible version it can. So if for example your targetframework is netcoreapp2.1 then it will take 2.1.1. When it builds it will look what the highest possible version is of the shared framework you have installed for and use that. If you have the following runtimes installed: 2.2.0, 2.1.5, 2.1.12 it will roll forward to 2.1.12. There are some additional roll forward policies having to do with the minor (if its a preview version or not ect.) but those only happen when it can't find a runtime corresponding to the major and minor version.
See also: https://github.com/aspnet/AspNetCore/issues/3292 and https://github.com/aspnet/AspNetCore.Docs/issues/6430
I am not understanding why am I getting above mentioned error while loading some new pulled project from tfs. Even though I have Microsoft DNX folder in my explorer it asks me to install DNX SDK and when I install it fails.
I tried updating visual studio also but it didn't work.
Can anyone help me with this?
Since I use VS 2015, above mentioned issue resolved for me by downloading specific .Net Core version from https://go.microsoft.com/fwlink/?LinkID=827546 . It gives you DotNetCore.1.0.1-VS2015Tools.Preview2.0.3.exe
You can get other related .Net Core SDKs from https://www.microsoft.com/net/download/core
If you have VS 2017, you don't need to install .Net Core SDK explicitly. You get it by default in VS 17.
Cheers!
I have a Build server which has TFS 2010 Build Service installed. I have 2 Build Agents and 1 Controllers configured. One of our projects have been converted to Visual Studio 2012.
I found out that .NET framework 4.5 comes with new version of MSBuild which is version 4.5.
I installed .NET framework 4.5 on the Build Server because prior to installing it every time the project was built I kept getting the following error:
"Solution is of version '12.00' which is not currently supported".
After installing .NET 4.5, I still run into the same issue.
How could I go about resolving this?
Do I have to configure the Build Agent to use the new MSBuild 4.5 in order to build this particular project or do I set something in the projects solution file itself? If so how?
I would really appreciate if somebody could assist me with this please?
Try install vs2012 on the build server, while i don't believe it's strictly needed it's the easiest way to get all the requirements installed.
We have installed VS2012 on the build agent. Interestingly when I RDC to the build agent and then run msbuild from the command line everything works fine. So the issue looks like it happens before we even get to MSBuild.