riferimento un csproj dalla stessa soluzione xproj

Question

ho una soluzione con i seguenti progetti:

MySolution.sln 
    - MySolution.Client.csproj 
    - MySolution.Service.csproj 
    - MySolution.Models.csproj 
    - MySolution.Server.xproj 

MySolution.Models è una libreria di classi semplice, che contiene il codice condiviso a cui fa riferimento MySolution.Client e MySolution.Service - e mi piacerebbe fare riferimento a MySolution.Server.

La GUI in VS 2015 RC1 consente di aggiungere il riferimento facendo clic con il tasto destro su Riferimenti -> Aggiungi riferimento. Vedo quindi tutti i miei progetti in Progetti -> Soluzione.

seleziono MySolution.Models e cliccare su OK, dopo di che ricevo il seguente errore nel registro di uscita:

Errors in ...PathToSolution\MySolution.Server\project.json 
    Unable to locate MySolution.Models >= 1.0.0-* 

E 'davvero si sente come questo dovrebbe funzionare, dal momento che la GUI mi permette di aggiungere il riferimento, senza qualsiasi singhiozzo.

Answer 1

Quindi la prima cosa da capire è che i progetti DNX non comprendono i progetti tradizionali .net. Non leggono o analizzano i file csproj. Questo è fatto per mantenerli cross-platform e cross compatibili con IDE (csproj è chiaramente una finestra e una cosa specifica per VS).

Quando si aggiunge un riferimento a un "legacy" (io uso legacy per indicare un progetto basato su .net 4.x csproj) dietro le quinte l'IDE eseguirà dnu wrap ma sembra che nel tuo caso qualcosa si sia rotto.

Il seguente dovrebbe essere fatto automaticamente.

1. Nella soluzione root global.json una cartella "wrap" deve essere aggiunta alla proprietà dei progetti .
2. Una cartella fuori dalla radice denominata "wrap" verrà creata se non esiste.
3. Un /wrap/project.json verrà creato/aggiornato con un percorso all'assembly (dll).
4. Aggiungere un riferimento all'assembly e versione al file project.json del progetto di riferimento.

Quindi la prima cosa da verificare è assicurarsi di avere una cartella "wrap" e il riferimento a capo nella proprietà projects di solution.json. Se non lo fai allora probabilmente qualcosa "rotto". Prova a rimuovere la ricostruzione di riferimento e ad aggiungere il riferimento. Controllare la finestra di output di generazione per eventuali errori (VS è ancora RC quindi ci sono errori che probabilmente dovrebbero essere fermati che non lo sono).

Cercare project.json nella cartella wrap. Dovrebbe assomigliare a questo:

{ 
    "version": "1.0.0-*", 
    "frameworks": { 
    "net452": { 
     "wrappedProject": "../../LegacyClassLibrary/LegacyClassLibrary.csproj", 
     "bin": { 
     "assembly": "../../LegacyClassLibrary/obj/{configuration}/LegacyClassLibrary.dll", 
     "pdb": "../../LegacyClassLibrary/obj/{configuration}/LegacyClassLibrary.pdb" 
     } 
    } 
    } 
} 

Nota la versione quadro. In caso di mancata corrispondenza, fallirà la risoluzione delle dipendenze. Ad esempio se il tuo MySolution.Models ha come target .Net 4.6 e quindi quando è avvolto ha un riferimento di framework dnx46 ma il tuo progetto MySolution.Server ha un riferimento a dnx452 (nel progetto.json per MySolution.Server) quindi fallirà quando risolverà la dipendenza a MySolution.Models.

Probabilmente il tuo preventivo potrebbe essere migliorato. Ciò significa che non potrebbe risolvere la dipendenza a causa di uno dei seguenti motivi

• esso non abbiamo trovato un gruppo MySolution.Models (sia codice sorgente o dll compilato) sulla base dei percorsi che utilizza (a partire dal parametro progetti nel globale.JSON).
• Ha trovato un assembly MySolution.Models (sia codice sorgente o compilato), ma era una versione non valida. Controllare la versione nel progetto Models vs il riferimento in Server project.json.
• Ha trovato un assembly MySolution.Models ma non è in grado di risolvere le dipendenze del framework (ad esempio, i modelli richiedono dnx46 ma il server punta solo a dnx452).

Nella mia esperienza il terzo se il più comune. Per i modelli DNX in VS 2015 RC il framework completo predefinito scelto è dnx452 (o è dnx451?). I nuovi progetti csproj saranno 4.6 (dnx46) per impostazione predefinita e i progetti esistenti potrebbero essere qualsiasi cosa.

Una soluzione alternativa: Ho trovato la seguente alternativa per ottenere una gestione delle dipendenze più semplice. Se MySolution.Models verrà utilizzato solo dai progetti DNX, convertirlo in un progetto DNX spostarlo nella cartella di origine e fare riferimento direttamente. Farà parte della compilazione sorgente e otterrai i benefici della compilazione dinamica.

Se MySolution.Models fa riferimento a entrambi i progetti DNX e legacy (csproj), è possibile creare un file side-by-side xproj e project.json per Modelli. Saranno ignorati dal progetto legacy. In sostanza hai sia un progetto legacy che DNX che usa gli stessi file sorgente. Puoi quindi semplicemente fare riferimento sopra direttamente. Tenere presente la struttura delle cartelle se la cartella dei modelli non è in/src (e probabilmente non lo è se si trattava di un progetto esistente), quindi sarà necessario spostarlo o aggiungere un riferimento alla cartella in global.json. Sembrava più confusionario che sia davvero. Basta tenere a mente per un progetto DNX il global.json definisce i percorsi relativi a dove DNX può trovare il codice sorgente. Il DNX può anche risolvere dipendenze da nuget o dalla ricerca del GAC, ma ciò va ben oltre ciò che si sta tentando di fare.