Modelli di costruzione e di progetto per il targeting di sapori .NET Core e .NET Framework?

Question

Modelli di costruzione e di progetto per il targeting di sapori .NET Core e .NET Framework?

#1 da (2 voti)
#2 da (0 voti)

3

Abbiamo una soluzione con 20 .DLL di .NET Framework 4.5 (diciamo helloworld01.dll a helloworld20.dll ) dove vogliamo aggiungere il supporto Linux (a ciascuno) nel prossimo futuro. Pensiamo che questo significhi che ognuno di questi deve essere ricompilato come target .NET Core 1.0.

Lasciando il codice sorgente portandolo da parte e osservando solo l'organizzazione / struttura, qual è la pratica consigliata per sviluppare, costruire e rilasciare .NET Core 1.0 con le DLL di .NET Framework ?

File .sln completamente nuovo + struttura di cartelle parallele per il codice?
Nuovo file di progetto ciascuno + struttura di cartelle parallele per il codice?
Nuovo file di progetto ciascuno + riferimenti nella struttura di cartelle esistente?
Lo stesso file di progetto + la stessa struttura di cartelle + qualche magia nera basata su msbuild? (Sospetto che non abbia dato i file xml vs json proj)
qualche altra magia?

Bonus: puoi indicare il progetto open source che incarna tali best practice?

c# .net visual-studio cross-platform .net-core

posta DeepSpace101 28.10.2016 - 06:00

fonte

2 risposte

Leggi altre domande sui tag c# .net visual-studio cross-platform .net-core

Il metodo più teso per eseguire una query SQL di grandi dimensioni in C # [chiuso] Come gestire il test con le funzioni di inizializzazione che chiamano funzioni simulate?

score 2 · Answer 1

A condizione che le librerie utilizzate dal codice in ogni DLL siano disponibili sia nel framework completo (4.5+) che in .NET Core. Quindi puoi effettivamente configurare un progetto che compila una DLL accessibile a entrambi i framework, scegliendo come target .NET Standard.

Questo è possibile anche con .NET Standard 1.6 (ovvero non è necessario attendere 2.0). La chiave è che ci sono ancora molte funzionalità dal framework completo che non è ancora disponibile in .NET Core, e colmare questa lacuna è ciò di cui tratta .NET Standard 2.0.

Il Project JSON per una libreria di classi a cui è possibile accedere da altri progetti di target diversi dovrebbe assomigliare a questo:

{
  "version": "1.0.0-*",
  "frameworks": {
    "net462": {
      "dependencies": {
      }
    },
    "netstandard1.6": {
      "imports": "dnxcore50"
    }
  },
  "dependencies": {
    "NETStandard.Library": "1.6.0",
    "System.ComponentModel.Annotations": "4.3.0",
    "System.ComponentModel.Primitives": "4.1.0",
    "System.Reflection.TypeExtensions": "4.3.0-preview1-24530-04"
  }
}

Spero che ti aiuti.

score 0 · Answer 2

I problemi che il mio team sta affrontando sono nuovi e riconosciuti anche dal team di .NET. Lo indirizzeranno in .NET Core "vNext" (1.2?) .

Questo è il momento in cui avremo molte funzionalità che consentono di affiancare le versioni di .NET Framework e .NET alle librerie principali come:

Supporto di MSBuild in .NET Core
Possibilità di utilizzare csproj per .NET Core (correlato a quanto sopra)
Possibilità di fare riferimento a DLL di .NET Core da progetti F / W .NET (e viceversa)

Più materiale, ma quanto sopra avrebbe davvero semplificato il caso d'uso nella domanda. Quindi la risposta è ...

Wait for .NET Standard 2.0