Runtime: System.MissingMethodException when using 4.5.0-preview2-* (and newer) library with master SDK

Created on 11 Apr 2018  路  18Comments  路  Source: dotnet/runtime

Valid repro: DirectoryRepro.zip

Execute repro with dotnet run -c Release.

Unhandled Exception: System.MissingMethodException: Method not found: 'System.ReadOnlySpan`1<Char> System.MemoryExtensions.AsSpan(System.String)'.
   at System.IO.Enumeration.FileSystemEnumerableFactory.NormalizeInputs(String& directory, String& expression, EnumerationOptions options)
   at System.IO.Directory.InternalEnumeratePaths(String path, String searchPattern, SearchTarget searchTarget, EnumerationOptions options)
   at DirectoryRepro.Program.Main() in /tmp/test4/Program.cs:line 9

I reproduced it on Windows as well as Linux. This issue did not happen previously with using 4.5.0-preview1-* library also on latest master SDK. I suspect some API incompatibility (probably not in the library being pulled, but one of its dependencies). If this is intended then how we're expected to use this library with latest master SDK?

Thank you in advance.

.NET Core SDK (reflecting any global.json):
 Version:   2.1.300-preview3-008443
 Commit:    1e2e8138b9

Runtime Environment:
 OS Name:     debian
 OS Version:
 OS Platform: Linux
 RID:         debian-x64
 Base Path:   /opt/dotnet/sdk/2.1.300-preview3-008443/

Host (useful for support):
  Version: 2.1.0-preview3-26404-01
  Commit:  1b1a652c15

.NET Core SDKs installed:
  2.1.300-preview3-008443 [/opt/dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.0-preview2-30431 [/opt/dotnet/shared/Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.0-preview2-30431 [/opt/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.0-preview3-26404-01 [/opt/dotnet/shared/Microsoft.NETCore.App]
area-System.Memory packaging tracking-external-issue

Most helpful comment

That PR went in and core-setup should now generate the version metadata for Microsoft.NETCore.App.deps.json deps in the next 2.1 build.

@weshaggard can we trigger a 2.1 release build to make this available asap?

All 18 comments

See previous issue for more context: https://github.com/dotnet/corefx/issues/28274

Since this issue is not reproducible on any sdk/package versions we have already shipped (nor on what's in master today), I am closing it. Feel free to re-open if that isn't the case.

On first glance, this looks like a duplicate of that one. However, it does look like the latest shipped preview2 packages are being used here (along with latest CLI from master). I will investigate further. Thanks for reporting it!

The workaround is likely to keep the versions in sync (rather than mixing and matching preview2/preview3).

Yes, this repro uses libraries that are publicly available on official nuget, only SDK is master but NOT the (project) libraries themselves. Thanks!

I discussed this with @ericstj, and it looks like an issue with the roll forward policy given the application is targeting netcoreapp2.0 when the dotnet SDK (from master) is for netcoreapp2.1.

A workaround for the issue is to add the following to the csproj:

<ItemGroup>
    <PackageReference Include="System.Memory" ExcludeAssets="All" Version="4.5.0-preview2-26406-04" />
</ItemGroup>

image

Steve, is this the expected behavior when a user is using the latest SDK to build a netcore 2.0 app?

cc @steveharter

The issue does not exist when the user's application targets netcoreapp2.1.

Although System.Memory.dll does contain MemoryExtensions.AsSpan, Span<T> lives in System.Memory for netcoreapp2.0 (but in System.Private.Corelib.dll for netcoreapp2.1). System.IO.Enumeration.FileSystemEnumerableFactory.NormalizeInputs expects Span<T> to be coming from System.Runtime.

image

The host is rolling forward the 2.0 app to run on the 2.1 shared framework but it isn't removing System.Memory.dll which has been moved into the shared framework in 2.1. This is a release blocking bug in the host.

This should be fixed once this is in: https://github.com/dotnet/sdk/pull/2118 and the framework's deps.json file is updated to add version numbers.

I verified this will work with @ahsonkhan by manually adding an "assemblyVersion" : "1.0.0" to the framework's deps.json file for that System.Memory.

adding 'tracking-external-issue' as SDK PR https://github.com/dotnet/sdk/pull/2118 will resolve this and there is no code changes required in the dotnet/corefx repo at this time.

@ahsonkhan once https://github.com/dotnet/sdk/pull/2118 is merged and a build is available, please verify and close.

@ericstj, that is the release/2.1 PR. Do you have a PR for master?

Not yet as it conflicts with versioning effort in master. The issue remains open and I鈥檝e mentioned what鈥檚 needed in master.

Update [4/24/2018] : https://github.com/dotnet/corefx/pull/29284 fixed the versioning in master. You still need the deps file updates to verify this change. For that to work you need the deps file changes in the shared framework.

The simple statement of workarounds are:

  1. Install .NET Core 2.0 since thats what you are targeting.
  2. Target .NET Core 2.1.

You still need the deps file updates to verify this change. For that to work you need the deps file changes in the shared framework.

~Using the latest 2.2 CLI from master (2.2.100-preview1-008633), we do not see this issue anymore.~

Edit: Nevermind, the issue still exists on master, if you don't have .NET Core 2.0 installed.

However, using an 2.1 RC build still fails (2.1.300-rc1-008662). Verification for the fix for 2.1 is blocked on https://github.com/dotnet/core-setup/issues/4082.

DirectoryRepro>....dotnet-8662dotnet.exe run -c Release

Unhandled Exception: System.IO.FileLoadException: Could not load file or assembly 'System.Memory, Version=4.1.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
   at System.IO.Enumeration.FileSystemEnumerableFactory.NormalizeInputs(String& directory, String& expression, EnumerationOptions options)
   at System.IO.Directory.InternalEnumeratePaths(String path, String searchPattern, SearchTarget searchTarget, EnumerationOptions options)
   at DirectoryRepro.Program.Main() in D:\Other\trash\DirectoryRepro\Program.cs:line 9

Note, we not longer get the System.MissingMethodException error, but instead System.IO.FileLoadException.

The FileLoadException is occurring now because the assembly in the app is lower than what鈥檚 expected by the shared framework. This is expected until the deps file is updated.

Still the same issue for 4.5.0-rc1.

Unhandled Exception: System.MissingMethodException: Method not found: 'System.ReadOnlySpan`1<Char> System.MemoryExtensions.AsSpan(System.String)'.
.NET Core SDK (reflecting any global.json):
 Version:   2.2.100-preview1-008636
 Commit:    6c9942bae6

Runtime Environment:
 OS Name:     debian
 OS Version:
 OS Platform: Linux
 RID:         debian-x64
 Base Path:   /opt/dotnet/sdk/2.2.100-preview1-008636/

Host (useful for support):
  Version: 2.1.0-preview3-26411-06
  Commit:  8faa8fcfcf

.NET Core SDKs installed:
  2.2.100-preview1-008636 [/opt/dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.0-preview2-30475 [/opt/dotnet/shared/Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.0-preview2-30475 [/opt/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.0-preview3-26411-06 [/opt/dotnet/shared/Microsoft.NETCore.App]

Still the same issue for 4.5.0-rc1.

The fix will require an SDK update (a package update isn't required).

The latest RTM build of the dotnet cli does not have the fix yet. https://github.com/dotnet/versions/tree/master/build-info/dotnet/product/cli/release/2.1#built-repositories

dotnet/sdk on 'refs/heads/release/2.1.3xx' (3c8b1f956b53d5e4e4580430925cc7c8dae1cbb6)

I don't see the assembly and file versions in the Microsoft.NETCore.App.deps.json deps file (within dotnetcli\shared\Microsoft.NETCore.App\2.1.0-rtm-26508-02)

There is investigation on going here: https://github.com/dotnet/core-setup/issues/4082#issuecomment-386738404

We will keep this issue open to track validation of the deps file once we get a full SDK that includes this.

That PR went in and core-setup should now generate the version metadata for Microsoft.NETCore.App.deps.json deps in the next 2.1 build.

@weshaggard can we trigger a 2.1 release build to make this available asap?

I have verified that we no longer see any error using the latest RTM dotnet cli/sdk: 2.1.300-rtm-008833, with Microsoft.NETCore.App version 2.1.0-rtm-26510-03 (regardless what library version your project is referencing: 4.5.0-preview2-26406-04 or 4.5.0-rc1).

This issue is no longer blocking release.

.NET Core 2.2. dotnet/cli master (2.2.100-preview1-008854) has an out-dated .NET Core runtime (Microsoft.NETCore.App 2.1.0-rtm-26505-04), and hence still has the issue. We should update the cli master to point to the latest available shared runtime.

Also, we need to update the versions repo, which still lists rtm-008823 as latest (rather than rtm-008833):
https://github.com/dotnet/versions/blob/476bf6db689722a99f15fce3cfb00cb993b29f2f/build-info/dotnet/cli/master/Latest.txt#L1

cc @livarcocc, the last update was 3 days ago.

Verified that this issue has been fixed using the latest master dotnet cli: 2.2.100-preview1-008905

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.0-rtm-30752 [D:\Other\dotnet-8905\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.0-rtm-30752 [D:\Other\dotnet-8905\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.0-rtm-26514-02 [D:\Other\dotnet-8905\shared\Microsoft.NETCore.App]

Closing.

I can confirm that I'm no longer seeing this issue with above release.

Thanks!

Was this page helpful?
0 / 5 - 0 ratings