Consider updating the scaffold for the dotnet SDK

[baronfel]

Description

The idea would be to keep all of the excellent features, possibly even the default full-framework targeting, just migrate projects and build scripts to using dotnet sdk/cli features where appropriate.

This would be to encourage good practices going forward, as well as make it easier for developers to opt into multitargeting and such.

Repro steps

Run the init script.

Expected behavior

My pipeline/projects are set up to use the dotnet sdk/cli

Actual behavior

The scripts and projects use old-style projects and a myriad of tools.

Known workarounds

Manually convert projects and scripts to dotnet sli/sdk where appropriate (~1hr of work)

[cdrnet]

Wouldn't this then require having some dotnet sdk installed?

[baronfel]

Not necessarily. We could use the new SDK and make the build script steps choose either mono's msbuild or dotnet cli commands based on what the user response is at init time.

The nice thing about the new SDK is that every dotnet cli action (restore, build, pack, etc) is mapped to a single msbuild target (Restore, Build, Pack), and mono 5+ uses the new msbuild which understands this.

So we can get to a cross-compatible project file and lower the user overhead for switching to netcore fully if and when they decide to.

[TheAngryByrd]

Please feel free to use anything from https://github.com/TheAngryByrd/MiniScaffold

[jackfoxy]

My fork implements the dotnetsdk. Do people generally want this project to move forward with that?

[jackfoxy]

this issue now covered by https://github.com/fsprojects/ProjectScaffold/issues/325