@karelz How can we improve the current experience with Visual Studio and .NET Standard 2.0 on netfx? Currently it is kinda sub-optimal. Let me revisit the current situation:

It all started with the VS 15.3 update. Suddenly existing applications stopped working/building/updating because of binding redirect errors, see https://github.com/dotnet/corefx/issues/23306 et.al., later @terrajobst created a doc to explain it, https://github.com/dotnet/standard/issues/481 The gist out of it was with .NET 4.7.1 many of the problems should go away, because it supports .NET Standard 2.0 oob.

Now .NET Framework 4.7.1 was released, several problems popped up immediately

• https://github.com/dotnet/corefx/issues/24716 (this bug)
• https://github.com/dotnet/corefx/issues/24653 (value tuple) which resulted in the rather scary document https://github.com/Microsoft/dotnet/blob/master/releases/net471/KnownIssues/510901-BCL Apps targeting .NET-4.6.1 that use .NET Standard libraries might be broken when running on .NET 4.7.1.md
• Redirect warnings again: https://github.com/dotnet/project-system/issues/2905

Those are only the issues I was more or less involved with.

From my point of view the problems only get bigger with every release and I actively follow the .NET development, appropriate persons on Twitter and Github to keep informed.

So what can we do to improve the situation?

• Are you missing test projects targeting the full framework with e.g. ASP.NET Core 2.0 or the new project format.
• e.g. Microsoft/msbuild#2567 was fixed a ~3 weeks ago, @dsplaisted even wrote it’s necessary for .NET Standard 2.0 to work with .NET Framework 4.7.1, but you didn’t release an update in time for VS 15.4, atleast 15.4.1 did not include it, nor could I find documentation about it.

After VS 15.3, I started installing the preview versions of VS (side-by-side), but I currently have issues installing early access frameworks, as they directly impact my development system and my solutions are rather annoying to open in VMs due to size and it’s quite hard to tell at the moment if problems with my solution happen due to VM slowness or problems with VS. We all know that the experience with VS 15 is not perfect at the moment.

So what do you suggest on how we can help so we can improve the current experience?

The root cause is that the process of releasing new framework version is flawed today. I have discovered and reported the original issue immediately when FCU appeared in the Release Preview ring and it was 3 days before FCU was released officially. During previous releases it was sometimes even a month.

So from the practical standpoint there was no way to test the apps before the release.

Microsoft definitely needs to increase the delay between Release Preview and Release or provide any other practical means for developers to widely test their software for compatibility with the new .NET Framework version before making the release.

There are limits of amount of preview software a developer can use in their computer. I don’t believe many developers are interested in installing slow/fast ring versions of Windows,

Also: not many developers are currently interested in early adoption of the new .NET Framework versions, because they acquire new features through the channels like nuget/.NET Standard/.NET Core and new .NET Framework alone has not much to offer to the developers.

which resulted in the rather scary document

That’s understating it. It’s impossible to use certain libraries and target .NET Framework earlier than 4.7.1 without the app ceasing to work if the customer gets the fall update. All this in-box vs out-of-box stuff is amazing but you need to ship better assembly binding intelligence at runtime first or you put us in an impossible situation.

What baffles me is that you knew positively that shipping 4.7.1 would break customers of our products without a scalable mitigation and you shipped anyway. So much for compatibility quirking!

Correction: @karelz indicates that the team had actually shipped 4.7.1 before seeing that issue and knowing something was wrong. I apologize! ❤️

Had the same problem, for me adding <_HasReferenceToSystemRuntime>true</_HasReferenceToSystemRuntime> to my .csproj solved the issue?

Perhaps useful for people struggling with this: the _HasReferenceToSystemRuntime route worked for us as well, the DependsOnSystemRuntime that was mentioned does not.

@mkosieradzki we are looking into how we can increase the cadency of our early access preview which should give more time for our customers to try the bits, give us feedback and allows us time to fix the issues they report.

very unlucky timing 😦

@karelz I read the Fall creators update is going live in two days. Heads up! on the 14th and the update was live the 17th, which is when I understood 4.7.1 shipped. I thought, wow, seriously good thing they caught that one! Then I was significantly surprised when net471 shipped with the fall update with an ineffective workaround published beside it. I thought that meant you’d have known about it for three days, but if you’d already shipped by then, none of what I said applies and I’m sorry for the inaccurate accusation.