2016-06-18 46 views
19

Voglio:Come posso creare una libreria di classi .NET Core e farvi riferimento da un progetto .NET 4.6?

  • Fai una libreria di classi che definisce alcune interfacce e classi helper semplici generiche. Si baserà su raccolte generiche e su IQueryable<T> ma non su dipendenze di terze parti (beh,).
  • Essere in grado di fare riferimento a questa libreria di classi da qualsiasi luogo (in particolare UWP, net46 e ASP.Net Core RC2)
  • Idealmente, utilizzare il sistema project.json ovunque, anche se sono pronto a sacrificarlo se necessario.
  • Pubblica la libreria finita a un feed NuGet e da lì lo usano in altre applicazioni

Quando si crea il mio progetto di libreria di classi in Visual Studio 2015,2, ho trovato il modello Class Library (.NET Core), in cui si afferma

Un modello di progetto per la creazione di una libreria di classi come pacchetto NuGet che può indirizzare qualsiasi piattaforma

Qualsiasi piattaforma! Brillante ... Ma non riesco a farlo funzionare. Dopo un sacco di giocherellare, Attualmente sono disponibili le seguenti project.json (Probabilmente ho completamente rotto da ora):

{ 
"title": "My Really Useful Class Library", 
"copyright": "Copyright © 2015-16 Tigra Astronomy, all rights reserved", 
"description": "Really neat stuff", 
"language": "en-GB", 
"version": "1.0.0-*", 
"dependencies": { 
    "JetBrains.Annotations": "10.1.4", 
    }, 
"frameworks": { 
    "netstandard1.5": { 
     "imports": "dnxcore50", 
     "dependencies": { 
      "NETStandard.Library": "1.5.0-rc2-24027", 
      "System.Linq.Expressions": "4.0.11-rc2-24027" 
      } 
     } 
    "net46": { 
     "frameworkAssemblies": { 
      "System.Collections": "4.0.*" 
      }, 
     "dependencies": {} 
     } 
    }, 
    "buildOptions": { 
     "xmlDoc": true 
     } 
} 

La prossima cosa che ho fatto è stato creare il mio progetto 4.6 .NET Framework nella stessa soluzione, e prova a fare riferimento alla libreria di classi. Mi permette di aggiungere il riferimento, ma sto ricevendo errori di compilazione, simboli non risolti, R # è infelice, ecc.

Immagino che non lo stia facendo bene (non è una sorpresa, davvero, mentre sto armeggiando nel buio).

Ho letto alcuni documenti su TFM, framework e librerie, ma nessuno di questi ha molto senso.

Che cosa ho veramente bisogno di mettere in project.json di mia libreria di classi, in modo che possa fare riferimento dal mio NET Framework 4.6 app, e anche da UWP e ASP.NET core applicazioni RC2? È davvero l'approccio giusto o ho iniziato con il piede sbagliato?

+0

Per favore mi scusi per non aver ancora selezionato una risposta 'corretta'. Sto ancora lavorando su una serie di scenari che sono stati aggiornati alle ultime versioni di RTM e agli ultimi strumenti di anteprima. –

+1

Assicuratevi di controllare l'elemento ' StingyJack

risposta

3

I nuovi modelli di progetto/.xproj funzionano in modo leggermente diverso. Le nuove librerie di classi (e i modelli di applicazione) producono pacchetti di nuget, anziché semplici assembly.

All'interno di quel pacchetto di nuget sono raggruppati tutti i target. Detto questo, aggiungi il nuovo progetto allo stesso modo in cui aggiungi qualsiasi altro pacchetto di nuget: metti il ​​nuget in un feed nuget, fai riferimento a questo in Visual Studio e poi recuperalo da lì.

Se non si dispone di un server nuget in esecuzione (Visual Studio Team Services + pacchetto NuGet, myget, self-hosted) è anche possibile inserire i pacchetti in una cartella (condivisione locale o di rete) e aggiungere questa cartella come fonte nuget.

Se è troppo "troppo" lavoro, puoi anche creare due progetti in una cartella: A * .csproj e a * .xproj. * .csproj è destinato a .NET 4.6 Framework e * .xproj rimane come indicato sopra e ha più destinazioni. Con questa configurazione, puoi normalmente fare riferimento al progetto come prima (se si trova nella stessa soluzione), semplicemente aggiungendo un riferimento.

+3

I nuovi modelli non producono pacchetti di nuget per impostazione predefinita. Questo faceva parte di DNX/RC1 ma i modelli di progetto RC2 non lo fanno automaticamente in VS. Dovresti eseguire 'dotnet pack' per creare i pacchetti. –

35

Al momento esistono due modi per creare progetti C#: xproj e csproj. Supponendo che stiamo usando project.json per entrambi, che funziona ancora in modo diverso per i tipi di progetto - per xproj, lo project.json contiene tutto il necessario per costruire il progetto; per csproj, contiene solo le dipendenze di nuget.

Detto questo, alcuni tipi di progetto, come UWP, non possono essere creati con xproj a causa della necessità di una pipeline di costruzione più complicata di quella supportata da xproj/project.json. (BTW, questo era uno dei motivi principali per tornare a msbuild.)

Ci sono anche due modi per creare una libreria di classi basata su .NET. Puoi usare xproj con project.json, o come hai fatto tu può creare un normale progetto "Libreria di classi portatili" csproj. Con VS 2015 Update 3 RC, è possibile modificare il PCL per scegliere una versione .NET Standard (netstandard1.x anziché un profilo PCL, 259, ecc.).

Se si utilizza una libreria di classi csproj per il target netstandard1.x, le cose dovrebbero funzionare solo quando si aggiungono riferimenti di progetto. Si noti che UWP attualmente supporta fino a netstandard1.4 in base allo platform map. La sfida è se si desidera utilizzare un progetto basato su xproj/project.json. Uno dei motivi principali per l'utilizzo di xproj oggi consiste nell'abilitare la compilazione incrociata tra più framework di destinazione. Vale a dire, creare più di un output dal tuo progetto. È diverso rispetto alla creazione di un singolo output che può essere referenziato da qualsiasi progetto compatibile. Entrambi hanno i loro usi, dipende dalle tue esigenze.

Se si decide di creare una libreria di classi basata su xproj, è possibile utilizzare una soluzione per fare riferimento a un progetto UWP o qualsiasi altro tipo di progetto compatibile se la finestra di dialogo "Aggiungi riferimenti" non funziona (cosa che non 't as csproj ->xproj è praticamente rotto). Invece di utilizzare la finestra di dialogo, modificare l'UWP csproj per indicare l'uscita del xproj in questo modo:

<Reference Include="System.Reactive.Interfaces"> 
    <HintPath>..\System.Reactive.Interfaces\bin\$(Configuration)\netstandard1.0\System.Reactive.Interfaces.dll</HintPath> 
</Reference> 

Il frammento di sopra è tratto dal Rx.NET UWP test Runner here

Se si esegue questa operazione , dovrai anche aggiungere la dipendenza di build dal tuo progetto UWP al tuo xproj poiché MSBuild/Visual Studio non ne saprà nulla e creerà le cose nell'ordine sbagliato. Per fare ciò, fare clic con il tasto destro del mouse sul progetto UWP in Esplora soluzioni, quindi selezionare "Dipendenze di compilazione -> Dipendenze del progetto". In questa finestra di dialogo, seleziona la casella per il tuo xproj per assicurarti che VS/MSbuild sappia prima di crearlo.

Qui è possibile vedere la soluzione Rx.NET completa, che include i riferimenti xproj->xproj ei riferimenti UWP ->xproj che ho menzionato sopra.

+0

Grazie Oren, sta iniziando a dare un senso ora. Posso anche iniziare a capire perché la SM sta dicendo "aspetta i nuovi strumenti". Forse dovrei provare VS2015.3 RC ...Probabilmente voglio che la mia libreria lavori su obiettivi basati su UWP/ARM sotto IoT Core, quindi desidero usare un xproj. –

+2

Se il tuo obiettivo è quello di essere compatibile con UWP e ASPNet Core 1.0 e vuoi solo un singolo output, l'approccio più semplice sarebbe probabilmente un 'csproj' che si rivolge a' netstandard1.4'. Non è necessario un 'xproj' per questo e i riferimenti da progetto a progetto sono più facili in questo modo. –

+0

Oh, infatti, posso vedere quel collegamento nell'aggiornamento 2 del 2015 ... È necessario installare RC 2015.3 in questa fase? Dato che è un RC dovrebbe essere abbastanza stabile ... –

Problemi correlati