Sto sperimentando con Visual Studio 2015 RC, con particolare attenzione al passaggio al nuovo framework ASP.NET 5, alla struttura del progetto e al nuovo DNX che esegue le applicazioni ASP.NET 5.Quali sono le mie opzioni per la condivisione del codice tra progetti DNX/ASP.NET 5 (project.json/xproj) e altri progetti C# (csproj) all'interno di una singola soluzione?

Il mio datore di lavoro ha molte soluzioni esistenti per il .NET Framework 4.5.2. Nelle nostre soluzioni di Visual Studio esistenti potremmo avere i seguenti progetti:

[Solution] Sample.sln 
    [Folder] src 
     [Project] ClassLibrary.csproj 
     [Project] WindowsService.csproj 
     [Project] WebApplication.csproj 
    [Folder] test 
     [Project] ClassLibrary.UnitTests.csproj 
     ...

In questo scenario, ClassLibrary.csproj è una libreria C# classe contenente codice condiviso. È una dipendenza di/referenziato da entrambi WindowsService.csproj e WebApplication.csproj.

Non stiamo specificatamente cercando di utilizzare .NET Core, dnxcore50. In questa fase, contiamo su .NET Framework, dnx451. Tuttavia, stiamo assolutamente cercando di sfruttare le nuove funzionalità di ASP.NET 5 e la struttura del progetto associato.

Di seguito sono riportate alcune opzioni a cui ho pensato ma entrambi hanno problemi.

Opzione 1

Quando abbiamo sostituire il progetto WebApplication.csproj di cui sopra con un nuovo ASP.NET 5 progetto DNX WebApplication-dnx allora possiamo ancora fare riferimento al ClassLibrary.csproj sia da questo nuovo progetto DNX e il WindowsService.csproj progetto esistente. Tuttavia alcuni problemi sorgono:

Questo approccio significa che eventuali modifiche al codice di ClassLibrary.csproj bisogno di una ricostruzione per essere visibile in corsa WebApplication-dnx. Questo non è sorprendente, ma significa che non riceviamo i vantaggi completi di compilazione da fonte per WebApplication-dnx.
Non possiamo facilmente indirizzare altri framework, ad es. dnxcore50. Come sopra, questo non è specificamente un obiettivo in questa fase.

Opzione 2

Se sostituiamo ClassLibrary.csproj con un progetto di libreria di classi DNX^ClassLibrary-dnx quindi non si applicano i problemi in opzione 1. Questo approccio sembra essere più in linea con il modo in cui il runtime .NET e le tecnologie associate come ASP.NET verranno impacchettate.

Tuttavia non riesco a trovare un modo per fare riferimento a ClassLibrary-dnx da WindowsService.csproj. Se questo approccio è fattibile, immagino che la soluzione abbia qualcosa a che fare con l'opzione di livello di progetto per Produce outputs on build e quindi con riferimento allo .nupkg o forse anche allo .dll prodotto durante la compilazione. Tuttavia, non riesco a vedere un modo pulito per raggiungere questo attraverso gli strumenti.

^I progetti di libreria di classi DNX sono denominati Class Library (Package) in VS 2015 RC. Questo tipo di progetto era precedentemente chiamato ASP.NET Class Library nei CTP.

Sommario

Sulla base delle informazioni di cui sopra che sto cercando:

un feedback ai miei opzioni di scenario e problemi.
Suggerimenti per altre opzioni a cui non ho pensato.
Forse un'indicazione di quale approccio dovrebbe essere utilizzato per andare avanti.

fonte

2015-05-20 Matt Brooks

Avete considerato se 'dnu wrap' funzionerà? Il wrapping dei file .csproj nei file project.json. – vcsjones

Sì, la mia comprensione è che questo è ciò che gli strumenti ora fanno per te quando aggiungi un riferimento a .csproj come per l'opzione 1 sopra. –

Non l'ho provato, quindi non posso fare un write-up completo, ma per l'Opzione 2, potresti essere in grado di "Produrre output su build" del tuo xproj e quindi aggiungere un feed NuGet locale che punta alla directory delle tue risorse da raccogliere il pacchetto NuGet. Forse avrò un'opportunità più tardi stasera. –

Dai un'occhiata a cosa fa EntityFramework.

Destinano 3 TFM: net45, .NETPortable, Versione = v4.5, Profile = Profile7, frameworkAssemblies e hanno sia csproj che xproj in the same folder.

In sostanza, per ogni progetto sono disponibili due file di progetto.

Tuttavia non riesco a trovare un modo per fare riferimento a ClassLibrary-dnx da WindowsService.csproj.

Sfortunatamente, non è ancora possibile. Puoi solo fare riferimento a csproj da xproj, non viceversa. Avete due alternative: (1) hanno sia xproj che csproj come EF fa o (2) fanno riferimento al pacchetto NuGet da csproj.

Se si desidera eseguire l'alternativa (2), è possibile impostare l'output di xproj su una cartella e aggiungerlo come feed NuGet.

fonte

2015-05-21 15:56:07

Grazie per i riferimenti. Sperimenterò con l'approccio per (1). Lei dice "non è possibile, ancora". Secondo la tua opinione, sto affrontando questo problema perché al tooling manca attualmente il supporto per i flussi di lavoro suggeriti (1) o (2) o entrambi? Vedi il mio [commento] (http://stackoverflow.com/questions/30355208/what-are-my-options-for-sharing-code-between-asp-net-5-projects-xproj-and-oth#comment48839618_30355208) sopra per problemi che prevedo con workflow (2). –

Non esiste un supporto di per sé per lo scenario in strumenti ma è possibile ottenerlo con tutto ciò che esiste pubblicamente oggi: aggiungere una cartella come feed NuGet e creare un passo pre build nel csproj che invocherà NuGet per aggiornare il pacchetto. Un altro modo più semplice è solo di fare riferimento al file binario prodotto da xproj piuttosto che al nupkg –

Ho dimenticato quel punto da @VictorHurdugaci - le DLL grezze vengono restituite a '{solutionFolder} \ manufatti \ bin \ {xprojName} \ {configuration} \ { piattaforma} '; potresti farvi riferimento in questo modo invece di utilizzare una cartella come feed NuGet. –

Quali sono le mie opzioni per la condivisione del codice tra progetti DNX/ASP.NET 5 (project.json/xproj) e altri progetti C# (csproj) all'interno di una singola soluzione?

Opzione 1

Opzione 2

Sommario

risposta

Problemi correlati