I took an ASP.NET Core 1.0 application and updated its package references to ASP.NET 1.1 today. I also updated to my SDK to the Current (not the LTS – Long Term Support version). Everything worked great building and running locally, but then I made a new Web App in Azure and did a quick git deploy.
c:aspnetcore11app> azure site create "aspnetcore11test" --location "West US" --git
c:aspnetcore11app> git add .
c:aspnetcore11app> git commit -m "initial"
c:aspnetcore11app> git push azure master
Then I watched the logs go by. You can watch them at the command line or from within the Azure Portal under “Log Stream.”
The deployment failed when Azure was building the app and got this error:
Build started 11/25/2016 6:51:54 AM. 2016-11-25T06:51:55 1>Project "D:homesiterepositoryaspnet1.1.xproj" on node 1 (Publish target(s)). 2016-11-25T06:51:55 1>D:homesiterepositoryaspnet1.1.xproj(7,3): error MSB4019: The imported project "D:Program Files (x86)dotnetsdk1.0.0-preview3-004056ExtensionsMicrosoftVisualStudiov14.0DotNetMicrosoft.DotNet.Props" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk. 2016-11-25T06:51:55 1>Done Building Project "D:homesiterepositoryaspnet1.1.xproj" (Publish target(s)) -- FAILED. 2016-11-25T06:51:55
See where it says “1.0.0-preview3-004056” in there? Looks like Azure Web Apps has some build that isn’t the one that I have. Theirs has the new csproj/msbuild stuff and I’m staying a few steps back waiting for things to bake.
Remember that unless you specify the SDK version, .NET Core will use whatever is the latest one on the box.
Well, what do I have locally?
OK, then that’s what I need to use so I’ll make a global.json at the root of my project, then move my code into a folder under “src” for example.
"projects": [ "src", "test" ],
Here I’m “pinning” the same SDK version. This will tell Azure (or you, if I gave you the code) to use this SDK version when building.
Now I’ll redeploy with a git add, commit, and push. It works.
I think this should be easier, but I’m not sure how it should be easier. Does this mean that everyone should have a global.json with a preferred version? If you have no preferred version should Azure give a smarter error if it has an incompatible newer one?
The learning here for me is that not having a global.json basically says “*.*” to any cloud build servers and you’ll get whatever latest SDK they have. It could stop working any day.
Sponsor: Big thanks to Octopus Deploy! 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!