MathNet Numerics needs FsUnit.CustomMatchers to successfully build. Ran out of options - f#

In trying to build the latest version of MathNet Numerics from GitHub using Visual Studio Community 15 with MathNet.Numerics.sln which needs DLLs for unit testing installed.
Could not resolve this reference. Could not locate the assembly "FsUnit.CustomMatchers".
Could not resolve this reference. Could not locate the assembly "FsUnit.NUnit".
Could not resolve this reference. Could not locate the assembly "nunit.framework".
So using NuGet from within Visual Studio the following can be successfully installed.
Successfully installed 'NUnitTestAdapter.WithFramework 2.0.0' to UnitTests
Successfully installed 'FSharp.Core 3.1.2.5' to FSharpUnitTests
Successfully installed 'NUnit 3.0.1' to FSharpUnitTests
Successfully installed 'FsUnit 2.0.0' to FSharpUnitTests
The only DLL remaining is
FsUnit.CustomMatchers
which I am unable to locate.
The hint is ..\..\packages\test\FsUnit\lib\FsUnit.CustomMatchers.dll, yet there is not test directory under packages.
How do I correctly resolve this?
Do I need the DLL and if so where can it be located?
Do I need to make a manual code fix?
Do I need to update the hint?
TLDR;
If I build without the missing DLL the basic error is:
A unique overload for method 'IsTrue' could not be determined based on type information prior to this program point. A type annotation may be needed. Candidates:
Assert.IsTrue(condition: Nullable<bool>, message: string, [<ParamArray>] args: obj []) : unit,
Assert.IsTrue(condition: bool, message: string, [<ParamArray>] args: obj []) : unit
which can be resolved by installing
Microsoft.VisualStudio.QualityTools.UnitTestFramework
and adding
open Microsoft.VisualStudio.TestTools.UnitTesting
which has the signature of
Assert.IsTrue(condition: bool, message: string, [<ParamArray>] args: obj []) : unit
but that is not correct as it does not install the correct DLL (Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll vs FsUnit.CustomMatchers) and from past experience with F# Unit testing I am aware of the subtitles that could allow false positives by doing such.
EDIT:
After successfully installing I wanted to know where this was documented.
See: Building Math.NET Numerics
The fully automated build including unit tests, documentation and
api reference, NuGet and Zip packages is using FAKE.

That solution is using Paket, the F# package system. Not NuGet. It also uses FAKE, the F# build system.
To have everything restored, configured and built, simply run build.cmd (or build.sh if you're on *NIX).
The /test/ part of the path comes from something called "dependency group", a feature of Paket. In a nutshell, it lets you group your dependencies by some criteria, and then restore them selectively rather than "all dependencies, all the time".
This particular project, judging by its paket.dependencies file, defines four groups - Test, Build, Data, and Benchmark. I can guess that "Build" has dependencies needed for regular build, and "Test" has dependencies needed for testing.
To restore dependencies using Paket, you need to download Paket and then run paket install.
In order to streamline the downloading part, the solution includes a bootstrapper at .paket/paket.bootstrapper.exe, which you can run to have the latest Paket downloaded. This is a standard thing, it is added when you initialize a new project by running paket init.
And the whole process (i.e. running the bootstrapper and then running Paket itself) is encoded in build.cmd and build.sh files, along with running FAKE afterwards. This is why I suggested that you simply run build.cmd.

Related

tfs 2017 build multiple solutions dependency

How to create build definition for multiple solutions that have dependency?
Background here:
There are two solutions
Solution A is class library contains an object class 'ClassA'
Solution B is console program that use 'ClassA' by add dll reference generated by solution A.
I would like to server build both solutions using one TFS 2017 build definition.
It raise out error:
Main\Source\SolutionB\Program.cs (13, 13)
Main\Source\SolutionB\SolutionB\Program.cs(13,13): Error CS0246:
The type or namespace name 'SolutionA' could not be found (are you
missing a using directive or an assembly reference?)
How to config the build definition that SolutionB would know to use the dll generated from the build of SolutionA?
You should build your first project that will be used at second project as dll and than copy files to build artifacts; than publish your dlls to specific folder that you referenced in your second project and finally build your second project.
You can check this image that with similiar process, just in below image it is publishing artifacts to three diffrent location, in your case it should be one publish task.
This is one of the simple way; but if you use the project A for some other projects too you may want to use NuGet packages. I am going to describe this as solution 2.
Solution 2: You should create a Nuget packages by the artifacts of Project A. You can host your Nuget packages in custom source folder. Add your first project's package to your project as a reference. You don't need to do something extra just add a nuget restore task to your build definition. If you want, you can publish your first project as a nuget package during the build definiton. Please check how to restore and install neuget packages by build definiton.

MSBuild builds solution but fails to build the project

I have F# project which I want to build with command line (to use that later in FAKE config).
The problem is that MSBuild fails to resolve assembly dependencies when I use it on the project file directly. While it goes fine when I use solution file with this single project included.
I really have run out of ideas. The solution file seems to not contain any critical information.
Another weird thing is that VSCode also fails to resolve one of those assemblies. I hope that when I fix MSBuild config I may be will able to see what's wrong with VSCode.
Command line:
"C:\Program Files (x86)\MSBuild\14.0\Bin\msbuild.exe" FSharpWeb1\FSharpWeb1.fsproj /t:rebuild
Error message:
C:\work\MNP\testMSBuild1\FSharpWebApi\FSharpWeb1\FSharpWeb1.fsproj(173,5): error MSB4062: The "MSBuild.ExtensionPack.FileSystem.File" task could not be loaded from the assembly C:\work\MNP\testMSBuild1\FSharpWebApi\FSharpWeb1\*Undefined*\packages\MSBuild.Extension.Pack.1.3.0\tools\net40\MSBuild.ExtensionPack.dll. Could not load file or assembly 'file:///C:\work\MNP\testMSBuild1\FSharpWebApi\FSharpWeb1\*Undefined*\packages\MSBuild.Extension.Pack.1.3.0\tools\net40\MSBuild.ExtensionPack.dll' or one of its dependencies. The filename, directory name, or volume label syntax is incorrect. Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.Done Building Project "C:\work\MNP\testMSBuild1\FSharpWebApi\FSharpWeb1\FSharpWeb1.fsproj" (rebuild target(s)) -- FAILED.
I've pushed the minimal demo to github: https://github.com/alehro/testMSBuild.git
It's actually easy to reproduce independently. In VS 2015 Community edition create new project from F# Web Template named "Web Api 2.2" and then try to build it with MSBuild.
Another disturbing thing is that the minimal demo produces different errors from those I've seen yesterday. Also vscode complains on different items. If yesterday it could not resolve a couple of calls, now it complains on all of:
open System.Net.Http
open System.Web
open System.Web.Http
open System.Web.Routing
telling that neither of them is defined.
Reformatting my comments to a response now that it's verified it works:
Your FSharpWeb1.fsproj references MSBuild.ExtensionPack.FileSystem.File task from MSBuild.Extension.Pack, but the path specified in the <UsingTask> tag contains $(SolutionDir) property which is not defined when you run MSBuild outside of Visual Studio.
The error message you're getting shows that in the highlighted part of the path:
The "MSBuild.ExtensionPack.FileSystem.File" task could not be loaded from the assembly C:\work\MNP\testMSBuild1\FSharpWebApi\FSharpWeb1\*Undefined*\packages\MSBuild.Extension.Pack.1.3.0\tools\net40\MSBuild.ExtensionPack.dll.
This can be remedied by conditionally setting the relative path when the property is not set by VS:
<SolutionDir Condition="$(SolutionDir) == '' Or $(SolutionDir) == '*Undefined*'">..\</SolutionDir>
(original response for this solution: https://stackoverflow.com/a/33782131/1659828)
One more thing I mentioned in the comments is that this solution assumes you already have the necessary dependencies downloaded in the packages folder. Visual Studio does that automatically by restoring NuGet packages before build, but when you build in another context, you have to make sure the packages are restored, otherwise the build will keep failing.

intellij grails unable to resolve external library at groovy compile time

I'm writing a simple etrade programmatic trading program that needs to authenticate with etrade oauth. I'm using IntelliJ Ultimate with Grails 3.1.9.
I added a folder full of jars to Project Settings->Libraries and Project Settings->Modules->main project (accessible by pressing "command ;") and selected "export." The classes resolve fine in the groovy editor in my controller class but they don't resolve at groovy compile time. Why is that?
~/IdeaProjects/<project name>/grails-app/controllers/etradescripter/ETradeUserController.groovy: 8: unable to resolve class com.etrade.etws.sdk.client.ClientRequest
# line 8, column 1.
import com.etrade.etws.sdk.client.ClientRequest;
Grails use the Gradle build system, which is comparable (superior IMHO) to maven.
It is completely external to the IDE itself and not dependend to any IDE.
It is a very powerfull external build tool which has it's own tooling, dependency management,
library cache and logs.
The libraries and SDK you declare in Intellij project structure settings are for IntelliJ internal support (intellisense, code assist, decompiling etc) not for building and/or debugging
The gradle tooling support for your project (found in File/Settings/Gradle) can be:
a gradlew declaration in the project : the project will use it's own
build system version downloaded from the specifications in
gradle/wrapper/gradle-wrapper.properties file with the accompanying
gradle-wrapper.jar downloader - this is the recommended way to go if you are not comfortable with the system to avoid
problems but disk consuming and not the fastest build. There will be a gradle binary distribution download for the first build
a Gradle version bundled with Intellij (2.13 for the last IntelliJ version I think)
one you can declare in the project settings (ie your own Gradle installation root, you have to install it before and set the right
environment variables to make it work) for the last one it can be a
"daemon" version which speeds up thing notably but is very cpu and
memory expensive for a large project (be prepared for 100% cpu and
memory hogs for a large project whatever computer you have).
The main file for build where you declare the build and debug dependencies is "Build.gradle" file at the root of your project.
Dependencies are declared with lines (Groovy syntax, gradle is a groovy tool) like:
dependencies {
assets "com.craigburke.angular:angular-template-asset-pipeline:2.2.6"
assets "com.craigburke.angular:angular-annotate-asset-pipeline:2.4.0"
assets "com.craigburke:js-closure-wrap-asset-pipeline:1.2.0"
compile "org.springframework.boot:spring-boot-starter-logging"
compile "org.springframework.boot:spring-boot-autoconfigure"
etc...
This is where you have to add your own dependencies, not in IntelliJ SDK/lib settings.
This is comparable to the maven system with a different syntax (groovy).
For jars comming from an external repo or local dependencies, you should see lines that you can copy/paste and modify.
If not look at gradle docs
especially 23.3 and 23.4, how to declare you dependencies.
There can be other gradle files in gradle directory and/or subprojects directory. It depend on your project.
To build your project, you can open the Gradle tool window in IntelliJ (View/Tool Windows/Gradle), select the build task (Task/build/build), double click on it and it will launch the build.
This will change the run/debug configuration in the IntelliJ IDE so you can build it again with the IDE toolbar by clicking on the Run button
Note: the run button runs the currently selected gradle task, not the application, this is a bit confusing at the beginning
To run or debug you app, you select the appropriate task, in case of Grails task, application/bootrun and double click on it.
This will launch your application (after a build if needed), and if it is a web app, you can browse you application in your browser.
When you run the Run task (not the build task) you can also click on 'Debug' icon to debug your application
If you select another task and click debug, you will have a socket exception because IntelliJ thinks you are launching a jvm and tries to connect to it for debugging.
(they are lots of predefined task in Gradle : assembling jars, building docs etc... and the Run task may be specific to a project
Generally Build tasks are under the build category and run task under the application category)

Build versus Runtime Dependencies in Nix

I am just starting to get to grips with Nix, so apologies if I missed the answer to my question in the docs.
I want to use Nix to setup a secure production machine with the minimal set of libraries and executables. I don't want any compilers or other build tools present because these can be security risks.
When I install some packages, it seems that they depend on only the minimum set of runtime dependencies. For example if I install apache-tomcat-8.0.23 then I get a Java runtime (JRE) and the pre-built JAR files comprising Tomcat.
On the other hand, some packages seem to include a full build toolchain as dependencies. Taking another Java-based example, when I install spark-1.4.0 Nix pulls down the Java development kit (JDK) which includes a compiler, and it also pulls the Maven build tool etc.
So, my questions are as follows:
Do Nix packages make any distinction between build and runtime dependencies?
Why do some packages appear to depend on build tools whereas others only need runtime? Is this all down to how the package author wrapped up the application?
If a package contains build dependencies that I don't want, is there anything that I, as the operator, can do about it except design my own alternative packaging for the same application?
Many thanks.
The runtime dependencies are a subset of the build-time dependencies that Nix determines automatically by scanning the generated output for the hash part of each build-time dependencies' store path. For example, if you build a package using the compiler /nix/store/abcdef...-foo-1.20, then Nix will scan all files in the generated output for the hash bit abcdef.... If that hash is found, then the output is assumed to reference the compiler in some way, so it's kepts as a runtime dependency. If that hash does not occur, however, then the generated output has no reference to the compiler and therefore cannot access it at runtime, so foo-1.20 is treated as a build-time-only dependency.
Some packages record large parts of their build environment for informational/debugging purposes. Perl, for example, stores every little detail about the tools used to compile it, so all those store paths end up being treated as runtime dependencies despite the fact that Perl doesn't actually need them at runtime, but Nix can't know: it just knows that the Perl store path references those tools. Now, Nixpkgs maintainers usually make an effort to clean that up, i.e. by pruning the logfile that contains all those store paths from the installation, etc., but for sure there are plenty of packages in the database still that haven't been optimized to that end yet.
Let's assume that you'd like to compile a version of openssh that does not depend on PAM. Then you can remove the build input from the expression by means of an override, i.e. you replace the pam argument that's normally passed to the openssh build function with null. To do that, store the following file in ~/.nixpkgs/config.nix
{
packageOverrides = super: let self = super.pkgs; in {
openssh-without-pam = super.openssh.override {
pam = null;
};
};
}
and now install that package by running:
$ nix-env -f "<nixpkgs>" -iA openssh-without-pam

How do I install Rascal

Can someone tell me how to install Rascal?
The install instruction say - Eclipse Indigo for RCP/RAP - got it.
Then Install New Software and put in the repository address:
http://update.rascal-mpl.org/stable/
- done that
Check "Contact all update sites during install to find required software" - ok
Hit Next, and it complains can't find Jetty, so set up its repo, can't find some Http lib, and on it goes.
What I have done, after I temporarily gave up on Eclipse, is to compile using the Maven build.
This makes me think, is a dependency missing from the Developer Dependencies list? That being the 'rascal-master' project, which contains not much more than the top-level pom.xml file?
I downloaded that too, and tried to build. It did not work because Tycho could not resolve dependencies correctly, it ended up looking for pdb.values:0.0.0 instead of the correct version, I don't know how it managed to zero out the version.
I notice that there is a Jenkins build server, which presumably runs off the Maven poms? It might be an idea to update the Developer Dependencies page with an accurate list of what needs checked out to build from scratch with Maven. It should be as easy as check out some projects, then type 'mvn install' and it all works nicely. Perhaps that is already the case on the build server, but I can't get into the configurations to see how that works.
In the end I removed Tycho from the build, and found enough dependencies in the Maven central repo by hand to get it building, and just put in statements for each of them.
It really is a sad state of affairs the way that Eclipse disrespects the Maven repository, by creating their own and using their own format and tool; Tycho will not download stuff from Eclipse and put it in your local repository, from where you could use it in a more sane way.
The installation instructions seems to be outdated. I can confirm that Rascal will not install with Eclipse Indigo due to dependency errors. It works fine with Eclipse Juno for RCP/RAP.
Ouch, that's a painfull experience, it should not have been this hard, I will look into this.
As workaround: see Rascal Developer dependencies , if you install these dependencies by hand, it should work.
If you continue experiencing installation problems, leave a Github issue, since that is more suited for back and forward conversations.
To use Maven, you also need to insert the following into the pom.xml of rascal-master (replacing the old modules section if there is one):
<modules>
<module>../pdb</module>
<module>../pdb.ui</module>
<module>../pdb.values</module>
<module>../imp.runtime</module>
<module>../imp.pom</module>
<module>../ambidexter</module>
<module>../rascal</module>
<module>../rascal-eclipse</module>
<module>../rascal-shell</module>
<module>../rascal-feature</module>
<module>../rascal-update-site</module>
</modules>
Then run "mvn clean install" or "mvn clean install -DskipTests=true" from inside rascal-master.

Resources