microsoft
Invalid .NET 10 MissingMethodException with specific SDK versions
Issue from https://github.com/dotnet/runtime/issues/113302. We sadly cannot transfer issues across orgs.
The gist of the problem is that if a test relies on a NETStandard2.0 library that exposes types that were later inboxed in .NETFramework, that test will face type unification problems when running on mono.
The root cause is that the TestHostNetFramework contains one jumble of assemblies shared for multiple versions of .NET framework. Contrast that to what's actually provided to projects targeting these frameworks by Microsoft.NET.Build.Extensions where each framework gets the appropriate assemblies to unify types correctly. Notice how there exists both a C:\Program Files\dotnet\sdk\9.0.200\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\System.ValueTuple.dll and C:\Program Files\dotnet\sdk\9.0.200\Microsoft\Microsoft.NET.Build.Extensions\net47\lib\System.ValueTuple.dll -- the latter must be used on net47 to ensure that the types unify with those in MSCorlib.
I can imagine a couple possible fixes for this problem.
- Stop shipping these assemblies entirely in the
TestHostNetFrameworkand let the test bring them if it needs them. - Segment the assemblies into subfolders so that multiple copies coexist, and specify them per-framework via the testhost.*.exe.config + probingPaths.
Interesting, @Youssef1313 I would hope that MTP is not failing in that case then. Could we test that?
I confirm that MTP works fine and it's VSTest-specific. @visschersm Thanks for providing a very minimal repro, accompanied with GitHub workflow that repro's the issue on GitHub Action. As the issue seems VSTest-specific, would it be an option for you to migrate over from VSTest to the newer Microsoft.Testing.Platform?
The migration process in many cases is:
-
Add the following to your Directory.Build.props
<PropertyGroup> <EnableMSTestRunner>true</EnableMSTestRunner> <TestingPlatformDotnetTestSupport>true</TestingPlatformDotnetTestSupport> <!-- Optional, you will find more info in docs --> <TestingPlatformCaptureOutput>false</TestingPlatformCaptureOutput> </PropertyGroup> -
Add
<OutputType>Exe</OutputType>to your test projects -
Update
dotnet testinvocations to account for the new way of doing it.
Meanwhile, I'll move to vstest repo and will let @nohwnd advise if this can be fixed.
First off all: Thank you for the response amazed by the level of detail! Learning a lot!
The issue for me was in a hobby project so luckily not a very big issue. Nevertheless finding it very interesting and hopefully it helps improving dotnet even more :)
@Youssef1313 I have added MTP in which the test passes as expected. Is MTP the advised way to run tests these days?
Do I understand the underlying issue correctly by stating that MTP does not use dll versions itself but just uses the versions brought by the code under test?
@ericstj
For libraries is it advised to build all the specific framework versions over using a shared .netstandard version? I am using it for some coditional compilation but I guess I could use the VERSION_OR_GREATOR as a replacement in those cases.
@visschersm thanks for the repro project, can you please update you microsoft.net.test.sdk to 17.14 preview from nuget?
https://www.nuget.org/packages/Microsoft.NET.Test.Sdk/17.14.0-preview-25107-01
There we upgraded the versions and started targeting just net8 and newer, hopefully solving the assembly mixup. I would try myself, but locally I cannot repro (as pointed out by you in the description)_, and you seem to already have the pipeline that consistently fails.
TY!
Is MTP the advised way to run tests these days?
The official stance is that it's a modern alternative to VSTest. Our team owning both platforms is really trying/hoping to have everyone moved over to the new platform. There are many benefits of performance, features and extensibility with the new platform (MTP).
Re-reading the thread and the logs, this is .net framework running on mono, as pointed aout above. So there was no change made, we only upgraded the versions of dependencies.
I don't think this will get fixed in vstest, unless there will be massive influx of this types of issues being reported 😔 I also don't think we can drop the dependency because some parts of the platform already use it.
For libraries is it advised to build all the specific framework versions over using a shared .netstandard version? I am using it for some coditional compilation but I guess I could use the VERSION_OR_GREATOR as a replacement in those cases.
I think you'll find multi-targeting to be a better tradeoff for consumption in actual applications. This is what we do for all libraries we build in dotnet/runtime. You can still target netstandard2.0 if you have consumers that you want to target netstandard2.0 but you'll get a better experience, particularly on older versions of .NETFramework, when multi-targeting.
Is MTP the advised way to run tests these days?
The official stance is that it's a modern alternative to VSTest. Our team owning both platforms is really trying/hoping to have everyone moved over to the new platform. There are many benefits of performance, features and extensibility with the new platform (MTP).
I managed to replace it and I am now using it in my hobby project. Testing against a bunch of dotnet versions on MSTest, NUnit and XUnit. All running on an ubuntu based action for dotnet framework 461 all the way to dotnet 10. Works like a charm. Will take the MTP message to my workplace since they are just starting with setting up there testing environments. Might aswell do it on the modern MTP :)
@visschersm thanks for the repro project, can you please update you microsoft.net.test.sdk to 17.14 preview from nuget?
https://www.nuget.org/packages/Microsoft.NET.Test.Sdk/17.14.0-preview-25107-01
There we upgraded the versions and started targeting just net8 and newer, hopefully solving the assembly mixup. I would try myself, but locally I cannot repro (as pointed out by you in the description)_, and you seem to already have the pipeline that consistently fails.
TY!
@nohwnd I just tried out 17.14.0-preview-25107-01 and it doesn't work.
Guess this was already done? Can do it in my repo if you still need it though.
Re-reading the thread and the logs, this is .net framework running on mono, as pointed aout above. So there was no change made, we only upgraded the versions of dependencies.
I don't think this will get fixed in vstest, unless there will be massive influx of this types of issues being reported 😔 I also don't think we can drop the dependency because some parts of the platform already use it.
I guess since I managed to migratie to MTP without any problems I should just use that instead?
Yes, using MTP you are better off, and thanks for adopting it!
-j
Od: Mark Visschers @.> Odesláno: Thursday, March 13, 2025 8:09:28 PM Komu: microsoft/vstest @.> Kopie: Comment @.>; Subscribed @.> Předmět: Re: [microsoft/vstest] Invalid .NET 10 MissingMethodException with specific SDK versions (Issue #15029)
Is MTP the advised way to run tests these days?
The official stance is that it's a modern alternative to VSTest. Our team owning both platforms is really trying/hoping to have everyone moved over to the new platform. There are many benefits of performance, features and extensibility with the new platform (MTP).
I managed to replace it and I am now using it in my hobby project. Testing against a bunch of dotnet versions on MSTest, NUnit and XUnit. All running on an ubuntu based action for dotnet framework 461 all the way to dotnet 10. Works like a charm. Will take the MTP message to my workplace since they are just starting with setting up there testing environments. Might aswell do it on the modern MTP :)
@visschersmhttps://github.com/visschersm thanks for the repro project, can you please update you microsoft.net.test.sdk to 17.14 preview from nuget?
https://www.nuget.org/packages/Microsoft.NET.Test.Sdk/17.14.0-preview-25107-01
There we upgraded the versions and started targeting just net8 and newer, hopefully solving the assembly mixup. I would try myself, but locally I cannot repro (as pointed out by you in the description)_, and you seem to already have the pipeline that consistently fails.
TY!
@nohwndhttps://github.com/nohwnd I just tried out 17.14.0-preview-25107-01 and it doesn't work.
Guess this was already done? Can do it in my repo if you still need it though.
Re-reading the thread and the logs, this is .net framework running on mono, as pointed aout above. So there was no change made, we only upgraded the versions of dependencies.
I don't think this will get fixed in vstest, unless there will be massive influx of this types of issues being reported 😔 I also don't think we can drop the dependency because some parts of the platform already use it.
I guess since I managed to migratie to MTP without any problems I should just use that instead?
— Reply to this email directly, view it on GitHubhttps://github.com/microsoft/vstest/issues/15029#issuecomment-2722427524 or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABLYLYLE3LFE3C5BKKIWTB32UHJWTBFKMF2HI4TJMJ2XIZLTSOBKK5TBNR2WLJDUOJ2WLJDOMFWWLO3UNBZGKYLEL5YGC4TUNFRWS4DBNZ2F6YLDORUXM2LUPGBKK5TBNR2WLJDUOJ2WLJDOMFWWLLTXMF2GG2C7MFRXI2LWNF2HTAVFOZQWY5LFUVUXG43VMWSG4YLNMWVXI2DSMVQWIX3UPFYGLLDTOVRGUZLDORPXI6LQMWWES43TOVSUG33NNVSW45FGORXXA2LDOOJIFJDUPFYGLKTSMVYG643JORXXE6NFOZQWY5LFVA3DENZXGQ3TENUCUR2HS4DFUVUXG43VMWSXMYLMOVS2UMRZGEYTEMBRHE4DBJ3UOJUWOZ3FOKTGG4TFMF2GK. You are receiving this email because you commented on the thread.
Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
@visschersm thanks for the nice feedback and yes please spread the word!!! Feel free to also say we are really eager to receive any feedback about MTP or MSTest (anything good, bad, missing... code, doc... anything really!).