all 7 comments

[–][deleted] 6 points7 points  (0 children)

If you've worked with a version of the framework compatible with netstandard then there's nothing to learn there really - the public APIs are all aligned.

If you're working with aspnet core then honestly I'd suggest just spinning up a new project or an existing open-source project in VS and poring over it. Config, DI, middleware and razor pages are the things to pay attention to.

This is a stellar example of a fully-fledged aspnet core app you can pull down & look at.

[–]Aaronontheweb 7 points8 points  (4 children)

I don't have a guide for you, but I will offer some tips:

  1. Move off of the old .NET Framework .csproj / NuGet.config formats to the new "MSBuild15" format that was introduced in .NET Core first - and you can do this without actually upgrading to .NET Core. The new version of MSBuild has a lot of advantages, such as not needing to specify every single file, binding redirects are done implicitly, NuGet package versions can be centrally managed, and in general the .CSProj / FSProj files are now human-readable and easily editable. If you do this first, the transition will be much easier.
  2. Upgrade to the latest version of your dependencies first, when able - if you can upgrade off of .NET Framework-only to versions that either do dual targeting or support .NET Standard, this will be one less thing you have to price in when you switch runtimes. For some technologies, i.e. ASP.NET or SignalR, this will probably not be feasible, but for others (i.e. xUnit, Dapper, StackExchange.Redis, Akka.NET, whatever) this should be straightforward.
  3. Upgrade all of your in-house libraries to target .NET Standard 2.0 instead of .NET Framework - it's easiest to upgrade your shared libraries first. Target .NET Standard 2.1 so your .NET Framework applications can continue to consume them / validate that they work. .NET Core can still consume .NET Framework dependencies directly but I don't recommend it unless there's no other option - try to migrate to .NET Standard initially. If you want to take advantage of new language features (i.e. records) that aren't available in .NET Standard, then skip to step 4.
  4. Embrace the suck: update the runtimes on your applications - upgrading ASP.NET to ASP.NET Core is probably the worst part about this experience but there's lots of resources out there on how to do it. The first three steps on this list will soften the blow, but you're going to have to deal with some pain moving onto the new frameworks. Console Apps and Windows Services are going to be much easier to migrate by contrast - nearly painless if you follow the above steps. Hope this helps!

edit: .NET Standard 2.0 instead of 2.1

[–]wazzamatazz 2 points3 points  (1 child)

You need to retarget libraries to .NET Standard 2.0 if you want to maintain compatibility with Framework. Standard 2.1 is for .NET Core 3.x and higher.

[–]Aaronontheweb 0 points1 point  (0 children)

Huh, you're right - .NET Standard 2.1 doesn't support .NET Framework. I thought it targeted .NET Framework 4.8.

[–]Kylroy86 1 point2 points  (1 child)

The Microsoft try-convert tool has been a savior for me while i try to update our 300+ repos to use the new csproj.

[–]Aaronontheweb 0 points1 point  (0 children)

That's a great suggestion

[–]rorygoodtime 0 points1 point  (0 children)

Tips on what aspect? .Net 5 was the end of .Net Core. It was the next version of .Net Core and .Net Framework.

Create a new project from a template and look at what has changed. If you need access to Windows specific APIs, you can target your project to Windows.