Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ValueTask defined in xunit.runner.visualstudio v3 causing conflict #431

Closed
6bee opened this issue Dec 20, 2024 · 5 comments
Closed

ValueTask defined in xunit.runner.visualstudio v3 causing conflict #431

6bee opened this issue Dec 20, 2024 · 5 comments

Comments

@6bee
Copy link

6bee commented Dec 20, 2024

Issue

Type conflict caused by ValueTask<> causes dynamic type resolution to fail.
The following two type definitions collide for tests executed on .NET Framework:

System.Threading.Tasks.ValueTask`1, System.Threading.Tasks.Extensions, Version=4.2.0.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51
System.Threading.Tasks.ValueTask`1, xunit.runner.visualstudio.testadapter, Version=3.0.0.0, Culture=neutral, PublicKeyToken=null

Potential Resolution

Would it be possible to used System.Threading.Tasks.Extensions package rather than defining your own ValueTask<>?

Background

aqua-core is a library that allows to serialize type information to be carried and re-created across application boundaries, different .net runtime and platform versions. Types defined in multiple locations (loaded into the default loading context) do contradict the concept and cannot be included in corresponding models. Hence, we're currently blocked from updating to xunit.runner.visualstudio.3.0.0.

@bradwilson
Copy link
Member

The reason you're seeing this is because the test adapter uses ILRepack so there is a private copy that's been repacked inside.

However, the more important question is: Why are you linking against xunit.runner.visualstudio.testadapter? Nobody should be doing that.

@6bee
Copy link
Author

6bee commented Dec 20, 2024

There is a package reference to xunit.runner.visualstudio for our unit test projects. No direct reference to xunit.runner.visualstudio.testadapter.
However, I suspect since we're using reflection to resolve types by full-name (not assembly-qualified-name), looking-up all loaded assemblies from AppDomain.CurrentDomain.GetAssemblies(), we end-up using System.Threading.Tasks.ValueTask<> from xunit.runner.visualstudio.testadapter assembly.

@bradwilson
Copy link
Member

bradwilson commented Dec 21, 2024

The issue is that we are forced by VSTest to copy all of our DLLs into your output folder. This is done outside the build process where, if we shared any dependencies, they could resolve those dependencies for us (because you're not actually linking against our runner DLL).

This is why we use ILRepack in the first place: any dependencies that we have need to become internalized or else we have a potential conflict problem (your version vs. our version). Additionally, ILRepack normally marks everything that's imported as internal instead of public, but it seems we have exposed some things publicly which consume/produce ValueTask<>, so it has left them public:

image

The visual difference here in ILSpy is subtle, but the types/namespaces which are public are black vs. the ones that are internal being gray.

I'll see if I can make some changes to what's left as public so that our version of ValueTask<> shows up as internal rather than public.

@bradwilson
Copy link
Member

Fix available in 3.0.1-pre.2 https://xunit.net/docs/using-ci-builds

I was able to reduce the public surface to just the one class that VSTest needs to find publicly, and the interfaces they define don't include ValueTask<>, everything should be good to go now. 👍🏼

image

@6bee
Copy link
Author

6bee commented Dec 22, 2024

This resolves our issue since we now can prioritize based on visibility.

Thank you so much @bradwilson for your responsiveness and the fix in such a short time. It is highly appreciated! ❤️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants