Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

SDK style .csproj for .NET full framework

Does anyone know why, when creating a new .NET full framework project, Visual Studio (version 15.9.2) still uses the old style of .csproj file?

To get round this, when creating new full framework projects, I create a .NET core project and then simply edit the TargetFramework tag in the .csproj to target net472 (for example), thereby taking advantage of the new simplified structure.

Does anyone see a problem with this approach?

like image 723
Mr Davies Avatar asked Nov 21 '18 07:11

Mr Davies


People also ask

What is .NET Framework SDK?

NET SDK is a set of libraries and tools that allow developers to create . NET applications and libraries. It contains the following components that are used to build and run applications: The . NET CLI.

Does .NET framework include SDK?

The . NET Framework SDK, is a software development kit (SDK) from Microsoft.

How do I find .NET SDK?

You can see both the SDK versions and runtime versions with the command dotnet --info . You'll also get other environmental related information, such as the operating system version and runtime identifier (RID).


1 Answers

As to the why, here's an excerpt from a GitHub issue that covers some of it (Add support for ASP.NET (non-Core) projects #2670), albeit specific to an ask regarding ASP.NET, rather than .NET Framework projects in general:

Honestly I don't see this happening in the short term (this year). There are lots of kinks to work out with SDK projects and the new project system before we can bring them to older projects. Those kinks don't even have anything to do with ASP.NET so then there would be a bunch of work that needs to happen to port ASP.NET things to the new project system which is non trivial e.g. old razor editor, aspx editor, webforms designer??, build system (WAP projects have a hybrid msbuild + build manager build system), and any other quirks that System.Web requires. Some of those components are written in native code since the older project system was native.

All of this to say, it's not a simple flip the switch, it's the same set of people working on new and existing project systems. When the SDK projects are near flawless, I'd look at bringing it to down level projects.

Short version: The new project system isn't mature enough yet to shift over everything, and that won't be a small undertaking when it is.

There's also commentary in there about issues you can have mixing old and new projects in the same solution (which may not be an issue for you, but is worth mentioning for others):

We can't move because we can't even start to move the solutions. We can't move things to libraries on the new system and migrate over in any reasonable way, because the build system won't build both.

If it works for you, great, but it's not supported and there are definitely pitfalls that you may encounter.

like image 157
Rob Avatar answered Sep 19 '22 23:09

Rob