As .NET Core and ASP.NET Core make the transition from project.json style project files to MSBuild (csproj) style files, I'm starting to get myself up to speed on what's needed, what's changing, and why/if it's a good thing. Documentation is still getting updated but there's a great blog post from Nate McMaster who works on the team.
As I touched on in a previous post, you can continue working on project.json based projects while experimenting with the newer stuff. Here I have a global.json with the version pinned to an earlier SDK. Then I move to another folder and the .NET CLI gives me another version. Projects can remember and pin their SDK versions.
This is assuming that you do have multiple versions (and the ones you want) installed:
To be clearer, I'll run "dotnet new" in one folder and again run "dotnet new" in another. Note that one has global.json pinned older "LTS" (Long Term Support) SDK with project.json and one will use the later "Current" (bleeding-edge) stuff.
See how that works?
C:\Users\scott\Desktop\csprojstuff> dotnet new
Created new C# project in C:\Users\scott\Desktop\csprojstuff.
C:\Users\scott\Desktop\csprojstuff> dir
Volume in drive C is Windows
Volume Serial Number is 00C1-AED2
Directory of C:\Users\scott\Desktop\csprojstuff
01/23/2017 01:09 PM <DIR> .
01/23/2017 01:09 PM <DIR> ..
12/07/2016 09:49 PM 422 csprojstuff.csproj
12/07/2016 09:49 PM 133 Program.cs
2 File(s) 555 bytes
2 Dir(s) 149,845,356,544 bytes free
C:\Users\scott\Desktop\csprojstuff> cd ..\projjsonstuff
C:\Users\scott\Desktop\projjsonstuff> dotnet new
Created new C# project in C:\Users\scott\Desktop\projjsonstuff.
C:\Users\scott\Desktop\projjsonstuff> dir
Volume in drive C is Windows
Volume Serial Number is 00C1-AED2
Directory of C:\Users\scott\Desktop\projjsonstuff
01/23/2017 01:10 PM <DIR> .
01/23/2017 01:10 PM <DIR> ..
01/23/2017 01:05 PM 95 global.json
06/21/2016 07:10 PM 214 Program.cs
06/21/2016 07:10 PM 367 project.json
3 File(s) 676 bytes
2 Dir(s) 149,844,484,096 bytes free
Now I can also "migrate" that project.json forward with "dotnet migrate." That's a NEW command so look what happens if I just run it locally there without changing the global.json pinned SDK version? Doesn't work. For this example I'll delete global.json and run it again.
C:\Users\scott\Desktop\projjsonstuff> dotnet migrate
No executable found matching command "dotnet-migrate"
C:\Users\scott\Desktop\projjsonstuff> del global.json
C:\Users\scott\Desktop\projjsonstuff> dotnet migrate
Project projjsonstuff migration succeeded (C:\Users\scott\Desktop\projjsonstuff)
Summary
Total Projects: 1
Succeeded Projects: 1
Failed Projects: 0
C:\Users\scott\Desktop\projjsonstuff> dir
Volume in drive C is Windows
Volume Serial Number is 00C1-AED2
Directory of C:\Users\scott\Desktop\projjsonstuff
01/23/2017 01:11 PM <DIR> .
01/23/2017 01:11 PM <DIR> ..
01/23/2017 01:11 PM <DIR> backup
06/21/2016 07:10 PM 214 Program.cs
01/23/2017 01:11 PM 944 projjsonstuff.csproj
2 File(s) 1,158 bytes
3 Dir(s) 149,843,054,592 bytes free
Again, go check out Nate's excellent blog on the topic. He also covers briefly how you can publish "Standalone" or "Self-Contained" Deployments, and points out that in MSBuild world, all projects are portable until you decide to target a runtime:
dotnet publish --framework netcoreapp1.0 /p:RuntimeIdentifier=osx.10.11-x64
More on this as it comes!
Sponsor: Do you deploy the same application multiple times for each of your end customers? The team at Octopus have taken the pain out of multi-tenant deployments. Check out their latest 3.4 release
© 2016 Scott Hanselman. All rights reserved.