Scott Hanselman

If something can stop working at any time unless there's an explicit version used, it's probably worth treating as a warning - not stopping you, but making it clear that it's not going to last forever and should be fixed at some point. That's the behaviour when compiling something that uses deprecated features, so it's not unheard of or unfamiliar.

My preference, then, is that a global.json should ideally always be specified. If that's too big a change of behaviour, then producing a warning that the resulting code might not be portable without it should hopefully help anyone getting that error and wondering what's wrong.

Obviously the errors caused by this will be different depending on the expected SDK version and the version actually used, so I don't think there will be an easy way of determining at compile time that it boils down to the wrong SDK version. To that end, it might be worth explicitly stating in the dotnet tooling which SDK version is being inferred (and why, i.e. using latest as no global.json found) during the build step.

For those unfamiliar with the command line, I'd also like to see more helpful prompts during failures as well, even if it's just telling them how to run the build with verbosity set to high for more information.

I must say that .net core is becoming very confusing at this stage.

There is the latest .net core 1.1 version, then there is the tooling version... and then there is that moment you just upgraded to the latest versions of the framework and tooling but visual studio keeps creating .net core projects with dependencies for 1.0.1 in project.json and 1.0.0-preview2-003131 in global.json.

I even deleted the unwanted sdk versions from C:\programfiles\dotnet\sdk\1.0.0-preview2-003131

But then Visual Studio fails to load sdk.

Well... I guess better productive days are to come. :)

So, the Web Apps git deploy has preview3 installed, but VSTS hasn't. Very annoying...

Just like we have to specify which .NET Version to use in old school .NET, you should also have to specify it in .NET Core. Whether thats in a global.json or in a csproj or whatever.

probably related: http://stackoverflow.com/questions/40757609/net-core-1-1-0-visual-studio-tooling

Maybe having something like

dotnet migrate --sdk [version]

could solve the issue of having to change the global.json, project.json, for those projects that still use it, and .cproj.

When using Git Deploy can you compile the application yourself and just keep the compiled version in the Git Repo? Anything I do that isn't just a small test application always has multiple build steps or internal libraries that have to be inlcluded from outside of Git but I like the idea of versioned builds and being able to rollback easily.

When I hit this issue myself I spent two days trying to get my project to deploy properly with csproj and preview 3. I heard about this post from the live session today and it inspired me to give up and go back to project.json for a little while.

I am excited for msbuild but there are still a great few things that aren't smooth yet.

And how do I do this for a project created in VS2017 RC1 ? There's already src. And I don't think putting global.json to solution root would do any good... damn!

These are exciting times to be a .NET dev.
I know things are in flux, but I find it hard to imagine .NET versioning/tooling being more confusing than they are right now.

I started a project months ago - knowing full well that I was teetering on the cutting edge of something new.

I know the tooling and SDK are at different stages, but is there somewhere that explains the version numbering?

Last week I dl'd the (LTS) 1.0.1 SDK. The file that dl's is 1.0.0-preview2...
Hold up, 1.0.0? preview?

The difference in version number between what I'm using now, and what I was using is ...3121 -> ...3131.

I see refs in VS to DNX - but I thought DNX was being deprecated in favour of dotnet. I used DNVM to find refs to DNX but read that it too was being deprecated, but dotnet doesn't show me what dnvm did.

I'm considering a win reinstall to start fresh...

Maybe it's just me that's finding it difficult to keep up.
Can you at least tell us that things will get better Scott-wan?
Or point me to somewhere that explains everything?

Thanks

As a side note: When I upgraded my ASP.Net Core 1.0.1 solution to 1.1.0 now, the standard Git deployment to Azure succeeded - but, when trying to access the site I got a 502.3 back.

The only way to fix this as far as I've found so far is to use the advanced tools in the Azure portal to fully clean out the site-folder and then do the deploy.
After this is done once, it will work. Seems like old versions of certain SDK files are left behind after a deploy.

It also works you do a publish from VS and enable "Remove additional files".

This is a great illustration of what I dislike about the deployment model that Azure Web Apps encourage: your deployment to production entails running a build in an environment that can change at any time, meaning you've got no way of knowing whether a deployment to production will work in the same way as your last deployment to a test environment.

It's possible to avoid this, but Azure really doesn't make things easy for you if you go that way. My preferred approach is to perform the build on a build server (usually one I control, although at least if you use a VSTS (formerly Visual Studio Online) hosted build Microsoft documents exactly what's installed and it's fairly easy to find out when changes are coming), and then to deploy the artifacts produced by that build to the Web App. This way you can be confident that the thing you're pushing to production is actually the same thing you tested - you deploy exactly the same compiled artifacts in each case, rather than running a whole new build each time. But rather astonishingly, the VSTS Integration in Azure Web Apps doesn't work that way - as with going via a git repo, it assumes that you want App Service to do your build. There's no way to tell an App Service to deploy the output of a VSTS build.

And if you set up a working Release pipeline in VSTS, there's no good way to see what's currently deployed. With old-school Cloud Services there was a thing called a deployment label, which was just a bit of text you could set to whatever you want, and which you could see in the portal when looking at a slot, and I usually put the build number and branch name in there so it was easy to see what was deployed. With App Services there's no such thing, and if you're using deployment slots, there's no straightforward way to see what's in which slot, so if you swap slots manually it's very easy to forget whether you've done it... I generally now automate slot swapping as part of my release process, but the problem with that is you never get to see any of the warnings the Azure Portal would show you if you've done something potentially dangerous (e.g., mismatched config settings).

What's particularly aggravating is that it *is* easy to see what's deployed if you let App Service build from source for you (because the Deployments blade will show you what's currently deployed) but that doesn't work if you drive deployments from VSTS or Team City or whatever. (There are workarounds of course - you can have your deployment process supply an Application Setting in the web app that states the build number, for example, but it seems a bit of a hack, particularly since there's that Deployments page there for precisely this purpose but which doesn't work in this scenario.)

The deploy-from-source model is great for static sites, because there's nothing to compile in that case, and it's beautifully simple. But for anything else it seems too much like a toy, and it's frustrating that there's not great support for more solid approaches.

To your attention a very good app to watch movies online on Android devices Showbox online . Broadcast of the films is from several sites. Loved the rich array of themes movies. The films are presented in different quality, it is very convenient.