Runtime: ArrayPool.Shared.Rent not working on .NET 4.7.1 (needs: 'netstandard, Version=2.0.0.0)

[Tornhoof]

As soon as I migrate my project to .NET 4.7.1, I get the following error:

The type 'Object' is defined in an assembly that is not referenced. You must add a reference to assembly 'netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'.

Steps to reproduce:

1. Create console project targeting .NET 4.7.1 (use new SDK project format)
2. Add Nuget Package System.Buffers 4.4.0
3. Add code using ArrayPool, e.g. var buffer = ArrayPool<byte>.Shared.Rent(4096);
   

   Expected result

Builds

Actual result

Error message

Repro:
ObjectNotFound.zip

[vbaderks]

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

[danmosemsft]

@AlexGhiondea ?

[Tornhoof]

<HasReferenceToSystemRuntime> did not solve it for me, adding the Runtime Nuget package <PackageReference Include="System.Runtime" Version="4.3.0" /> did solve it for me.

[karelz]

@safern can you please take a look? It looks scary.

[safern]

Yes it kind of looks scary. I’ll take a look as soon as I can. I’m out tomorrow but definitely on Monday I’ll take a look.

[Macromullet]

I'm getting this when trying to build on our VSTS on-prem agent after upgrading the solution to .net 4.7.1. It builds just fine in 15.5 preview 1 on my box (haven't tried 15.4). It was building fine before updating to .net 4.7.1 (we were targeting 4.6.1). After update, and installing the 4.7.1 dev pack, I get this on all .net assemblies that target .net 4.7.1 and have .net standard refs and are classic projects, IE
<TargetFrameworkVersion>v4.7.1</TargetFrameworkVersion>

Projects that I converted to CPS that use
<TargetFramework>net471</TargetFramework>

Seem to compile just fine.

[Macromullet]

So I went back and built with 15.4 and got the same error, so I think it's MSBuild, in particular this issue:
https://github.com/Microsoft/msbuild/pull/2567

It appears to have been merged into 15.5.113, which is why it makes sense it compiles on the 15.5 preview version I have. I'm about to install that on the build agent and will follow up.

[Tornhoof]

Using <_HasReferenceToSystemRuntime>true</_HasReferenceToSystemRuntime> in the project solves this, I previously had the wrong name (without '_'). So I think you're correct and this is actually Microsoft/msbuild#2567

[Tornhoof]

@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%20Apps%20targeting%20.NET-4.6.1%20that%20use%20.NET%20Standard%20libraries%20might%20be%20broken%20when%20running%20on%20.NET%204.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?

[safern]

@joperezr is this related with the issue that you where looking at? Seems to be.

@Tornhoof sorry that you’re having this bad experience, we’re always trying to make the product better and obviously our intention is not to make it worse. This was definitely something that slip of our hands but seems to be a known issue that we’re already investing a lot to get it fixed. We will keep you posted on any updates we have in this.

[jnm2]

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! ❤️

[Macromullet]

I don't want to pile on, but I agree the delivery of this has been sub-par. The release notes for 4.7.1 made it seem like this would be a drop-in replacement that just simplified the delivery strategy for .net standard 2.0/.net framework mixed usage scenarios, and yet we are back working with beta build agents and tools trying to get the entire thing compiling. It's not really release if you need beta software to get it to work, right?

[karelz]

@jnm2 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.

Why do you think we knew about the problem before 4.7.1 shipped? To my knowledge we learned one
day before FCU with 4.7.1 went public that ValueTuple is busted. We didn't have any way to fix the release at that point.
I am not trying to downplay the impact, but the above accusation is not correct.

[jnm2]

@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.

[gulbanana]

very unlucky timing :(

[mkosieradzki]

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.

[safern]

After investigating I found that this issue is a dupe of: https://github.com/Microsoft/msbuild/issues/2199 and it was a SDK tooling issue, the fix was made in: https://github.com/Microsoft/msbuild/pull/2567 so that being said we can close this issue.

I validated locally and with that fix it works fine.

As a temporary workaround setting either one of these:

<DependsOnSystemRuntime>true</DependsOnSystemRuntime>

or as previously mentioned

<_HasReferenceToSystemRuntime>true</_HasReferenceToSystemRuntime>

in your .csproj should fix the issue.

cc: @dsplaisted @livarcocc

[AlexGhiondea]

@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.

[Entroper]

To be clear, that setting in the .csproj file goes under a property group. For example:

<PropertyGroup>
  <_HasReferenceToSystemRuntime>true</_HasReferenceToSystemRuntime>
  <ApplicationIcon>WarMECH.ico</ApplicationIcon>
</PropertyGroup>

This also fixed the issue for me.

[rlordcardano]

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