Scott Hanselman

Working with Multiple .NET Core SDKs - both project.json and msbuild/csproj

January 21, '17 Comments [9] Posted in
Sponsored By

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.

Global.json is useful

This is assuming that you do have multiple versions (and the ones you want) installed:

Here I have 4 SDKs installed and I can see them in my installation folder

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

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb
Tuesday, 24 January 2017 05:41:22 UTC
Thanks Scott. That will be one for the bookmarks. A succinct post like that can really help when the alternative is trawling documentation that may or may not be complete.
Dave
Tuesday, 24 January 2017 06:29:34 UTC
Thanks, that looks good, especially the migrate command, but again I hope all this is included in VS in the future so one can just swap core frameworks as we do now with full frameworks and also just change a setting to do standalone deployments.
Kevin
Tuesday, 24 January 2017 09:13:51 UTC
It looks like the official docs on the repo says you can't have preview4 for project.json. No mention of global.json and states you need preview2 tooling still on your system. https://github.com/dotnet/cli#preview-4-release---msbuild-based-tools

After looking on dot.net for the preview4 tooling and not finding it, its here if others are looking for it - Installers & Binaries
Tuesday, 24 January 2017 11:54:04 UTC
What a mess, I think I'll leave it for a year or two and see if it's all sorted then.
Tuesday, 24 January 2017 15:05:36 UTC
Thanks for the info. It is confusing but I guess that is part of the "fun" of using preview releases.
Tuesday, 24 January 2017 17:33:03 UTC
"dotnet-migrate" is only available in dotnet CLI preview3. is that correct? i am in preview 2 and i dont' see it. but i don't see preview3 being available for download.
alltej
Tuesday, 07 February 2017 05:00:18 UTC
Hello! Excellent and decent post. I found this much informative, as to what I was exactly searching for. Thanks for such post and please keep on sharing with us.... Showbox for PC. The website looks great. The article is written so professionally that no even words. Showbox for PC
Thursday, 09 February 2017 09:52:49 UTC
It's hard to keep up!

I was following https://mva.microsoft.com/en-US/training-courses/introduction-to-aspnet-core-10-16841?l=JWZaodE6C_5706218965 using Visual Studio Code in Ubuntu 16.04 LTS (and using netcoreapp1.1).

In the video you introduce dotnetwatch and show how to copy and paste from GitHub to the project.json file.

Of course, on GitHub, the documentation has already migrated to the dotnetclitoolreference syntax. I had a look at the history in GitHub to establish a timeline for changes. I listen to podcasts so I was at least aware, peripherally, about going back to .csproj (+). The awareness slowly dawned on me as I struggled to comprehend what was happening.

So next, I had to search how to move from project.json to .csproj in simple terms etc. in Visual Studio Code, so I can continue to learn .Net Core etc. on Ubuntu (a small pebble on a beach of hurried learning). Brought me here.

I wish Microsoft could use its cognitive services somehow for some kind of dependency graph for documentation so evaluation of prerequisites with chained notices of correction or change could be rendered visually for quick consumption, and maybe for simple group-editing. The process could possibly highlight breaking changes to the documentation so that you could use some kind of embedded shortcode or something easily available to the documentation editor to pass as a callback to the breaking-change-watcher. The AI component might allow for general references within a context rather than hard-coding references, or might even piggy-back on semantic/accessibility good practice. Must be some human-sustainable/extensible approach. (Idle fantasising lol).

Love the show and everything you do for the community,

Ta, Dave
David Bayliss
Thursday, 09 February 2017 10:20:34 UTC
Ps: Had a coffee, realised I was being stupid worrying about this for now, and just typed in the tools dependency manually in the project.json, updating the version from "1.0.0-*" to "1.1.0-*" to match my .Net Core version. Works fine. Made me realise the irony of copying & pasting from GitHub in the video when talking about dependencies ... i.e. breaking the SRP. :) It is kind of funny.
David Bayliss
Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.