Perché la migrazione da DNX a .NET CLI richiede modifiche nel codice?

Question

Oggi la versione RC1 di ASP.NET Core funziona con DNX. Come ho capito, il cambiamento principale per RC2 sarà che ASP.NET Core inizierà a lavorare con .NET Core CLI.

Ora questo ha fatto meraviglia su quanto segue: se DNX e .NET CLI sono solo strumenti per spiegare perché questa migrazione richiede modifiche al codice?

Infatti oggi c'è stato l'annuncio Microsoft.AspNetCore.Mvc.Dnx is required to allow Mvc in RC2 to work with Dnx su cui si vede che per usare ASP.NET MVC core con DNX abbiamo bisogno di aggiungere un unico pacchetto e di più, abbiamo bisogno di cambiare il nostro codice in modo da avere sul metodo di StartupConfigureServices una chiamata a services.AddMvcDnx();

Questo mi confonde. Ho capito che DNX e .NET Core CLI erano solo strumenti per l'esecuzione di app .NET Core. Se questo è solo uno strumento, perché la migrazione da uno all'altro richiede modifiche al codice?

Answer 1

Questo mi confonde. Ho capito che DNX e .NET Core CLI erano solo strumenti per l'esecuzione di app .NET Core. Se questo è solo uno strumento, perché la migrazione da uno all'altro richiede modifiche al codice?

DNVM/DNU/DNX non erano solo strumenti. DNX era anche il runtime. Era responsabile del bootstrap del CLR e della chiamata dell'applicazione. Ciò significava anche che aveva molte informazioni sul runtime e sull'applicazione, come dipendenze, ambiente, ecc. Queste informazioni sono state rese disponibili all'applicazione attraverso vari servizi che è possibile iniettare, come IRuntimeEnvironment, IApplicationEnvironment e ILibraryManager.

A sua volta, MVC ha un servizio chiamato IAssemblyProvider. Questo è responsabile della fornitura degli assembly in cui MVC dovrebbe cercare controller, tra le altre cose. L'implementazione predefinita di questo, era basata su ILibraryManager, che è un servizio specifico DNX. Ciò significa che non funzionerà più quando si passa a un runtime basato su dotnet, che viene disattivato dai pacchetti, invece di utilizzare uno strumento separato, come DNVM.

Per risolvere questo problema, il team MVC ha iniziato la propria attività in base a entrambi i servizi DNX e la nuova alternativa dotnet (Microsoft.Extensions.DependencyModel). Puoi vedere il codice here. In pratica controlla se lo specifico DN23 ILibraryManager è disponibile e, in caso contrario, ricade sull'API dotnet alternativa.

Il problema con questo approccio è che introduce extra, e nella maggior parte dei casi, ridondanti, dipendenze (Microsoft.Extensions.PlatformAbstractions.Dnx) in MVC, quando la maggior parte delle persone inizierà a utilizzarlo con strumenti e runtime dotnet. Ricorda; DNX ecc. È ancora roba beta e sarà rimosso da RTM.

Invece, hanno optato per la soluzione corrente; avere un pacchetto separato, Microsoft.AspNetCore.Mvc.Dnx, che contiene, tra le altre cose, lo IAssemblyProvider basato su DNX per MVC. Puoi vedere che cos'è il metodo AddMvcDnxhere.

Ciò significa che le poche persone che stanno seguendo le pre-release dovranno apportare alcune modifiche al loro codice, per poter continuare a funzionare su DNX (anche se mi trasferirei a dotnet ASAP), mentre nuove persone sarebbero Devo solo chiamare AddMvc come al solito.

Spero che questo abbia un senso. Può essere davvero confuso :)

Answer 2

Non è il cli switch DNX to dotnet, che richiede le modifiche al codice. È RC1 a RC2. Come si può vedere nel rc2 milestone announcements, 31 annunci su 34 riguardano le modifiche alle interruzioni.

Tutti i pacchetti e gli spazi dei nomi associati sono stati modificati, da Microsoft.AspNet.* a Microsoft.AspNetCore.*, lo stesso per il framework di entità.

Se si avesse un RC2 su dnx e poi si passasse a dotnet cli, non ci sarebbero molti cambiamenti di codice (se non del tutto), tranne per il modo in cui l'applicazione viene avviata.

Non ci sono più comandi in dotnet cli e molto probabilmente non torneranno indietro. Per dotnet cli è necessario avviare in modo esplicito l'applicazione simile a questo:

public static void Main(string[] args) 
    { 
     var host = new WebHostBuilder() 
        .UseServer("Microsoft.AspNetCore.Server.Kestrel") 
        .UseStartup<Startup>() 
        .Build(); 

     host.Start(); 
    } 

Non è ancora uscito, modifiche del codice in modo che si infrangono sono ancora da aspettarselo.

Scavando po 'sul GitHub (fonte e problemi), ho ottenuto questo qui:

La RC1 e costruisce precoce di RC2 utilizzato per iniettare IMvcRazorHost nella ICompilationService attuazione, che non è più disponibile. Ora viene utilizzato il RazorLoadContext come si può vedere nel new package's commit.

Inoltre, possiamo vedere come target DOTNET5_6 che è un nuovo moniker, che indica un nuovo livello platform standard (dotnet 5.1 equivale a netstandard 1.0, dotnet54 equivale a 1,3, quindi dotnet56 equivale a netstandard 1.5).

Questo numero here indica la transizione a dotnet56/DOTNET5_6.