Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error

Xunit.v3 analysis failure
damianh
#1 Posted : Saturday, September 28, 2024 10:51:08 AM(UTC)
Rank: Member

Groups: Registered
Joined: 5/5/2014(UTC)
Posts: 23
Location: Netherlands

Thanks: 2 times
Was thanked: 4 time(s) in 4 post(s)
When attempting to use xunit.v3 (Version="0.4.0-pre.20") get analysis failure:

An error occurred while analysing this project after it was built: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.
---> System.MissingMethodException: Method not found: 'System.Collections.Generic.HashSet`1<System.String> Xunit.Runner.Common.XunitFilters.get_IncludedClasses()'.
at Xunit.Runner.v3.Xunit3ArgumentFactory.ToArguments(Version coreFrameworkVersion, String configFileName, String culture, Nullable`1 diagnosicMessages, Nullable`1 disableParallelization, Nullable`1 explicitOption, Nullable`1 failSkips, Nullable`1 failTestsWithWarnings, XunitFilters filters, Nullable`1 internalDiagnosticMessages, Nullable`1 listOption, Nullable`1 maxParallelThreads, Nullable`1 methodDisplay, Nullable`1 methodDisplayOptions, Nullable`1 parallelAlgorithm, Nullable`1 preEnumerateTheories, Nullable`1 seed, IReadOnlyCollection`1 serializedTestCases, Nullable`1 stopOnTestFail, Nullable`1 synchronousMessages, Boolean waitForDebugger)
at Xunit.Runner.v3.Xunit3ArgumentFactory.ForFind(Version coreFrameworkVersion, ITestFrameworkDiscoveryOptions options, XunitFilters filters, String configFileName, Nullable`1 listOption, Boolean waitForDebugger) in C:\Projects\3rdparty\xunit\src\xunit.v3.runner.utility\Frameworks\v3\Xunit3ArgumentFactory.cs:line 31
at Xunit.Runner.v3.Xunit3.Find(IMessageSink messageSink, FrontControllerFindSettings settings) in C:\Projects\3rdparty\xunit\src\xunit.v3.runner.utility\Frameworks\v3\Xunit3.cs:line 102
at System.RuntimeMethodHandle.InvokeMethod(Object target, Void** arguments, Signature sig, Boolean isConstructor)
at System.Reflection.MethodBaseInvoker.InvokeDirectByRefWithFewArgs(Object obj, Span`1 copyOfArgs, BindingFlags invokeAttr)
--- End of inner exception stack trace ---
at System.Reflection.MethodBaseInvoker.InvokeDirectByRefWithFewArgs(Object obj, Span`1 copyOfArgs, BindingFlags invokeAttr)
at System.Reflection.MethodBaseInvoker.InvokeWithFewArgs(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)
at nCrunch.Module.XUnit3.ReflectionWrapper.Xunit3.Find(Object messageSink, FrontControllerFindSettings settings)
at nCrunch.Module.XUnit3.XUnit3DiscoveryEnvironment.FindFrameworkTestsInAssembly(ReflectedAssembly assembly, FilePath assemblyFilePath, IList`1 referencedAssemblyFilePaths, ComponentUniqueName testComponentUniqueName, PlatformType platformType, DynamicProxy[] dynamicProxies)
at nCrunch.TestExecution.TestFinder..()
at nCrunch.Common.PerformanceTracking.PerfTracker.TrackActivity(String name, Action activity)
at nCrunch.TestExecution.TestFinder..()
at nCrunch.Common.PerformanceTracking.PerfTracker.TrackActivity(String name, Action activity)
at nCrunch.TestExecution.TestFinder.FindTestsForFrameworks(ReflectedAssembly assembly, FilePath assemblyFilePath, IList`1 referencedAssemblyFilePaths, DescribedTestFrameworkDiscoverer[] describedDiscoverers, ComponentUniqueName testComponentUniqueName, PlatformType platformType, DynamicProxy[] dynamicProxies)
at nCrunch.TestExecution.RemoteTaskRunner.AnalyseAssembly(DescribedTestFrameworkDiscoverer[] applicableFrameworks, ComponentUniqueName testComponentUniqueName, PerfTracker perfTracker, TaskLogId taskLogId)


The tests are discovered and run in VS test runner and resharper test runner.
Remco
#2 Posted : Saturday, September 28, 2024 1:14:05 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,177

Thanks: 967 times
Was thanked: 1298 time(s) in 1203 post(s)
Thanks for sharing this issue.

This is caused by an inconsistency between the xunit runner libraries that are packaged with NCrunch, and the xunit runtime libraries referenced from your test project.

Basically, the main xunit Nuget package doesn't ship with the runner libraries, so it's the responsibility of runners (like NCrunch) to provide them. The current set of binaries packaged with NCrunch is consistent with xunit 0.3.0-pre.18, which seems to have a clash with 0.4.0-pre.20. The reason for this is because we finalised our integration with xunit about 2-3 weeks ago, at which point 0.3.0-pre.18 was the latest version. The smart move would have been for us to update our binaries just prior to our own release ... but of course, we forgot to do that. So when NCrunch v5.10 went out yesterday it was already out of alignment with the latest pre-release of xunit.

Because it's expected that xunit is likely to still see changes like this while in a PR state, we did try to implement forwards compatibility with future versions of the libraries, but depending on the versions involved, you may still need to have the runner library versions match those of the runtime ones. NCrunch has a built-in override through which it will always use the runner libraries being referenced by your project before using the ones packaged with itself. To use this override, you'll need to have your own copies of these runner libraries:

xunit.v3.common.dll
xunit.v3.runner.common.dll
xunit.v3.runner.utility.netcore.dll or xunit.v3.runner.utility.netfx.dll (depending on your platform)
xunit.v3.runner.inproc.console.dll

They need to be referenced directly from the project to work. I don't think there is a Nuget reference available for these yet, so it would probably need to be done using a <Reference Include="AssemblyName.dll" /> inside the project file (i.e. old school assembly reference). I've just checked quickly and it looks like it might take a few steps to get hold of these files. You might need to build them from source.

Alternatively, you can use a slightly older version of xunit, v0.3.0-pre.18, which should work just fine.

We'll update our own copies of the binaries the next time we push a build.
damianh
#3 Posted : Saturday, September 28, 2024 1:18:09 PM(UTC)
Rank: Member

Groups: Registered
Joined: 5/5/2014(UTC)
Posts: 23
Location: Netherlands

Thanks: 2 times
Was thanked: 4 time(s) in 4 post(s)
Thanks.for the detailed response.

I'll downgrade to 0.3.0-pre.18 for now and will upgrade on next ncrunch build.

Cheers!
anemitoff
#4 Posted : Thursday, December 12, 2024 1:55:30 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 11/4/2017(UTC)
Posts: 2
Location: United States of America

The release notes for version 5.11.0.1 say " Xunit runner DLLs are now resolved via the Nuget package cache".
I have a solution with a number of projects and test projects.
Some of my test projects upgraded to use xUnit.v3 (0.7.0-pre.15) work fine with NCrunch and some give me the error


The assembly was expected at the following path:
...\AppData\Local\NCrunch\12332\18\DEV\OphthalmologyApp\xunit.v3.core\bin\_content\runners\netcore\xunit.v3.runner.utility.netcore.dll

Actually the "xunit.v3.core" folder does not exist.

The .csproj files look the same as far as PropertyGroup and PackageReferences.

Any help would be appreciated.
anemitoff
#5 Posted : Thursday, December 12, 2024 3:43:03 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 11/4/2017(UTC)
Posts: 2
Location: United States of America

I tried clearing and restoring my NuGet packages.
Now, the same project analyses are still failing with the same error. And I have an additional error in Tests window "Unable to Restore required NuGet Packages"
Remco
#6 Posted : Thursday, December 12, 2024 10:22:42 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,177

Thanks: 967 times
Was thanked: 1298 time(s) in 1203 post(s)
NCrunch tries to load the Xunit assemblies relative to xunit.v3.core. This means that if you've referenced xunit.v3.core via assembly reference (and not through the Nuget package), it will try to find them in the wrong place.

Can you show me how you're referencing xunit.v3.core? Note that if you're using the assembly reference method to force resolution logic, you'll need to do the same for all the Xunit binaries.
DCasado
#7 Posted : Tuesday, January 7, 2025 4:57:12 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 10/2/2024(UTC)
Posts: 4

I'm currently trying also to use xunit v3 but got the same experience as anemitoff.

I have many test projects inside my solution, nearly all of them are working fine but two of them are failing with the error:

"An error occurred while analysing this project after it was built: Unable to resolve an assembly required for the execution of Xunit3 on this machine. The assembly was expected at the following path: ...\AppData\Local\NCrunch\23652\463\PlanningEngine\xunit.v3.core\bin\_content\runners\netcore\xunit.v3.runner.utility.netcore.dll
Please ensure the package containing this assembly is installed on your machine. If you introduce an assembly reference directly to this binary in your test project, NCrunch will resolve it directly using your specified path."

xunit is referenced by

<PackageReference Include="xunit.v3" Version="1.0.0" />

Any help would be appreciated.
Remco
#8 Posted : Wednesday, January 8, 2025 4:23:24 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,177

Thanks: 967 times
Was thanked: 1298 time(s) in 1203 post(s)
DCasado
#9 Posted : Wednesday, January 8, 2025 7:11:00 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 10/2/2024(UTC)
Posts: 4

I can confirm that my two projects are configured with 'Copy reference assemblies to workspace'. Unfortunately I need this setting for my tests.

I installed your new version now and it seems that the problem still exists.
Now I don't get a an analysis failure on project level as before, but on every test execution. So NCrunch Test Explorer is now able to discover all the tests, but they are failing with the same error message at test level now:


"Unable to resolve an assembly required for the execution of Xunit3 on this machine. The assembly was expected at the following path: C:\Users\CasadoDaniel\AppData\Local\NCrunch\24764\85\Common\xunit.v3.core\bin\_content\runners\netcore\xunit.v3.runner.utility.netcore.dll
Please ensure the package containing this assembly is installed on your machine. If you introduce an assembly reference directly to this binary in your test project, NCrunch will resolve it directly using your specified path."

Remco
#10 Posted : Wednesday, January 8, 2025 12:29:56 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,177

Thanks: 967 times
Was thanked: 1298 time(s) in 1203 post(s)
I can't seem to reproduce the problem anymore after introducing the above fix.

Are you able to reproduce it using a sample project that you can share with me? You can upload small projects to me in ZIP form through the NCrunch contact form.

Edit: Scratch that, sorry, I've managed to reproduce it now. It looks to be something to do with the test process life cycle. I'll let you know when I have a fix available.
DCasado
#11 Posted : Wednesday, January 8, 2025 4:12:49 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 10/2/2024(UTC)
Posts: 4

I doesn't know if this is related or not.

But I refactored my solution so that 'Copy reference assemblies to workspace' is not needed anymore. Most of my tests are working now, but some are still failing with following exception:


System.TypeInitializationException: The type initializer for '' threw an exception.
at ..ctor(Presentation )
at ..ctor(TextFrame )
at Aspose.Slides.TextFrame..ctor( )
at Aspose.Slides.AutoShape.()
at .(Presentation )
at .(Presentation )
at Aspose.Slides.Presentation..ctor(LoadOptions loadOptions)
at Aspose.Slides.Presentation..ctor()
...
at System.RuntimeType.CreateInstanceDefaultCtor(Boolean publicOnly, Boolean wrapExceptions)
System.DllNotFoundException: Unable to load DLL 'aspose.slides.drawing.capi_vc14x64' or one of its dependencies: The specified module could not be found. (0x8007007E)
at System.Runtime.InteropServices.NativeLibrary.LoadLibraryByName(String libraryName, Assembly assembly, Nullable`1 searchPath, Boolean throwOnError)
at .(String , Assembly , Nullable`1 )
at System.Runtime.InteropServices.NativeLibrary.LoadLibraryCallbackStub(String libraryName, Assembly assembly, Boolean hasDllImportSearchPathFlags, UInt32 dllImportSearchPathFlags)
at .d(Int32 d, Int32 v, Int32 c, IntPtr& t)
at System.Drawing.Bitmap..ctor(Int32 width, Int32 height, PixelFormat format)
at System.Drawing.Bitmap..ctor(Int32 width, Int32 height)
at ..cctor()


All those tests are running without any problems with Visual Studio Test Explorer. So it seems related to NCrunch.

I tried to reproduce this in a small project, but here it is working fine :(

https://github.com/IT-CA...TestLibrary1.csproj#L10

For the test project Aspose.Slides is a transitive reference by project 'LibTest1'
DCasado
#12 Posted : Wednesday, January 8, 2025 9:43:56 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 10/2/2024(UTC)
Posts: 4

It seems that my problem is gone away after a machine reboot. Could be a caching issue with NCrunch...
Remco
#13 Posted : Thursday, January 9, 2025 12:26:18 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,177

Thanks: 967 times
Was thanked: 1298 time(s) in 1203 post(s)
I've implemented another fix for the Xunit DLL resolution issue in the build below, I'm hoping this solves the problem completely:
NCrunch_Console_5.12.0.5.msi
NCrunch_Console_5.12.0.5.zip
NCrunch_GridNodeServer_5.12.0.5.msi
NCrunch_GridNodeServer_5.12.0.5.zip
NCrunch_LicenseServer_5.12.0.5.zip
NCrunch_Rider_5.12.0.5.7z
NCrunch_Rider_5.12.0.5.zip
NCrunch_VS2010_5.12.0.5.msi
NCrunch_VS2010_5.12.0.5.zip
NCrunch_VS2012_5.12.0.5.msi
NCrunch_VS2012_5.12.0.5.zip
NCrunch_VS2013_5.12.0.5.msi
NCrunch_VS2013_5.12.0.5.zip
NCrunch_VS2015_5.12.0.5.msi
NCrunch_VS2015_5.12.0.5.msi.7z
NCrunch_VS2015_5.12.0.5.zip
NCrunch_VS2017_5.12.0.5.msi
NCrunch_VS2017_5.12.0.5.msi.7z
NCrunch_VS2017_5.12.0.5.zip
NCrunch_VS2019_5.12.0.5.msi
NCrunch_VS2019_5.12.0.5.msi.7z
NCrunch_VS2019_5.12.0.5.zip
NCrunch_VS2022_5.12.0.5.msi
NCrunch_VS2022_5.12.0.5.msi.7z
NCrunch_VS2022_5.12.0.5.zip


The problem you're encountering with the runtime assembly resolution looks to be related to a native binary. Native binaries don't go through the MSBuild assembly reference resolution system, so they usually need to be included in your project as a copylocal resource. As long as the native binary is copied to the output directory of the project making use of it, the resolution should pass. The intermittent nature of this problem could be related to the resolution path of the binary. For example, there may be two projects that use it directly, but only one has it in the output directory.
Users browsing this topic
Guest
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

YAF | YAF © 2003-2011, Yet Another Forum.NET
This page was generated in 0.103 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download