Integrate TestAssemblyLoadContext changes to version315 #1376
Conversation
|
@OsirisTerje - This is probably more complicated than I'm assuming you were expecting when you suggested raising this PR for If you do still want to go ahead with this, is there anything that I need to know around building/testing the changes that were done to the different packages files (cake/choco/msi)? |
|
I think we should try to move on with this. There are a comprehensive suite of tests in the console. Do all of them run? PS: I am on travel now, and my laptop doesnt have all the frameworks installed, and slow internet lines, so I can't check it. I also got some vulnerability warnings. |
OsirisTerje
changed the title
|
Okay, finally found a few minutes to troubleshoot this. Had to add some extra dependencies for .NET 5 and .NET 6. Verified tests all pass on Windows, I don't have any way to easily test on other platforms. Attached build/test log given the above command. |
veleek
changed the title
|
@OsirisTerje - Quick bump in case this you missed this one. |
|
Not missed, but lack of time. I need to work through the different changes you have done, to ensure the bugs in 3.16.X is not coming over. Even if you're pretty sure it is, a second look here should be done. |
|
Sounds good! Absolutely no pressure intended from my end. I'm not blocked in any way, just wanted to make sure it wasn't lost in the cracks (because I took so long for the original follow up). |
|
Cherry-picked from 3f854b2
Cherry picked from f11499a
Try to load assembly from trusted list, before to start using some complex logic and enumerate AdditinalFrameworkDirectories Improve logging for assembly resolving process
(cherry picked from commit f642e99)
Loading of unmanaged assemblies suffers from the same issues as loading managed assemblies in that the wrong deps.json is used by default. This updates the TestAssemblyLoadContext to use the exact same pattern for loading unmanaged assemblies as managed assemblies. 1. Use the default assembly loading logic (I'm unsure if we actually need this since, in both managed and unmanaged, the base AssemblyLoadContext logic is a no-op and it's actually the VM that has some logic for loading assemblies). 2. Use an AssemblyDependencyResolver for the test assembly. 3. Check in the same folder as the test assembly (in case the dependencies are not fully specified in deps.json). Resolves nunit#1253
veleek
force-pushed
the
veleek/native-assembly-resolve-v315
branch
from
696af74
to
87d6996
Compare
…hich were added/merged after this PR was created.
Okay, I just rebased this onto version3X and retargeted the PR. I had to make some extra changes because .NET 7 and 8 support were added, but everything seems to build and test fine now.
Is there some semi-automated way to do this? I got as far as figuring out how the nunit3-vs-adapter repo builds, and I feel like I would need to publish a NuGet package with my updated binaries, then rebuild the adapter and then pull it into a test project. I did the bare minimum testing and it seemed to work:
|
As per discussion in #1370, this change integrates all of the updates to TestAssembyLoadContext (nee CustomAssemblyLoadContext) from the
mainto theversion315branch. Unfortunately, there have been some changes to some of the packaging bits and pieces in order to add in the extra library used by TestAssemblyResolver, so I had to get those changes all merged as well.Here is the set of commits that touched
TestAssemblyLoadContext.csandTestAssemblyResolver.cs(from oldest to newest) and what I did to resolve them:3f854b2 - Manual resolution needed to deal with packaging changes due to new dependency.
f11499a - Do we need this change? I merged the modifications to TestAssemblyLoadContext but just ignored everything else related to project changes for extra tests.
485153d - Clean
b01ad3e - Clean
38d141e - Clean
462d9d2 - Clean