Converting Old-style .csproj to SDK-style project

[sator-imaging]

Summary

Another approach to the problem: #5551

Why I need to resolve the old-style csproj problem is that, In Unity game development, it exports old-style files. so some features are not supported on development.

Solution

When I try to change unity project header to <Project Sdk="Microsoft.NET.Sdk">, it causes so many problems.

then, I change header to <Project Sdk=""> (empty string), it looks fine except for the warning shown below toolbar. I am not sure how Unity compiles C# assembly (I heard that unity doens't use msbuild), resulting .dll files also look fine.

so simply adding the "Do nothing" sdk could solve the old-style file problem.

<Project Sdk="EmptySdk.DoNothing">
    <!-- old-style csproj contains all of necessary information inside -->
</Project>

User Impact

Especially for Unity development, Unity exports all .csproj files in same folder, so if SDK-style .csproj will try to collect .cs files from root directory implicitly, it will cause problem.

Unity Project Structure

• Project/
  • Assets/
    • AssemblyA/
      • *.cs
    • AssemblyB/
      • *.cs
• AssemblyA.csproj (comping Project/Assets/AssemblyA/**.cs only)
• AssemblyB.csproj (and so on)

[julealgon]

Isn't this much more of a Unity gap? IMHO they should be the ones changing what they are doing to something more standard that works with the modern .NET ecosystem.

[sator-imaging]

I agree modernization is the best, my request is temporary solution for a while.

Unity's Visual studio plugin changelog describes that "Adding support for SDK-Style..." but unfortunately, that feature is only activated when working with vscode. and also it is not actual sdk-style, project file header is set to <Project ToolsVersion="Current"> ie. Nullable property is not recognized by VS.

[tmeschter]

When I try to change unity project header to <Project Sdk="Microsoft.NET.Sdk">, it causes so many problems.

This is expected. The .NET SDK handles many aspects of building a project in a very different manner than the older tooling. Migrating a project to be SDK-style almost always requires projects changes beyond just updating that header, as well as changes to the related tooling in the IDE.

In the short-term we do not have the domain expertise to produce a functional workaround for Unity, nor is this an area we are going to dedicate resources to. Long-term the way forward is for the Unity tooling to produce SDK-style projects that reference an SDK that makes sense for Unity.

Closing the issue.