Developing On Two Versions Of .Net Core SDK Side-By-Side

In previous versions of .net core, picking which .net framework version you were going to use was as simple as selecting it in the “new project” dialog of Visual Studio. With .net core things have changed somewhat, mostly because while Visual Studio is still the IDE for the majority of developers on windows machines, there is now a myriad of ways to write code with .net core all the way down to using a simple text editor.

The issue of picking a .net core version mostly comes about when you want to test out the latest release candidate version to see what’s new, but you need to keep using an older release for your day to day work. Or it could even be that a very old project uses a previous release, but now you want to start doing all future work on the latest .net core version. All problems that can be solved, even if in a slightly round about way!

How Do I Know Which .Net Core SDK Versions I Have?

The simplest way is to check your SDK folder. First, open a command prompt and type the following :

where dotnet

You should be given a path similar to the following :

C:\Program Files\dotnet\dotnet.exe

Go to that “folder” so in my case C:\Program Files\dotnet\. Inside there you should see another folder labelled “sdk”. Inside here you will find all “installed” SDK versions of .net you have available. Mine looks a bit like the following :


Now these versions probably don’t line up with what you are expecting for the most part. It would make more sense of course to have them named “1.0” “1.1” “1.1.4” etc. But, Microsoft being Microsoft it is what it is. If you are confused, you should be. In the future Microsoft have said they will clean up these version issues, but for now this is what you have. I haven’t been able to find official documentation with a simple table to look up what version of the SDK means what (If you have, drop a comment below!).

There is however this article here (https://github.com/dotnet/core/blob/master/release-notes/download-archive.md). It has a bit more on the version numbers which through a bit of mental gymnastics you can kind of make our what they mean.

I can tell you what those on my machine mean :

1.0.0-preview2-003131 – .net Core 1.0 tooling
1.0.0-preview2-1-003177 – .net Core 1.1 tooling with project.json
1.0.0-rc4-004771 – .net Core tooling with Preview 4 (which is .csproj not project.json).

For the most part when you are finding which versions you have on your machine, you are probably going to be able to match them up with an existing SDK version of a project anyway (More on that later), so don’t get too stressed trying to work out what they mean for now.

What Is My Default .Net Core SDK Version?

By default, the latest SDK version is going to be your default version. When I say default, I mean that if you opened a folder and ran “dotnet new”, what version of the tooling would it use.

But to be 100% sure, open a command prompt that is not inside an actual .net core project and run :

dotnet --version

You will get a response like “1.0.0-rc4-004771”. That is your default .net core SDK.

How Do I Know An Existing .Net Core Project’s SDK Version?

In the root of your Solution (Not your project!), look for a file named “global.json”. Inside this file you will find an element that looks like the following :

"sdk": {
	"version": "1.0.0-preview2-003131"
}

This tells dotnet what version of the SDK it should be forced to use, irrespective of other tooling you have installed or what is the default. For example if I open a command prompt inside this solution and run “dotnet –version”. I get the response “1.0.0-preview2-003131” even if the default for my machine is RC4 etc.

And if you don’t have a global.json? Then it runs on the latest version on that machine. Unsurprisingly these could cause issues in the future so it is much much better to have a global.json in your solution directory to lock down the SDK version. This is especially true if you are part of a team that may have any amount of SDK’s installed on each machine.

How Do I Create A New Project With A Specfic SDK Version In Command Line?

The above section probably pointed you in the right direction already, but let’s go over it. I create a solution folder and place a global.json file in there with the following contents :

{
  "sdk": {
    "version": "1.0.0-preview2-003131"
  }
}

Note that this SDK version is an old version that used project.json files. That will be important shortly.

I then create a folder in the solution directory for my project. Opening a command prompt in the project folder and running “dotnet new -t web”. A web project is created that when I view it, I can see it has project.json files which means it must have read my global.json file (From a directory up no less). I know this because only older versions of the SDK use project.json, if it didn’t bother reading the global.json it would have created a project using .csproj files instead.

Just to be sure, I create a new solution folder and place the following global.json file inside :

{
  "sdk": {
    "version": "1.0.0-rc4-004771"
  }
}

Now we are forcing the SDK version to a later version (That uses csproj files).

Again, I create a project folder inside the solution directory. This time I run the following command “dotnet new webapi” (In RC4, the -t flag is removed and you can instead just pass in what type of project you would like directly). Inside our project folder I can see that a API project has been created and it’s using CSProj files not project.json files. Success!

How Do I Create A New Project With A Specfic SDK Version In Visual Studio?

Most people with Visual Studio would presume that when creating a new project in .net core, you are presented with the option of which SDK you want to use. This is not the case. You are asked what version of the .net core framework you would like to use (1.0 or 1.1), but not the tooling (e.g. Whether you wish to run project.json or .csproj). If you create a project from Visual Studio this way, it will use the latest version on your machine at that time and put that into your global.json. This may work just fine for you, but in other cases (such as if you have developers using Project Rider from Jetbrains that only supports Preview 2 of the tooling), you will need to define the SDK ahead of time.

In my case, I actually haven’t found a way to do it. Using Visual Studio 2017, it doesn’t seem to care what is inside the global.json and just creates a file with csproj anyway. This is in comparison to Visual Studio 2015 which will only create projects that use project.json. In this way you can “kind of” force a SDK version by using a specific version of Visual Studio, but it’s not exactly a perfect science.

In my experience, it’s better to just use the command line tools to get you up and going to start with. Once you have a solution created from the command line and you add additional projects, Visual Studio does then recognize the existing global.json SDK.

5 thoughts on “Developing On Two Versions Of .Net Core SDK Side-By-Side”

  1. That was very informative. But I have a question – You say ‘You are asked what version of the .net core framework you would like to use (1.0 or 1.1), but not the tooling (e.g. Whether you wish to run project.json or .csproj)’.

    That confuses me about what the difference is between .net core framework and .net core tooling. Isnt the .net core framework version the same as the .net core tooling version?

    Reply
    • Actually no, the tooling versions are wide and varied (You can see them all here : https://github.com/dotnet/core/blob/master/release-notes/download-archive.md), but the tooling doesn’t actually determine what version of .net core you are running. Both Project.json and .csproj based projects can run 1.0 and 1.1. I think the easiest way to think about it is, that after you have published your code, the runtime doesn’t actually read your project.json or csproj at all right? It’s just reading the binaries. So the runtime of 1.0 and 1.1 is different from the “tooling” of how you create those binaries. Hopefully that makes sense!

      Reply
  2. Hello, your article is very informative. thanks.

    Would you mind clearing up a little bit about the folders mentioned below? what do they signify and when/how are they used? please.

    C:\Program Files\Dotnet\Sdk
    C:\Program Files\Dotnet\Sdk\NuGetFallbackFolder
    C:\Program Files\dotnet\shared\Microsoft.NETCore.App

    thanks!

    Reply

Leave a Comment