Lingue miste e sottoprogetti con .NET Core

Question

Ho un progetto scritto principalmente in F # che utilizza un componente scritto in C#. Sta crescendo bene su Windows con Visual Studio e su Linux e OS X usando Makefiles.

Sto provando a portarlo a .NET Core, che ha il proprio sistema di compilazione, dotnet build. Ho difficoltà a replicare la gestione del progetto nidificata dei miei sistemi di generazione esistenti al suo interno. Cioè, voglio creare la DLL C#, quindi creare e collegare il progetto eseguibile F # ad esso.

Ho provato a fare a meno di DLL, ma ogni file project.json può apparentemente solo fare riferimento a file in una lingua. Se si tenta di aggiungere un file C# all'elenco di un file di progetto F # compileFiles, dotnet build si lamenta che non è possibile compilare Foo.cs con fsc.

Il mio progetto C# si trova in una sottodirectory del progetto F #, che prende il nome dallo spazio dei nomi che implementa, quindi ho creato un nuovo progetto .NET Core C# DLL in quella directory, ma ora non vedo come legare i due progetti insieme.

La funzione dependencies di project file format non sembra risolvere questo tipo di problema. Se il progetto DLL è in Foo/Bar e implementa lo spazio dei nomi Foo.Bar, dotnet restore non riesce a trovare con questo riferimento dipendenza:

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

A quanto pare è solo cercare NuGet per le dipendenze. Non voglio spedire il componente a NuGet puramente in modo che lo possa trovare dotnet restore.

Non voglio utilizzare bin syntax per fare riferimento alla DLL costruita perché ciò richiederebbe un build a 2 passaggi e un terzo file project.json. (Uno per il progetto F #, uno per il progetto C# e uno per fare riferimento alla DLL costruita.) Anche allora, non vedo ancora come legare il primo progetto al terzo.

Sicuramente c'è un modo semplice per avere un albero di build nidificato con dotnet build?

Answer 1

Il tuo problema è che un progetto è annidato sotto l'altro. Se si mette fianco a fianco (diciamo, /src/RootProj e /src/Foo.Bar), si dovrebbe essere in grado di fare riferimento al progetto Foo.Bar con:

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

---

Il sistema progetto dnx è cop ..., ehm, pesantemente influenzato da quello di NodeJS, quindi fare affidamento sulla struttura delle directory per inferire determinati attributi.

Si prevede che i progetti si trovino in sottocartelle della radice e che ciascuno abbia il proprio file project.json. La "radice" stessa deriva dal file global.json situato all'albero delle cartelle. Lo strumento attraversa le cartelle da "corrente" fino a trovare global.json. La cartella con global.json viene quindi considerata la "radice di tutte le radici". Se basta creare la vostra soluzione da un modello, si avrà qualcosa di simile:

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

Quando si è in una delle sottocartelle, l'attrezzatura sapranno radice soluzione attraversando le cartelle su. Simile a come funziona git.

Se si guarda il file global.json, probabilmente vedrete qualcosa di simile:

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

Ciò significa che l'attrezzatura DNX si aspetta di trovare progetti nell'ambito /src e /tests, il gioco è fatto.

Ora, da questo, posso dedurre un'altra possibile soluzione. Non ho provato da solo, ma solo potrebbe funzionare. Invece di spostare il progetto Foo.Bar fuori a /src, è possibile aggiungere il percorso a projects in global.json:

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

Come ho detto, non so se questo funzionerà o creare alcune altre incongruenze sottili. Provalo.