Skip to content

FsUnit.xUnit 7.0.0 Assembly Conflict with FsUnit.Xunit.exe #298

Closed

Description

@krymtkts

Description

Hi, I'm currently working with FsUnit.xUnit 7.0.0.
But I've encountered a problem when running dotnet test.
The issue seems to be related to a conflict between FsUnit.Xunit.exe and FsUnit.Xunit.dll that is included in the 7.0.0 nupkg.
7.0.0 seems to include FsUnit.Xunit.exe, while 6.0.1 does not include it.

Repro steps

  1. dotnet new xunit3 --language 'F#'
  2. dotnet test --verbosity diagnostic finished successfully.
  3. dotnet add package FsUnit.xUnit --version 7.0.0
  4. dotnet test --verbosity diagnostic finished in failure.

I tested this in my repo.

https://github.com/krymtkts/fsunit7

Expected behavior

dotnet test should finish successfully without any assembly resolution conflicts.

Actual behavior

dotnet test fails with the following error:

> dotnet test --verbosity diagnostic
C:\Program Files\dotnet\sdk\9.0.101\MSBuild.dll -nologo --property:VsTestUseMSBuildOutput=true -property:VSTestVerbosity=diagnostic -property:VSTestArtifactsProcessingMode=collect -property:VSTestSessionCorrelationId=18744_eacad426-d2f7-4b10-8fff-fd0d4dd7f7cf -distributedlogger:Microsoft.DotNet.Tools.MSBuild.MSBuildLogger,C:\Program Files\dotnet\sdk\9.0.101\dotnet.dll*Microsoft.DotNet.Tools.MSBuild.MSBuildForwardingLogger,C:\Program Files\dotnet\sdk\9.0.101\dotnet.dll -maxcpucount -restore -target:VSTest -tlp:default=auto -verbosity:m -verbosity:diagnostic .\fsunit7.fsproj
Restore complete (0.7s)
    Determining projects to restore...
    Restored C:\fsunit7\fsunit7.fsproj (in 379 ms).
  fsunit7 succeeded with 2 warning(s) (2.5s) → bin\Debug\net9.0\fsunit7.dll
    C:\Program Files\dotnet\sdk\9.0.101\Microsoft.Common.CurrentVersion.targets(2413,5): warning MSB3246: Resolved file has a bad image, no metadata, or is otherwise inaccessible. PE image does not have metadata. PE image does not have metadata.
    C:\Program Files\dotnet\sdk\9.0.101\Microsoft.Common.CurrentVersion.targets(2413,5): warning MSB3243: No way to resolve conflict between "FsUnit.Xunit, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" and "FsUnit.Xunit". Choosing "FsUnit.Xunit, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" arbitrarily.
Error:
  An assembly specified in the application dependencies manifest (fsunit7.deps.json) has already been found but with a different file extension:
    package: 'FsUnit.xUnit', version: '7.0.0'
    path: 'lib/net6.0/FsUnit.Xunit.exe'
    previously found assembly: 'C:\fsunit7\bin\Debug\net9.0\FsUnit.Xunit.dll'
Testhost process for source(s) 'C:\fsunit7\bin\Debug\net9.0\fsunit7.dll' exited with error: Error:
  An assembly specified in the application dependencies manifest (fsunit7.deps.json) has already been found but with a different file extension:
    package: 'FsUnit.xUnit', version: '7.0.0'
    path: 'lib/net6.0/FsUnit.Xunit.exe'
    previously found assembly: 'C:\fsunit7\bin\Debug\net9.0\FsUnit.Xunit.dll'
. Please check the diagnostic logs for more information.
  fsunit7 test failed with 1 error(s) (0.5s)
    C:\fsunit7\bin\Debug\net9.0\fsunit7.dll : error TESTRUNABORT: Test Run Aborted.

Build failed with 1 error(s) and 2 warning(s) in 4.3s

Known workarounds

Currently, I'm not shure how to resolve this.
If I could configure .fsproj to remove FsUnit.Xunit.exe section from bin/*/*/*.deps.json before dotnet test, that would be a workaround.

Related information

  • dotnet --version 9.0.101
  • TargetFramework: .NET 6 ~ .NET 9.0.101

Activity

  1. CaptnCodr commented on Dec 28, 2024

    @CaptnCodr
    Member

    Hey @krymtkts,
    could you try to remove the <OutputType>Exe</OutputType> from your project file and test again?
    Test projects usually don't have the OutputType.

    When this doesn't work I'll look into it in the next few days.

  2. krymtkts commented on Dec 28, 2024

    @krymtkts
    Author

    @CaptnCodr Thank you for the suggestion!
    I have removed the <OutputType>Exe</OutputType> from the project file and run dotnet test again, but unfortunately, the error still persists.

  3. CaptnCodr commented on Dec 28, 2024

    @CaptnCodr
    Member

    Thank you for testing. I'll look into it.

  4. cobra300 commented on Dec 30, 2024

    @cobra300

    I was hit by this issue as well. I added this piece in my fsproj to walkaround this issue:

    	<!-- Temporarily resolve the issue caused by FsUnit.XUnit 7.0 -->
    	<Target Name="RemoveFsUnitExe" AfterTargets="ResolvePackageAssets" >
    		<FindInList List="@(RuntimeCopyLocalItems)" ItemSpecToFind="FsUnit.Xunit.exe" MatchFileNameOnly="true">
    			<Output TaskParameter="ItemFound" ItemName="_ToBeRemoved" />
    		</FindInList>
    		<ItemGroup>
    			<RuntimeCopyLocalItems Remove="@(_ToBeRemoved)" />
    			<ResolvedCompileFileDefinitions Remove="@(_ToBeRemoved)" />
    		</ItemGroup>
    	</Target>
  5. krymtkts commented on Dec 30, 2024

    @krymtkts
    Author

    @cobra300 Thank you for sharing the workaround. It worked perfectly!

  6. CaptnCodr commented on Dec 30, 2024

    @CaptnCodr
    Member

    Hey @krymtkts,
    FsUnit v7.0.1 has been published right now with a fix. 🙂
    Thank you for reporting this issue.

    And @cobra300, thank you for the workaround. ❤️

    Have a nice end of the year and a great start of 2025! 🎉

  7. krymtkts commented on Dec 31, 2024

    @krymtkts
    Author

    Thank you @CaptnCodr for the quick fix! 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions