ReviewCoreASPHosting.NET | Best and cheap ASP.NET Core 1.1 hosting. I was planning on playing with the latest .NET Core 1.1 preview recently, but I ran into a few issues getting it working on my Mac. As I suspected, this was entirely down to my mistakes and my machine’s setup, but I’m documenting it here in case any one else runs into similar problem!
Note that as of yesterday the RTM release of 1.1 is out, so while not strictly applicable, I would probably have run into the same problems! I’ve updated the post to reflect the latest version numbers.
TL;DR; There were two issues I ran into. First, the global.json file I used specified an older version of the tooling. Second, I had an older version of the tooling installed that was, according to SemVer, newer than the version I had just installed!
Installing ASP.NET Core 1.1
I began by downloading the .NET Core 1.1 installer for macOS from the downloads page, following the instructions from the announcement blog post. The installation was quick and went smoothly, installing side-by side with the existing .NET Core 1.0 RTM install.
Creating a new 1.1 project
According to the blog post, once you’ve run the installer you should be able to start creating 1.1 applications. Running donet new with the .NET CLI should create a new 1.1 application, with a project.json that contains an updated Microsoft.NETCore.App dependency, looking something like:
"frameworks": {
"netcoreapp1.0": {
"dependencies": {
"Microsoft.NETCore.App": {
"type": "platform",
"version": "1.1.0"
}
},
"imports": "dnxcore50"
}
}
So I created a sub folder for a test project, ran dotnet new and eagerly checked the project.json:
"frameworks": {
"netcoreapp1.0": {
"dependencies": {
"Microsoft.NETCore.App": {
"type": "platform",
"version": "1.0.0"
}
},
"imports": "dnxcore50"
}
}
that doesn’t look right, we still seem to be getting a 1.0.0 project instead of 1.1
Check the global.json
My first thought was that the install hadn’t worked correctly – it is a preview after all (it was when i originally tried it!) so wouldn’t be completely unheard of. Running dotnet --version to check the version of the CLI being run returned
$ dotnet --version 1.0.0-preview2-003121
So the preview 2 tooling is being used, which corresponds to the .NET Core 1.0 RTM release, definitely the wrong version.
It was then I remembered a similar issue I had when moving from RC2 to the RTM release – check the global.json! When I had created my sub folder for testing dotnet new, I had automatically copied across a global.json from a previous project. Looking inside, this was what I found:
{
"projects": [ "src", "test" ],
"sdk": {
"version": "1.0.0-preview2-003121"
}
}
If an SDK version is specified in global.json then it will be used preferentially over the latest tooling. Updating the sdk section with the appropriate value, or removing the SDK section means the latest tooling should be used, which should let me create my 1.1.0 project.
Take two – preview fun
After removing the sdk section of the global.json, I ran dotnet new again, and checked the project.json:
"frameworks": {
"netcoreapp1.0": {
"dependencies": {
"Microsoft.NETCore.App": {
"type": "platform",
"version": "1.0.0"
}
},
"imports": "dnxcore50"
}
}
that’s still not right! At this point, I started to think something must have gone wrong with the installation, as I couldn’t think of any other explanation. Luckily, it’s easy to see which versions of the SDK are installed by checking the file system. On a Mac, you can see them at:
/usr/local/share/dotnet/sdk/
Checking the folder, this is what I saw, notice anything odd?
There’s quite a few different versions of the SDK in there, including the 1.0.0 RTM version (1.0.0-preview2-003121) and also the 1.1.0 Preview 1 version (1.0.0-preview2.1-003155). However there’s also a slightly odd one that stands out – 1.0.0-preview3-003213. (Note, with the 1.1 RTM there is a whole new version, 1.0.0-preview2-1-003177)
Most people installing the .NET Core SDK will not run into this issue, as they likely won’t have this additional preview3 version. I only have it installed (I think) because I created a couple of pull requests to the ASP.NET Core repositories recently. The way versioning works in the ASP.NET Core repositories for development versions means that although there is a preview3 version of the tooling, it is actually older that the preview2.1 version of the tooling just released, and generates 1.0.0 projects.
When you run dotnet new, and in the absence of a global.json with an sdk section, the CLI will use the most recent version of the tooling as determined by SemVer. Consequently, it had been using the preview3 version and generating 1.0.0 projects!
The simple solution was to delete the 1.0.0-preview3-003213 folder, and re-run dotnet new:
"frameworks": {
"netcoreapp1.0": {
"dependencies": {
"Microsoft.NETCore.App": {
"type": "platform",
"version": "1.1.0-preview1-001100-00"
}
},
"imports": "dnxcore50"
}
}
Lo and behold, a 1.1 project!
Summary
The final issue I ran into is not something that general users have to worry about. The only reason it was a problem for me was due to working directly with the GitHub repo, and the slightly screwy SemVer versions when using development packages.
The global.json issue is one that you might run into when upgrading projects. It’s well documented that you need to update it when upgrading, but it’s easy to overlook.
Anyway, the issues I experienced were entirely down to my setup and stupidity rather than the installer or documentation, so hopefully things go smoother for you. Now time to play with new features!