Mixed languages ​​and subprojects with .NET Core

Question

I have a project written mostly in F # that uses a component written in C #. It works great on Windows with Visual Studio, as well as on Linux and OS X using Make files.

I am trying to port it to .NET Core , which has its own dotnet build . I'm having difficulty reproducing nested projects of my existing build system. That is, I want him to build the C # DLL, and then build and associate the F # executable project with it.

I tried to do without a DLL, but each project.json file, apparently, can only refer to files in one language. If you try to add the C # file to the compileFiles list of the F # project file, dotnet build complains that it cannot compile Foo.cs with fsc .

My C # project is in a subdirectory of the F # project, named after the namespace that it implements, so I created a new .NET Core C # DLL project in this directory, but now I don’t see how to link these two projects together.

The dependencies function of the project file format does not seem to solve this problem. If the DLL project is in Foo/Bar and it implements the Foo.Bar namespace, dotnet restore cannot find it with this dependency link:

 "dependencies": { ...other stuff... "Foo.Bar": "*" }, 

Apparently, he can only search for NuGet for dependencies. I do not want to send a component to NuGet just so that dotnet restore can find it.

I don’t want to use the bin syntax to link to the embedded DLL, because this will require a two-pass assembly and a third project.json . (One for the F # project, one for the C # project, and one for linking to the embedded DLL.) Even then, I still don’t see how to link the first project with the third.

Of course, is there an easy way to have a nested build tree with dotnet build ?

Answer 1

Your problem is that one project is nested under another. If you put them side by side (say /src/RootProj and /src/Foo.Bar ), you can access the Foo.Bar project with:

 "dependencies": { "Foo.Bar": "*" } 

---

The dnx design system is cop ..., um, is highly dependent on NodeJS, so depending on the directory structure is to output certain attributes.

It is expected that the projects will be located in the subfolders of the root, and each of them should have its own project.json file. The "root" itself comes from the global.json file, located up the folder tree. The toolkit moves the folders up from the "current" until it finds global.json . The global.json then considered the "root of all roots." If you just create your solution from a template, you will have something like this:

 /solution global.json /src /project1 project.json File.cs /project2 project.json File.cs /tests /testproject1 project.json File.cs 

When you are in any of the subfolders, the tool will know the root of the solution by going up the folders. How git works

If you look at the global.json file, you will probably see something like this:

 { "projects": ["src", "tests"] } 

This means that the dnx snap-in expects to find projects under /src and /tests that it is.

Now, from this, I can make another possible solution. I haven’t tried it myself, but it might work. Instead of moving the project Foo.Bar to /src , you can add the path to projects to global.json :

 { "projects": ["src", "tests", "src/Project1/Foo.Bar"] } 

As I said, I’m not sure if this will work or create any other subtle inconsistencies. Give it a try.