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

Respect deps json #7490

Closed
wants to merge 3 commits into from
Closed

Conversation

Forgind
Copy link
Member

@Forgind Forgind commented Mar 25, 2022

Fixes #4081 and #1887; progress towards #5037

Context

MSBuild doesn't currently respect .deps.json files for plugins (tasks). This can lead to incorrect versions of assemblies being found as finding the AnyCPU version of an assembly instead of the windows-specific version.

Changes Made

Use AssemblyDependencyResolver as a second pass (after looking for "well-known assemblies") to automatically use the deps.json file to find the right assembly.

Testing

Verified that for a task assembly with a rid-specific dependency, it finds the rid-specific dependency as specified by the deps.json file. Also verified that it can find native assemblies and that the issue that inspired this (dotnet/sdk#23498) no longer reproduces after giving nuget a .deps.json file specifying the correct version.

@Forgind
Copy link
Member Author

Forgind commented Apr 4, 2022

What I've found:
The failing test is LoadNonExistingAssembly]()
Unsurprisingly, it fails on Core. When I ran tests locally, it only failed on net6.0. It surprised me for a moment that windows full would fail; apparently it also runs net6.0 tests. (I think we should change that.)

With my local debugging, it seems to be failing when it tries to create an AssemblyDependencyResolver, and the AssemblyPath doesn't exist:
System.InvalidOperationException: Dependency resolution failed for component --> Detailed error: Failed to locate managed application

I was able to make the test pass by only making or using the AssemblyDependencyResolver if assemblyPath exists.

@rainersigwald
Copy link
Member

It surprised me for a moment that windows full would fail; apparently it also runs net6.0 tests. (I think we should change that.)

That is the "official build configuration" and I think it should definitely run all tests. The only differences between windows/full and windows/core are whether we build with dotnet build or msbuild.exe, and I think that's a reasonable goal to preserve.

@Forgind Forgind closed this Apr 5, 2022
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

Successfully merging this pull request may close these issues.

Consider adopting ComponentDependencyResolver for tasks on Core
2 participants