I'm trying to setup a basic FAKE F# project that can run FsUnit but I cannot figure out how to solve the Method not found: 'Void FsUnit.TopLevelOperators.should(Microsoft.FSharp.Core.FSharpFunc`2<!!0,!!1>, !!0, System.Object)' errors.
I have read the following posts that seem to be related, but I'm apparently still not grokking it:
Main github issue
FSharp.Core packaging guidelines
FsUnit unable to test portable library (SO)
Another github issue
I have created a JunkTest library project with the following setup:
paket.dependencies
source https://www.nuget.org/api/v2
nuget FAKE
nuget FSharp.Core
nuget FsUnit
nuget NUnit
nuget NUnit.Console
paket.references
FSharp.Core
FsUnit
NUnit
JunkTest.fs
module JunkTest
open FsUnit
open NUnit.Framework
[<Test>]
let ``Example Test`` () =
1 |> should equal 1 // this does not work
//Assert.That(1, Is.EqualTo(1)) // this works (NUnit)
build.fsx (relevant part)
Target "Test" (fun _ ->
!! (buildDir + "JunkTest.dll")
|> NUnit3 (fun p ->
{p with OutputDir = "TestResults" }
)
)
Output
I see that FSharp.Core.dll is being copied from the local packages directory: Copying file from "c:\Users\dangets\code\exercism\fsharp\dgt\packages\FSharp.Core\lib\net40\FSharp.Core.dll" to "c:\Users\dangets\code\exercism\fsharp\dgt\build\FSharp.Core.dll".
And the nunit3-console execution: c:\Users\dangets\code\exercism\fsharp\dgt\packages\NUnit.ConsoleRunner\tools\nunit3-console.exe "--noheader" "--output=TestResults" "c:\Users\dangets\code\exercism\fsharp\dgt\build\JunkTest.dll"
I have tried to add a app.config file with the in the test project root directory with the following but it doesn't seem to solve the issue (NOTE I am not using Visual Studio - do I need to do anything special for the project to include the app.config file?):
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="FSharp.Core" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.3.1.0" newVersion="4.3.1.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
Any and all help is appreciated.
EDIT: The solution was that I was not properly setting up the App.config file to get included in the build. All of the answers that said "just add this to your App.config file" didn't help me because VSCode doesn't add this to the fsproj file automatically.
The part that I added is:
<None Include="App.config" />
In the ItemGroup that contains the other <Compile Include=Foo.fs> lines.
This happens because of FSharp.Core version mismatch. See, your application references one version of FSharp.Core and FsUnit references another version. This means that the FSharpFunc<_,_> type is going to be different (coming from different assemblies) for you and FsUnit, which in turn means that the should function exported by FsUnit is not the same function that your code is looking for, because it has a parameter of a different type.
This is where the bindingRedirect comes in. You're absolutely correctly added it to app.config, but from your question about whether you're doing it correctly, I get a suspicion that you might not. The thing with app.config is, it's not actually the program configuration. Rather, it's the source code for program configuration. At compile time, this file gets copied to bin\Debug\Your.Project.dll.config, and only then it will get picked up at runtime. If you didn't add this file to the fsproj project file (which, I suspect, might be the case), then it's not getting copied to the right place during build, and thus isn't getting picked up at runtime.
Another reason for it still not working may be that you've specified an incorrect version of FSharp.Core in your app.config file. Which brings me to the next point.
Crafting that file by hand is a bit fragile: when you upgrade FSharp.Core to a new version (or Paket does it for you), you may forget to fix it in app.config and even if you don't, it's a bit of a hassle. But Paket can help you with that: if you add the redirects: on options to your paket.dependencies file, Paket will add the bindingRedirect cruft to your app.config automatically:
source https://www.nuget.org/api/v2
nuget FAKE
nuget FSharp.Core redirects: on
nuget FsUnit
nuget NUnit
nuget NUnit.Console
This sounds like an FSharp.Core version mismatch.
The NuGet package you're using ships with FSharp.Core 4.4 (not 4.3.1). I recommend modifying your binding redirect to use 4.4:
<bindingRedirect oldVersion="0.0.0.0-4.3.1.0" newVersion="4.4.0.0" />
Related
I have been developing in VS 2015 and F# 4.0 (4.4.0.0) for quite some time.
With the release of VS 2017, I want to open solutions in the newest VS for development work, but still for a while keep the projects as VS 2015, F# 4.0, .NET 4.5.2. The build server will also have to use VS 2015 for a while.
As far as I can remember, this kind of scenario has not been problematic in earlier VS version upgrades, but then I don't think I used F# at that time.
I opened the solution and tried to compile. I get this error in a C# application project. (There are other C# applications, and at least one references an F# library.)
Unknown build error, 'Cannot resolve dependency to assembly 'FSharp.Core, Version=4.4.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' because it has not been preloaded. When using the ReflectionOnly APIs, dependent assemblies must be pre-loaded or loaded on demand through the ReflectionOnlyAssemblyResolve event.
All my F# projects in the solution are 4.0 (4.4.0.0). I double checked.
Why is this happening?
I searched for "4.4.1.0", and discovered that the "obj" folder of the C# project had a .exe.config file that differed from the app.config. It had this extra information that is not in the app.config of the project.
<runtime>
...
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="FSharp.Core" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.4.1.0" newVersion="4.4.1.0" />
</dependentAssembly>
</assemblyBinding>
Why is this appended automatically, and why only in this particular C# project?
I tried to copy that section to the app.config of the project, and change it to 4.4.0.0 in both places, but that didn't work. Also tried to use "4.4.1.0" as upper limit of old version, and have "4.4.0.0" as new version, but still didn't work. Same compiler error.
Then I removed that section, and I referenced FSharp.Core 4.4.0.0 in the C# project. That finally got rid of the compile error.
The I ran the program. It crashed with this exception.
Unhandled exception: Could not load file or assembly 'FSharp.Core, Version=4.4.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
I reinserted the section with the redirect, and now the program runs fine.
Just to sum up, I added a reference to FSharp.Core 4.0, and the redirect looks like this
<bindingRedirect oldVersion="0.0.0.0-4.4.1.0" newVersion="4.4.0.0" />
With these modifications, the solution still works as expected also in VS 2015.
I had the same problem, maybe this is helpful for someone:
In my case, the cause was that some of my C# projects with transitive dependencies on FSharp.Core were referencing the runtime's assembly installed on my system directly, instead of using the NuGet package. I.e. the reference didn't have a hint path pointing to the NuGet packages folder, and thus was picking the assembly from C:\Program Files\FSharp\... from the F# SDK. I solved this by removing the reference and reinstalling the FSharp.Core NuGet package.
So this:
<Reference Include="FSharp.Core, Version=4.3.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" />
Turns into:
<Reference Include="FSharp.Core, Version=4.5.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
<HintPath>..\..\..\packages\FSharp.Core.4.5.2\lib\net45\FSharp.Core.dll</HintPath>
<Private>True</Private>
</Reference>
Check the assembly references of the assembly in the message. For me I had a reference to assembly X which had a reference to Y. Because Y was missing, I got this error. By referencing Y, the error was resolved for me.
The following line:
let system = System.create "MyActorSystem" <| Configuration.load ()
... produces this output in the F# Interactive window:
Binding session to 'C:\Program Files (x86)\Microsoft Visual Studio 12.0\Blend\Newtonsoft.Json.dll'...
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.TypeLoadException: Could not load type 'Newtonsoft.Json.Converters.DiscriminatedUnionConverter' from assembly 'Newtonsoft.Json, Version=4.5.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed'.
at Akka.Serialization.NewtonSoftJsonSerializer..ctor(ExtendedActorSystem system)
--- End of inner exception stack trace ---
In my project references, Newtonsoft.Json points to .\packages\Newtonsoft.Json.9.0.1\lib\net45\Newtonsoft.Json.dll. I've read that I need version 7 or above of Newtonsoft.Json for Akka.NET, so I'm not sure why I'm seeing binding for version 4.5 in the FSI output; is that a false correlation that I should just ignore?
I thought that another copy of the library file might be loading, so in C:\Program Files (x86)\Microsoft SDKs\F#\4.0\Framework\v4.0\FsiAnyCPU.exe.config, I added:
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-9.0.0.0" newVersion="9.0.1.0" />
... but then I just get error FS0192: internal error: convMethodRef: could not bind to method in FSI.
I've tried looking in the fusion logs; binding succeeds for the Newtonsoft.Json library, so nothing fishy going on, there.
Anyone else run into this problem?
EDIT: OK so I discovered in the fusion logs that another copy of Newtonsoft.Json.dll, in C:\Program Files (x86)\Microsoft Visual Studio 12.0\Blend\, was intercepting binding. How do I prevent this without simply removing the library file from the Blend folder?
I think your problem is that your not loading the Json.NET from your packages folder:
C:\Program Files (x86)\Microsoft Visual Studio 12.0\Blend\Newtonsoft.Json.dll
write at the top of the script
#I __SOURCE_DIRECTORY__
this will add the source directory on the probing paths.
your references should resolve correctly.
FSLab template gives an error "The type provider 'RProvider.RProvider' reported an error: The type provider constructor has thrown an exception: Failed to start the R.NET server within 20 seconds"
I am using VS2015 and latest template from fslab.org
Anyone know how to work around this error? I get the same error when using VS2013 so I don't think it is related to VS.
RProvider.Server.exe is expecting FSharp.Core v4.3.0.0 but is bundled with 4.4, if you run RProvider.Server.exe you should see the exception. A work around is to add a RProvider.Server.exe.config file to the same directory with a binding redirect.
This is a pain. I am assuming you added FsLab from NuGet and tried building the project. As #kev says, the current stable version of FsLab (0.3.18) bundles the wrong version of FSharp.Core.dll. To see what #kev meant, go to the $YOUR_PROJECT_DIR/packages/RProvider.1.1.17/lib/net40 directory, open a command window there, and run RProvider.Server.exe to see the exception for yourself.
The cure is to create a binding redirect that would tell the runtime to look for the assembly version that is actually bundled (4.4.0.0) instead of the one it expects (4.3.0.0). To do this, create a file in the above mentioned directory, called RProvider.Server.exe.config, and paste the following into it...
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="FSharp.Core" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="4.3.0.0" newVersion="4.4.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
...and you should be good to go. To check, either run RProvider.Server.exe from the command line (it should give a different output to before) or rebuild your project to check that the error message stops appearing.
Obviously, this will hopefully just go away when the FsLab NuGet package gets sorted out.
I'm struggling to get started with F# on Linux using ProjectScaffold.
Specifically: I can't get a project to work with FsUnit/FsCheck/xunit. I
have F# 3.1 and mono 3.12.1 and I'm on Linux (Ubuntu) x64.
I start "MyProject" with:
$ git clone --depth=1 git#github.com:fsprojects/ProjectScaffold.git
$ cd ProjectScaffold && ./build.sh
Then I add a bit of code to "src/MyProject/Library.fs":
module MyProject.X
let four = 4
And then two tests to "tests/MyProject.Tests/Tests.fs":
module MyProject.Tests.X
open Xunit
open FsUnit.Xunit
open FsCheck
open FsCheck.Xunit
open MyProject.X
[<Fact>]
let ``Two plus two is four.`` () =
2 + 2 |> should equal four
[<Property>]
let ``Sorting a sorted list is idempotent.`` (l: int list) =
let s = List.sort l
s = List.sort s
This code works on Visual Studio where I manually added FsCheck, FsUnit, anx xunit 1.9.2 (it fails with later version
for some reason). My test project on Windows/Visual Studio has this config file:
<?xml version="1.0" encoding="utf-8"?>
<packages>
<package id="FsCheck" version="1.0.4" targetFramework="net45" />
<package id="FsCheck.Xunit" version="1.0.4" targetFramework="net45" />
<package id="FsUnit.xUnit" version="1.3.0.1" targetFramework="net45" />
<package id="xunit" version="1.9.2" targetFramework="net45" />
<package id="xunit.runner.visualstudio" version="2.0.0" targetFramework="net45" />
</packages>
So I edit paket.dependencies to add these packages and remove Nunit:
source https://nuget.org/api/v2
nuget FSharp.Formatting 2.8.0
nuget FSharpVSPowerTools.Core 1.7.0
nuget FAKE
nuget FsCheck 1.0.4
nuget FsCheck.Xunit 1.0.4
nuget FsUnit.xUnit 1.3.0.1
nuget xunit 1.9.2
nuget SourceLink.Fake
github fsharp/FAKE modules/Octokit/Octokit.fsx
Then:
$ mono .paket/paket.exe install
...and it fails because NUnit is referenced somewhere, so I delete the references in tests/MyProject.Tests/paket.references and
$ mono .paket/paket.exe install
works, but
$ ./build.sh
fails, at it cannot find references to FsCheck et al. So I assume that I need to add the references manually, so tests/MyProject.Tests/paket.references is now:
FsCheck
FsCheck.Xunit
FsUnit.xUnit
xunit
...built build.sh fails again: it cannot find FsCheck. I could not find in the paket doc how to add a local dependency (MyProject.Tests should reference MyProject), it might be done automatically.
I had this problem and it took a while for me to figure out a fix. For the project file in the Tests directory, I had to change this:
<Reference Include="FsUnit.NUnit">
<HintPath>..\..\packages\FsUnit.1.3.0.1\Lib\Net40\FsUnit.NUnit.dll</HintPath>
<Private>True</Private>
</Reference>
To this:
<Reference Include="FsUnit.NUnit">
<HintPath>..\..\packages\FsUnit\Lib\Net40\FsUnit.NUnit.dll</HintPath>
<Private>True</Private>
</Reference>
Similarly, for NUnit:
<Reference Include="nunit.framework">
<HintPath>..\..\packages\NUnit.2.6.3\lib\nunit.framework.dll</HintPath>
<Private>True</Private>
</Reference>
To:
<Reference Include="nunit.framework">
<HintPath>..\..\packages\NUnit\lib\nunit.framework.dll</HintPath>
<Private>True</Private>
</Reference>
The issue is that on mono, the packages don't have the version in the path but under Visual Studio they do. Once I found this fix, I created two .fsproj files for the tests and I modified the build.sh script to swap the mono-compatible one in when under mono via:
#!/bin/bash
if test "$OS" = "Windows_NT"
then
# no changes in here
else
# fix test fsproj file
mv tests/ProjectName.Tests/ProjectName.Tests.fsproj tests/ProjectName.Tests/ProjectName.Tests.fsproj.vs
mv tests/ProjectName.Tests/ProjectName.Tests.fsproj.mono tests/ProjectName.Tests/ProjectName.Tests.fsproj
# leave the script logic for mono in place
# put project files back to avoid git noticing the swap
mv tests/ProjectName.Tests/ProjectName.Tests.fsproj tests/ProjectName.Tests/ProjectName.Tests.fsproj.mono
mv tests/ProjectName.Tests/ProjectName.Tests.fsproj.vs tests/ProjectName.Tests/ProjectName.Tests.fsproj
fi
Once I made these changes the project works fine under both Visual Studio as well as mono.
I am not quite sure, I understand you: Do you have two fsproj files, one for the production code and one for the unit tests? And are you referencing FsCheck in the fsproj?
Plus, I remember an issue, where if you compile against an older version of .net and reference an assembly compiled against a newer version of .net, it will behave as though there was no reference.
I've got TFS doing some continuous integration builds. Today, it broke for one solution. It seems it can't find AutoMapper. All the other packages can be found just fine.
A couple relevant points:
None of the packages are in source control, we're letting TFS restore them.
We have an internal NuGet feed, but it doesn't seem to be a problem in other solutions, and in this solution we are still getting Entity Framework to restore - just not AutoMapper.
I tried removing and re-adding the NuGet Packages. No luck.
If I use Remote Desktop to connect to the build server and open the project in Visual Studio there, it restores the packages and builds fine.
I can build manually by executing D:\"Program Files"\"Microsoft Team Foundation Server 12.0"\Tools\Nuget.exe restore followed by msbuild MySolutoin.sln
Our TFS server is installed on our D:\ drive.
This is from the TFS Logs:
D:\Program Files\Microsoft Team Foundation Server 12.0\Tools\nuget.exe restore "C:\Builds\1\MyCompany Web\FclQuoteWcfService\src\FclQuoteWcfService.sln" -NonInteractive
Installing 'EntityFramework 6.1.3'.
Installing 'InternalPackage 1.0'.
Successfully installed 'InternalPackage 1.0'.
Successfully installed 'EntityFramework 6.1.3'.
Unable to find version '3.3.1' of package 'AutoMapper'.
C:\Program Files (x86)\MSBuild\12.0\bin\amd64\MSBuild.exe /nologo /noconsolelogger "C:\Builds\1\MyCompany Web\FclQuoteWcfService\src\FclQuoteWcfService.sln" /nr:False /fl /flp:"logfile=C:\Builds\1\MyCompany Web\FclQuoteWcfService\src\FclQuoteWcfService.log;encoding=Unicode;verbosity=normal" /p:SkipInvalidConfigurations=true /m /p:OutDir="C:\Builds\1\MyCompany Web\FclQuoteWcfService\bin\\" /p:VCBuildOverride="C:\Builds\1\MyCompany Web\FclQuoteWcfService\src\FclQuoteWcfService.sln.vsprops" /dl:WorkflowCentralLogger,"D:\Program Files\Microsoft Team Foundation Server 12.0\Tools\Microsoft.TeamFoundation.Build.Server.Logger.dll";"Verbosity=Normal;BuildUri=vstfs:///Build/Build/230;IgnoreDuplicateProjects=False;InformationNodeId=12;TargetsNotLogged=GetNativeManifest,GetCopyToOutputDirectoryItems,GetTargetPath;TFSUrl=http://ctidev2k8:8080/tfs/MyCompany;"*WorkflowForwardingLogger,"D:\Program Files\Microsoft Team Foundation Server 12.0\Tools\Microsoft.TeamFoundation.Build.Server.Logger.dll";"Verbosity=Normal;" /p:BuildId="9aa9f8af-c9b9-4d0a-ba06-7cc959231d8e,vstfs:///Build/Build/230" /p:BuildLabel="FclQuoteWcfService_20150330.2" /p:BuildTimestamp="Mon, 30 Mar 2015 20:40:07 GMT" /p:BuildSourceVersion="LFclQuoteWcfService_20150330.2#$/MyCompany Web" /p:BuildDefinition="FclQuoteWcfService"
Exception Message: MSBuild error 1 has ended this build. You can find more specific information about the cause of this error in above messages. (type BuildProcessTerminateException) Exception Stack Trace: at System.Activities.Statements.Throw.Execute(CodeActivityContext context) at System.Activities.CodeActivity.InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager) at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor executor, BookmarkManager bookmarkManager, Location resultLocation)
I've seen this too. It seems to be triggered as soon as NuGet package restore switches to the internal feed. Once it does this is doesn't switch back to the official nuget.org feed and continues to look for the packages on the internal feed.
Ensure both package sources are added to your NuGet.config file. Also ensure both sources are 'active'.
<configuration>
<packageSources>
<add key="nuget.org"
value="https://www.nuget.org/api/v2/" />
<add key="example.com"
value="http://example.com/feed/nuget/" />
</packageSources>
<activePackageSource>
<add key="All"
value="(Aggregate source)" />
</activePackageSource>
</configuration>
See NuGet configuration file documentation.
Matt's answer put me on the right track but we don't use an internal feed so I had to do some more digging. This answer works, at least, for a project created in Visual Studio 2015 and built by TFS 2015.
In Visual Studio, open the NuGet package manager settings (Tools menu > NuGet Package Manager > Package Manager Settings). Choose "Package Sources" from the options list on the left.
Create the nuget.config file at the root of the solution. This should be the same folder location as your ".sln" solution file. Copy the following into the config file:
<configuration>
<packageSources>
</packageSources>
<activePackageSource>
<add key="All"
value="(Aggregate source)" />
</activePackageSource>
</configuration>
Within the <packageSources> tag, create an <add key="" value="" /> entry for each source listed in the "Package Sources" options window. The key is the name of the source as shown above the URL, and the value is the URL itself. Include those listed in both "Available package sources" and "Machine-wide package sources". I did not create an entry for the local filesystem as it wasn't used in this solution. Based on the screenshot above, the complete config file now contains the following:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="nuget.org"
value="https://api.nuget.org/v3/index.json" />
<add key="Microsoft and .NET"
value="https://www.nuget.org/api/v2/curated-feeds/microsoftdotnet/" />
</packageSources>
<activePackageSource>
<add key="All"
value="(Aggregate source)" />
</activePackageSource>
</configuration>
After committing the nuget.config file to source control, TFS was able to download all the necessary NuGet packages and successfully build the solution.
In addition to Matt's answer, I'd like to highlight the following well-hidden stuff from the NuGet documentation:
NuGet config files are treated in the following priority order
(closest to the folder nuget.exe runs from wins), for example assuming
the solution directory is c:\a\b\c:
c:\a\b\c\.nuget\nuget.config - This file is only used for solution
level packages, and is not supported in nuget 3.0 - 3.4
c:\a\b\c\nuget.config
c:\a\b\nuget.config
c:\a\nuget.config
c:\nuget.config
User specific config file,
%AppData%\NuGet\nuget.config.
Or the user specified file thru option
-ConfigFile.
This could explain some weird behaviour in specific scenario's where a restore does or does not pick up a configured feed, depending on whether youre restoring with nuget 2.x or 3.x
Edit: and I found yet another reason why packages might not be detected:
I have package "A" with version 1.1.1.0 .
Prior 3.4 this command works well:
nuget install A -version 1.1.1.0
With NuGet 3.4 RC I get:
An error occurred while retrieving package metadata for 'A.1.1.1' from
source 'N'. An error occurred while retrieving package metadata for
'A.1.1.1' from source 'N'. Data at the root level is invalid. Line
1, position 1.
...
The client treats 1.1, 1.1.0, 1.01.0 and 1.1.0.0 as the same version
using SemVer rules. The reason non-normalized versions were special
cased in the past is because for v2 http calls the client would first
send the version string exactly as the user specified it