)). I've learned some interesting things there and have connected with people who have helped me resolve some real head-scratchers.

Can't really speak to your second question since I haven't done enough deployment to Azure to note their release patterns or schedule.
<issue_comment>username_4: @username_2 any timeline on when Azure App Service will have 1.1.2? Running into the same issue.
<issue_comment>username_0: Also, *if* I wanted to roll back to 1.1.1, would I simply need to change the csproj -- everywhere there's a 1.1.2 change it to 1.1.1?

![1-1-2-rollback](https://cloud.githubusercontent.com/assets/19307883/26008447/6f618ac0-370a-11e7-9fd7-45f562364c33.png)
<issue_comment>username_1: Yes, that's correct. You also have `Microsoft.AspNetCore.Mvc` in there at version `1.1.3`. That's an example of how the various patch versions are still compatible, like @username_2 mentioned.

BTW, I love your project name :wink:
<issue_comment>username_2: @username_4 I believe the Azure rollout of the patch is scheduled for next week, though I don't have the exact dates.  @username_5?
<issue_comment>username_4: Next week is excellent!

Is it expected for Azure to lag on official releases like this? It makes it sort of dangerous to deploy if it's going to respond with a 502 after every minor release...
<issue_comment>username_5: It's already partially deployed (e.g. try in West US 2). It will complete Tuesday at the latest, but hopefully sooner.

And we'll work to avoid/minimize this situation in the future :)
<issue_comment>username_5: See also http://stackoverflow.com/a/43924403/111888
<issue_comment>username_4: Great @username_5 thank you.
<issue_comment>username_5: We have accelerated the deployment of 1.1.2 and 1.0.5 to App Service and it is now complete. So the workaround below should no longer be needed by anyone.

Apologies for the inconvenience this has caused.

@username_2, can you close?
<issue_comment>username_2: Thanks @username_5! Closing this bug, but if folks hit other issues, they should log another one.<issue_closed>
<issue_comment>username_6: @username_5 I wouldn't agree that the workaround is no longer needed by **anyone**. 

Not every app is deployed to Azure. I haven't used Azure once in my life :) I had the same issue today just because I've updated Visual Studio 2017 to version "15.2". After publishing the same unchanged app (that only has `<TargetFramework>netcoreapp1.1</TargetFramework>` but no `<RuntimeFrameworkVersion>` to a remote server which only has NETCore 1.1.1 installed, the production app broke, asking for 1.1.2. And I preferred to fix this by the workaround which @username_1 provided (much thanks!), because updating a framework on a production server requires admins, caution, some time, etc.. Also it's a very bad thing that the app broke by itself, just because I've updated Visual Studio, and this workaround mitigates/prevents this. I actually think that there still is a bug somewhere: if I only have netcoreapp1.1 specified and my server only has 1.1.1 it should not, under any circumstances, fail because it wants 1.1.2 for some reason. I'm not that familiar with the new NETCore toolset, so I don't completely understand which component is to blame here.
<issue_comment>username_2: @username_6 We have some plans in place to prevent this type of failure going forward, at least in the 2.x train.  @username_7 would have more information.
<issue_comment>username_7: Correct. We actually have a PR out right now for 2.0 and if/when we need to do this again in 1.0, we will port the fix there as well.
<issue_comment>username_8: I agree with @username_6 about always specifying a `<RuntimeFrameworkVersion>`. And I think it's bad practice not to use it.

When our systems go to production, they are completely tested and signed-off *for a specific version of everything*. We don't "pull latest sources" for.NET or npm packages and runtimes, or whatever, we hardcode the versions of all packages used by the system - because then that release is KNOWN TO WORK.

When you rely on implicit versions, for example by not using `<RuntimeFrameworkVersion>` then you get the problems others have mentioned above. So you need to choose versions explicitly, not implicitly.

When a new version of something is released, don't just "pull latest". You need to test that it works with what you have first. If it does, then manually update all versions. Then redeploy.

Only exception I guess, is if you are working on a "small" system, or maybe your team is small. Then you can cut corners with less risk.
<issue_comment>username_9: I encountered this issue today - adding <RuntimeFrameworkVersion>1.1.1</RuntimeFrameworkVersion> to *.csproj took care of it.

Not sure which link I followed to get the file originally, but DotNetCore.1.0.4_1.1.1-WindowsHosting.exe is still floating around.
<issue_comment>username_10: It sounds to me like if `<RuntimeFrameworkVersion>` is missing (which when creating a new project with the latest dotnet CLR it **is**) then it will automatically target 1.1.2 which is crazy to me, why is it like this?

## I was able to fix mine by adding:

```
<RuntimeFrameworkVersion>2.0</RuntimeFrameworkVersion>
```
<issue_comment>username_11: I've updated VS 2017 to 15.4.4 Yesterday and then one of my app targeting to 1.1 was not working anymore. I tried adding `<RuntimeFrameworkVersion>1.1.1</RuntimeFrameworkVersion>`
but it didn't help much.

So I went back to VS installer and found that VS has installed.net core 2.0 and put 1.1 in optional category. So i have to re-install that version.

<img width="1245" alt="vs-update" src="https://user-images.githubusercontent.com/7391319/33273244-b4900820-d3b2-11e7-92cd-57515cc65b72.png">

Hope this helps someone who face problem similar to me.
<issue_comment>username_12: @username_11 thanks this helped me!
<issue_comment>username_13: guys, this thing is completely crazy. Visual Studio updater is removing the current dotnet framewrok version. Are we sick? where the world is going to.
<issue_comment>username_2: @username_11 @username_12 @username_13 the VS issue is not directly related to the issue discussed here, though. Could you guys give the feedback through VS feedback tool?
<issue_comment>username_14: There is the same problem with my project, the workaround to resolve it successfully is that remove the item 'C:\Program Files (x86)\dotnet' from the Path of Environment Variable because I found I did not install the right netcore version under X86.  I have not tried to install the proper version with x86,  appreciate that you tell me if you have done that test.
<issue_comment>username_15: Happened to me and solved adding this line as @username_1 troubleshooting. Dunno but this line missed in my *.csproj.  

<RuntimeFrameworkVersion>1.1.1</RuntimeFrameworkVersion>.
<issue_comment>username_16: I fixed it by installing DotNetCore.1.0.5_1.1.2-WindowsHosting:
https://go.microsoft.com/fwlink/?linkid=848766

Source https://stackoverflow.com/questions/47349608/how-to-fix-microsoft-netcore-app-version-1-1-2-was-not-foundLife is a beautiful, capricious thing. One cannot deny the undeniable power that the feeling of being alive elicits; one can never take these things for granted. In his gorgeous new video for his song “Face the World,” which Atwood Magazine is proudly premiering today, Brandon Jenner seeks solace in living in the present and appreciating the small moments.
“Face the World” allows Jenner the opportunity to live as his most authentic self. In its lyricism, the song appreciates the little things, with Jenner elucidating our inherent smallness in this great big universe. He asks the universe in return to take mercy on