The module/namespace 'NHamcrest' from compilation unit 'NHamcrest' did not contain the namespace, module or type 'CustomMatcher`1'

Description

I have created a new test (classlib) project using the dotnet sdk (2.0), and I’m using paket for package management. I followed the xunit tutorial to get things wired up, and I am able to write a trivial xunit test to prove that the pieces work. However, when I try to do that same with FsUnit.xUnit, the compiler fails thusly:

error FS0074: The type referenced through 'Xunit.Assert' is defined in an assembly that is not referenced. You must add a reference to assembly 'xunit'.

After configuring some binding redirects, the error becomes this:

FSC : error FS0193: The module/namespace 'NHamcrest' from compilation unit 'NHamcrest' did not contain the namespace, module or type 'CustomMatcher`1'

Repro steps

1. Create project files as follows:

Contents of my .fsproj:

<?xml version="1.0" encoding="utf-8"?>
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Library</OutputType>
    <TargetFramework>net461</TargetFramework>
    <DebugType>portable</DebugType>
  </PropertyGroup>
  <ItemGroup>
    <Compile Include="Test.fs" />
    <None Include="Script.fsx" />
  </ItemGroup>
  <ItemGroup>
    <DotNetCliToolReference Include="dotnet-xunit" version="2.3.0" />
  </ItemGroup>
  <Import Project="..\..\DotNetSdk.FscTooling.props" />
  <Import Project="..\..\.paket\Paket.Restore.targets" />
</Project>

Contents of DotNetSdk.FscTooling.props:

<Project>
  <PropertyGroup>
    <IsWindows Condition="'$(OS)' == 'Windows_NT'">true</IsWindows>
    <IsOSX Condition="'$([System.Runtime.InteropServices.RuntimeInformation]::IsOSPlatform($([System.Runtime.InteropServices.OSPLatform]::OSX)))' == 'true'">true</IsOSX>
    <IsLinux Condition="'$([System.Runtime.InteropServices.RuntimeInformation]::IsOSPlatform($([System.Runtime.InteropServices.OSPLatform]::Linux)))' == 'true'">true</IsLinux>
  </PropertyGroup>
  <PropertyGroup Condition="'$(IsWindows)' == 'true'">
    <FscToolPath>C:\Program Files (x86)\Microsoft SDKs\F#\4.1\Framework\v4.0</FscToolPath>
    <FscToolExe>fsc.exe</FscToolExe>
  </PropertyGroup>
  <PropertyGroup Condition="'$(IsOSX)' == 'true'">
    <FscToolPath>/Library/Frameworks/Mono.framework/Versions/Current/Commands</FscToolPath>
    <FscToolExe>fsharpc</FscToolExe>
  </PropertyGroup>
  <PropertyGroup Condition="'$(IsLinux)' == 'true'">
    <FscToolPath>/usr/bin</FscToolPath>
    <FscToolExe>fsharpc</FscToolExe>
  </PropertyGroup>
</Project>

Contents of Test.fs:

namespace Olo.Insights.Test
module Default =

    open Xunit
    open FsUnit.Xunit

    [<Fact>]
    let ``Simple test to prove fsunit`` () =
        true |> should be True

Contents of packet.dependencies:

source https://api.nuget.org/v3/index.json
generate_load_scripts: true

framework: net461
nuget FAKE
nuget FSharp.Core
nuget Rezoom.SQL.Provider.Postgres
nuget xunit ~> 2.3.0
nuget xunit.runner.visualstudio ~> 2.3.0
nuget dotnet-xunit ~> 2.3.0
nuget Microsoft.NET.Test.Sdk
nuget FsUnit.xUnit

Contents of paket.references in my test project:

FSharp.Core
xunit
FsUnit.xUnit

1. run paket install

2. run dotnet build or msbuild

Expected behavior

Compile to succeed, 1 test to be discovered by the dotnet xunit runner.

Actual behavior

Compiler error:

Test.fs(8,9): error FS0074: The type referenced through 'Xunit.Assert' is defined in an assembly that is not referenced. You must add a reference to  assembly 'xunit'.

1. After realizing that this was failing because of paket’s dependency resolution algorithm, I specified ~> 3.0.0 in my paket.dependencies file.

2. Now the original error is gone, and the correct versions are installed, but there seems to now be a conflict between the NHamcrest included in the FsUnit.xUnit nupkg and the NHamcrest my client fetched from nugget.

Example MSBuild output:

λ  msbuild
Microsoft (R) Build Engine version 15.4.8.50001 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.

Build started 10/24/2017 06:20:25 PM.
Project "Test.fsproj" on node 1 (default targets).
_HandlePackageFileConflicts:
  Encountered conflict between 'Reference:C:\Users\ben\.nuget\packages\fsunit.xunit\3.0.0\lib\net45\NHamcrest.dll' and 'Reference:C:\Users\ben\.nuget\packages\nhamcrest\2.0.1\lib\net451\NHamcrest.dll'.  Choosing 'Reference:C
  :\Users\ben\.nuget\packages\nhamcrest\2.0.1\lib\net451\NHamcrest.dll' because AssemblyVersion '2.0.1.0' is greater than '1.2.1.0'.
  Encountered conflict between 'CopyLocal:C:\Users\ben\.nuget\packages\fsunit.xunit\3.0.0\lib\net45\NHamcrest.dll' and 'CopyLocal:C:\Users\ben\.nuget\packages\nhamcrest\2.0.1\lib\net451\NHamcrest.dll'.  Choosing 'CopyLocal:C
  :\Users\ben\.nuget\packages\nhamcrest\2.0.1\lib\net451\NHamcrest.dll' because AssemblyVersion '2.0.1.0' is greater than '1.2.1.0'.

Any ideas how to solve this? I tried adding copy_local to my paket.dependencies file next to the reference to FsUnit.xUnit, but that didn’t make a difference.

Related information

• Operating system: Windows 10
• Package Versions: FsUnit.xUnit 3.0.0, xunit* 2.3.0
• .NET Runtime, CoreCLR or Mono Version: .NET Framework 4.6.1, using dotnet sdk 2.0.2

[enricosada]

As a learned the bad way, the fallback references (the All frameworks) shown in nuget, should be avoided. because if that exists, if target framework doesnt match EXACTLY (that mean version too), the fallback is going to be used, not the nearest one.

if your case, .net core 2.0 ask for netstandard2.0, but your nuspec doesnt have it, so fallback too All frameowkrs (the fallback group) and use .NET full assemblies. Adding other pkg fix the situation because these pull in and override the packages.

if you do dotnet build -v n you can see fsc args, and the refs

fallbackversion is a really old feature of nuget, not used anymore, and doesnt work as we expect it does. now the sdk choose the nearest target framework

So to fix:

• remove fallback group (the one without version)
• add a net45 (or net40, etc) the minimal .NET version you support
• leave the netstandard1.6 (will be used also for netstandard2.0 because nearest)

[sergey-tihon]

should not be an issue with v4 since it provide only netstandard2.0 assemblies