We Keep Coding

Visual Studio 2019 - change .NET target framework to 4.8

I cannot change the .NET version of my project. I installed .NET 4.8 via the Visual studio installer and manually downloaded it separately. Neither of these works.
I actually tried to change the framework in the .csproj project file
<TargetFramework> net5.0-windows </TargetFramework>
to
<TargetFramework>net48</TargetFramework>
and it doesn't work too...
I'm running out of solutions and don't really know what to do next.

If you're attempting to convert an SDK-style "net5.0-windows" project to a "net48" WinForms one you'll likely need to do more than just change TargetFramework.
Firstly, the Project node at the start of the ".csproj" file should look like this:
<Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">
(A "net5.0" target doesn't need the .WindowsDesktop part of that.)
Secondly, you'll need to ensure that <UseWindowsForms>true</UseWindowsForms> is part of the main PropertyGroup.
Even after those changes you're still likely to get all sorts of issues if your project uses types that are not available in .net 4.8.

Issues with SDK version when importing C# project into Visual Studio

I have a visual studio project I am trying to import that is causing me issues. I am getting the following error message when I try and load the project:
error : The project file cannot be opened by the project system, because it is missing some critical imports or the referenced SDK cannot be found.
Detailed Information:
Unable to locate the .NET Core SDK. Check that it is installed and that the version specified in global.json (if any) matches the installed version.
So there are a few issues with this, number 1 being that there is no global.json file anywhere as far as I can tell nor is the project built using .NET Core (it's built with .NET framework 4.7.2). I have a .csproj file which I think might be causing the issues as it has the following lines:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net472</TargetFramework>
</PropertyGroup>
I have other projects where the .csproj file has no mention of the SDK version at all and so I tried to delete the SKD element entirely from the XML element however this did not work either.
I am using Visual Studio 2019 on Windows 7.
Has anyone encountered this issue before and can anyone explain how to rectify so that I can load the project into visual studio? Also is there a way to remove the SDK element so this wont happen if I try and move the project again?

Using Microsoft.AspNetCore.Hosting.WindowsServices with .Net Core 2.x

I'm trying to use a Windows Service to host a simple ASP.Net Core web app targeting .Net core 2.x, as detailed here by Microsoft.
This should be simple with the docs, but I'm getting nowhere because the Microsoft.AspNetCore.Hosting.WindowsServices package doesn't seem to work with any version of .Net Core (the NuGet page says it depends on .Net Standard). Simply opening a project will cause Visual Studio to get stuck at NuGet restore, without any error message whatsoever (I have to kill the VS process manually, as closing VS would cause it to stop responding). Running dotnet restore from command will cause cmd gets stuck at "Restoring packages for XXX".
The same thing happens with the sample code in ASP.Net official docs. I guess this must mean a machine- or platform-specific issue to me but I have tried with various (fresh) VMs and am out of ideas. The only thing that works so far is this answer here, i.e targeting .Net Framework and explicitly list all the package references rather than using Microsoft.AspNetCore.All.
I'm using VS2017 15.7.6. Any help on this issue would be greatly appreciated!
Update
The problem magically disappeared after I installed the Azure development workload in VS2017. I already had ASP.Net and .Net Core workloads before, so I really can't figure out which individual component did the trick, but it did solve the problem.

Yes, this answer is correct. The windows-service package only runs on windows. You have to directly target each package you need, because the Microsoft.AspNetCore.App (.NET-Core >= 2.1) and Microsoft.AspNetCore.All (.NET-Core >= 1.1 <= 2.0) packages, contain package(s) that target .NET-Core instead of .NET-Standard.
You could target both frame-works using
<TargetFrameworks>net471;netcoreapp2.1</TargetFrameworks>
and have conditional includes in your project file + compiler directives in your c# code.
<!-- CSPROJ CONDITIONAL REFERENCE -->
<PackageReference Include="Microsoft.AspNetCore.Hosting.WindowsServices" Version="2.1.1" Condition="'$(TargetFramework)' == 'net471'" />
// c#-code compiler directive
#if net471
using Microsoft.AspNetCore.Hosting.WindowsServices;
#endif
Keep in mind that using the full .NET-Framework will make you lose the performance improvements introduced with .NET-Core.
I am sure you could also have a batch script / windows task that starts your .NET-Core service each time your windows machine restarts.

I just had a similar problem. We have multiple Nuget package stores, and one of them was experiencing certificate issues.
I fixed it by doing the following:
Right-click on project Dependencies in Solution Explorer, and click Manage Nuget packages.
In the Package Manager, in the Installed tab, you should see the package, select the Microsoft.AspNetCore.Hosting.WindowsServices package. It will be showing a version 0 and some indication that it is failing to download.
You may also see the Package source in the top-right pointing to one of the custom Nuget stores. Change the Package Source to ALL. That will cause the window to refresh, and then you may see the correct version and an Update button.
Now click the Update button to update. My version is now 2.1.1.
Looking at the project file now, it changed the package reference to:
<PackageReference Include="Microsoft.AspNetCore.Hosting.WindowsServices" Version="2.1.1" />

ASP.NET Core 2.0 Upgrade - Broken NETStandardLibrary References

I recently upgraded our ASP.NET Core 1.1 application to 2.x. This project (and all other projects in the solution) now target the full 4.6.1 framework (previously targeted the full 4.5.2 framework). Visual Studio Version 15.5.7.
After doing so, all my class library projects in the same solution have a number of broken/yellow references to NETStandard.Library.2.0.2. Strangely, the solution still builds without issue and no pertinent warnings or errors are generated in the build output. All other references are fine including all references in the ASP.NET project (meaning that project does not have this problem).
Does anyone know what might be going on here?
Troubleshooting Steps
Clean Solution/Rebuild
NuGet Restore
Restart Visual Studio
Remove .suo/.vs/project.fragment.lock.json and restart
Suspend/Resume/Turn off R#
Manually remove and rebuild (works but they come back after NuGet restore)
Confirm the files it's looking for are actually available on the path...which they are sans the strange "double backslash" before ref:
Environment Details
Visual Studio: 15.5.7
Full Framework: 4.6.1
dotnet --info:
.NET Command Line Tools (2.1.4)
Product Information: Version: 2.1.4 Commit SHA-1 hash:
5e8add2190
Runtime Environment: OS Name: Windows OS Version: 10.0.16299
OS Platform: Windows RID: win10-x64 Base Path: C:\Program
Files\dotnet\sdk\2.1.4\
Microsoft .NET Core Shared Framework Host
Version : 2.0.5 Build :
17373eb129b3b05aa18ece963f8795d65ef8ea54
Please feel free to let me know what other information may be pertinent.
UPDATE: As Requested CSProj Sample (Some Things Had to be Redacted)
https://gist.github.com/mikeomeara1/0edd3b83447473accd3350ffc974c62c

The older .NET Framework project system doesn’t properly support .NET Standard Library 2.x, at least at design time. It requires the new .NET Core SDK project system.
A good migration how-to I’ve recently followed — https://www.natemcmaster.com/blog/2017/03/09/vs2015-to-vs2017-upgrade/.

#MattBrooks and #ScottChamberlain are correct and this is a Visual Studio csproj issue and following the link #MattBrooks provided is the correct answer to this question (I've marked it as such). However, I also wanted to share my personal experience with this in the hopes it will help others who find this process convoluted and confusing (and it doesn't seem right to plop this into an update to the question). As Matt says, "it can be very confusing and sometimes the tooling doesn’t help very much."
Here is the exact procedure I used to convert my projects over. After trying to manually convert a couple, I gave up and rebuilt them:
Remove Project from Solution
Copy Project Folder to Backup Location
Add New ".NET Standard" Class Library Project with Same Name
Edit new .csproj and Change <TargetFramework> to net461 (or whatever you need. Note this can't be done from the Target Framework UI Dropdown. All you'll see is "Net Standard").
Copy all <package> elements from backup projects packages.json (if you don't have a package.json see the outline from the accepted answer to convert your csproj <References> to <PackageReferences>)
Create <ItemGroup> in new csproj
Paste in <package> elements
Find Replace:
<package id= --> <PackageReference Include=
targetFramework=".*" --> <blank>
version --> Version
Open Backed-Up .csproj and copy all <Reference Include=... That DON'T HAVE Version=4.1.0.0, Culture=neutral, PublicKeyToken=..." e.g. that look like <Reference Include="System.Web" /> and paste into new csproj and save.
At this point, NuGet will restore your packages.
If you (likely) end up with NuGet Dependencies that have Yellow/Warning Triangles:
Try to build and see if you get any errors/warnings in the error list. I had some versions that didn't jive between projects. Apparently that's a full stop issue now.
I had some Pre-Release NuGet Packages from a Private Feed that I had to re-install manually.
If all else fails, remove the reference from csproj and install directly from NuGet
If all else all else fails, uninstall and reinstall the package from the VS Package Manager
Copy content files and folders from Backup Project into New Project Folder - VS Will Pick them Up and Auto-Add to Project. I also had to copy node_modules for projects that had NPM packages installed from the backup back into the new project.
Add back any solution project references you may have.
Now, the fun part if you're an idiot like me and had files "excluded from project"....you must hunt those down and remove them.
I would also note that if you (like me) had <Reference> tags to packages in your csproj and a package.json, I found that the package.json was accurate in terms of having the correct versions.
I was not able to convert a single MVC4/WebAPI2 project over because there doesn't seem to be a way in the new project format to tell it "This is a web project, run IIS and debug"...in that all new Core projects expect an static void Main. Probably a different question though.
I was able to get the MVC4/WebAPI2 App Migrated Using the Answer Provided here: https://stackoverflow.com/a/49655107/3892531
Good Luck!

How to upgrade msbuild to C# 6?

I want to use C# 6 in my project (null propagation, other features).
I've installed VS 2015 on my PC and it works brilliantly and builds test code like
var user = new SingleUserModel(); //all model fields are null
var test = user.User?.Avatar?["blah"];
But when I push my project to the repo and CI starts to build it, build fails because of unsupported ?.
I've installed VS2015 on CI server too but looke like it doesn't use it.
What can I do?
CI - CruiseControl .NET
Builds with C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe

Make sure you call:
C:\Program Files (x86)\MSBuild\14.0\Bin\MsBuild.exe
That's the version of MsBuild that ships with Visual Studio 2015 and calls the C# compiler that understands this. You can get this version of MsBuild on your system by installing any edition of Visual Studio 2015 or by installing the stand-alone Microsoft Build Tools 2015.
Adding a reference to the following NuGet package will also force use of the new compiler:
Install-Package Microsoft.Net.Compilers
Please note Install-Package will pick the latest available version which may not be the one you are looking for. Before you install, please check the release notes and dependencies to resolve the underlying issue with the version being dealt with, which in this case, was more specific to VS 2015.
So for Visual Studio 2015:
Install-Package Microsoft.Net.Compilers -Version 1.0.0

You can by the way also install the "Microsoft Build Tools 2015" instead of VS2015 on your build server.
https://www.microsoft.com/en-us/download/details.aspx?id=48159
It installs MSBuild to the same path:
C:\Program Files (x86)\MSBuild\14.0\Bin\MsBuild.exe

You probably already have this working, but this might help someone else in the future. I came across this question recently and it got me moving in the right direction and ultimately led to a solution.
Another possible solution to this is manually updating your project files to target the MSBuild version you want your projects to be built with.
I've recently gone through a TeamCity build server update and I've already installed the Microsoft Build Tools 2015 on it. I thought I had everything in place on the build server, I had my solution targeting C# 6.0, and I had every project targeting .net 4.6.1. Like you, everything with C# 6.0-specific code built just fine in my local environment, but my TeamCity build server didn't like any of it.
As mentioned by others, I tried using the Microsoft.Net.Compilers NuGet package. The latest version of it allowed the build to work on my build server, but it wouldn't let me publish my code locally (a requirement of mine). Earlier versions of that NuGet package would let me publish, but the build wouldn't work.
What I found that I had to do was ultimately modify each project file in my solution to specifically target the MSBuild version that could handle C# 6.0 code. In each of my project files, I found a line similar to the following line:
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
with the key component of that line being the ToolsVersion portion of it. I simply changed this line on my project files to read the following:
<Project ToolsVersion="14.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
The difference here was that I was targeting version 14, not 4. Version 14.0 corresponds with Build Tools 2015. By changing this, my TeamCity build server used the correct MSBuild version and was able to build my C# 6.0 code.
I also had to manually update the TargetFrameworkVersion xml node of this to use 4.6.1 because VS2015 wasn't doing something right and messed up my local build, but that's not relevant here.
Please, someone correct me if I'm wrong, but just for reference, I think the version numbers go something like this:
4.0 = VS2012
12.0 = VS2013
14.0 = VS2015
15.0 = VS2017
I believe if you wanted to use .net 4.7, you'd have to have the Build Tools 2017 installed and have your projects targeting 15.0 instead of 14.0, but I haven't verified this.