-
Notifications
You must be signed in to change notification settings - Fork 174
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
System.Reflection.ReflectionTypeLoadException when running from test runner #15
Comments
Hi, |
On Pacco, if I pull, dotnet restore, and dotnet test under Pacco\Pacco.Services.Availability\tests\Pacco.Services.Availability.IntegrationTests the restore actually fails so I can't run the tests there. Is there working set of tests that are a good example of testing Convey services? |
I have a same issue. Projects Tests doesn't run because that. The exception
Here was reported this issue early, and still on error using vs 16.4.0. |
Hey, |
This seems to be an issue with Visual Studio and .NET Core 3.0 from the other posts that I'm seeing on it. It sounds like it has been resolved in certain versions and then regressed. It comes from calling
AppDomain.CurrentDomain.GetAssemblies()
I've only seen it complain about not being able to load Microsoft.IntelliTrace.Core but other Microsoft assemblies are being reported by others online. Again this runs just fine outside of a test runner but I need to be able to execute my tests. I was trying to follow the pattern used in Pacco.Services.Availability.IntegrationTests.Sync.GetResourceTests. If you just run them as is from the repo you should be able to repro this issue. I tried to fork and apply a potential workaround but am having trouble getting the dependencies to line up somehow. I got past the issue in Convey.CQRS.Commands.Extensions.AddCommandHandlers by forking, filtering the GetAssemblies call to those that contain a parameter for assemblyFilter. I tried the same for Convey.CQRS.Events.Extenstions.AddEventHandlers but I can't even build as the event signature doesn't show up meaning it must be still seeing an old version of that assembly somehow. Maybe from another package's reference. And alternative to supplying an assemblyFilter would be to just filter out the Microsoft assemblies as some are suggesting online as well. I'm just getting a lot of heat for having to comment out my unit tests and was hoping you guys could find a resolution to this. Maybe a more elegant solution would be to infer the namespace of the current app domain and use that to filter rather than having to supply the filter.
Please reply if you aren't able to repro using the Pacco solution test that I referred to as that would indicate that something else is amiss within my local environment.
The text was updated successfully, but these errors were encountered: