SDK-based csproj files for full framework projects
This suggestion is migrated to Developer Community. Please use below link to view the current status.
I love the new "SDK based .csproj" files for .NET Core. Unfortunately, I'm working on a project that targets the full .NET framework and uses old technologies like Classic ASP! There seems to be a manual "hacked" way of using the SDK based .csproj files for these projects by setting the TargetFramework to e.g. "net461", but it doesn’t work 100% smoothly. It would be great to get all this goodness for older project types as well.
Some of the great thing about the SDK based projects:
- Globbing patterns in files - no more merge conflicts in .csproj, git commits”outside of VS where you've forgotten to save in VS so that your added file is not included, and no more constant reload of project in VS when switching branch! Yay!
- NuGet referenes in the .csproj files only – less duplication
- NuGet packages restored to a central place rather than in "\packages"
- Support for NuGet transitive dependencies
- AssemblyInfo in .csproj
- Sensible defaults in .csproj
- Human readable (and editable) .csproj!
So far, some of the issues I've experienced is:
- I have an ASP.NET project that I want to run locally in IIS as I'm developing by just pointing IIS to the root of my source. This doesn't work out of the box because the binaries are not in the root of the "\bin" folder but is forced in a "\bin\<framework>" folder. I've resolved for now by making a post-build target in msbuild that copies all files to the root of \bin, but it would be great to be able to force to a specific output folder without the framework moniker.
- It doesn't seem that Azure Cloud Deployment projects (.ccproj) play nicely with pointing to SDK based projects. Since we have old Classic ASP projects, we deploy to Azure using the old Azure Cloud Services where we can configure the machine to support that.
- I seem to have problems using the "COMReference" for importing COM references (yeah I know - we have an old stack!)
Thanks Kevin. Bearing that in mind I have moved my votes to: https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/20232889-sdk-based-csproj-files-for-full-framework-projects
I also think VS should remove the option for using PackageReference style in old project types, because it doesn't work very well. It's flaky and it only shows top level packages since it doesn't have the nesting that's present in the new project system.
I've stumbled across random bugs when trying it too, like the package references all vanishing in solution explorer project node for some reason.
Kevin Pilch [MSFT] commented
Great idea Mark - we're working on making it possible to use this for other project types that are based on the new project system (like JS).
Unfortunately, it's not likely to be retrofitted to the existing C# project system. Over time though, we are working on improving compatibility and performance of the new project system and plan to (someday) support opening non-SDK projects with the new project system too.
This would be useful for this and a variety of other great features (live project editing, file-globbing support, etc).
The way that .net core and .net standard project show references in solution explorer is great. Can we have it extended to other project types since we will be using them for a while yet.