web-dev-qa-db-fra.com

Migrer vers .NET Core à partir d'une application Web ASP.NET 4.5 MVC

Je viens de recevoir une mission avec une technologie que je ne connais pas très bien - notre belle application Web Windows ASP.NET MVC devrait être convertie pour être utilisée dans un environnement Linux.

Je travaille dans le domaine de la santé et nous avons des données utilisateur qui ne peuvent absolument pas être perdues ou les têtes rouleront (les nôtres ou les leurs).

Je ne suis généralement pas un gars C #/ASP.NET - bien que je puisse m'adapter à la tâche. J'ai lu les documents officiels @ http://docs.asp.net/en/latest/getting-started/installing-on-linux.html et je peux voir que cette tâche est effective signifie "cibler le framework .NET CORE (ou mono)".

J'ai parcouru Google et il n'y a aucun moyen de facto/facile de migrer, semble-t-il - apprenez simplement la nouvelle configuration modulaire avec les configurations configurées dans project.json et c'est parti! Avant d'essayer de le faire manuellement, y a-t-il des informations sur lesquelles vous pourriez me conseiller? Quelques processus systématiques à suivre? Peut-être quelques "accrochages" que j'aurais dû lire à l'avance?

Le projet utilise NHibernate et Autofac pour DI - semble assez standard. Je voulais juste savoir combien de lecture/d'expérimentation cela prendrait pour le faire fonctionner sur un serveur Linux - en fin de compte, c'est ce qui compte.

c#asp.net.netasp.net-mvcasp.net-core
21
JensenB

La réponse ci-dessous est dépassée mais décrit une solution de travail pour mettre à jour une application MVC .Net 4.5 vers le framework .Net Core. .Net Core est prêt pour la production

Le Core CLR et le BCL ne sont pas prêts pour la production. Période. Du moins pas encore et probablement pas pendant six mois à un an. Le support de la dépendance est encore plus inconnu à ce stade. Autofac n'a pas de bibliothèque compatible core clr. Vont-ils? C'est un endroit où commencer les recherches. Quand le feront-ils? Cela peut prendre un certain temps et c'est une exigence de projet qui échappe à votre contrôle.

Même pour les travaux hors production, le noyau .NET est encore très tôt. La réponse simple serait de dire à votre patron d'attendre six mois et de voir comment tout se déroule plutôt que de brûler potentiellement des centaines d'heures de travail ou du code de pré-production. Bien sûr, cela sera probablement ignoré, alors voici comment je procéderais aujourd'hui si je le devais.

Il y a quelques changements réunis dans votre question. Vous cherchez à migrer d'ASP.NET 4.5 vers ASP.NET 5. Vous cherchez également à cibler un nouveau cadre. Enfin, vous prévoyez d'exécuter la solution dans un nouvel environnement. Chacun d'entre eux peut être géré indépendamment (bien que certains pas avant les autres), c'est donc la voie que je prendrais.

Phase 0) Il n'y a pas de versions DNX prises en charge du framework .Net avant 4.5.1. Vous utiliserez DNVM pour sélectionner un DNX à cibler. Vous ne pouvez pas cibler ce qui n'est pas disponible, donc si votre projet cible actuellement quelque chose avant la mise à jour 4.5.1 et vérifiez qu'il n'y a pas de changements de rupture. S'il existe des correctifs et maintenez la base de données compatible avec la version 4.5.1 ou ultérieure.

Phase 1) DNVM et DNX sont compatibles avec le .Net Framework "complet" (4.5.1+) et .Net Core (5.0). Il peut être tentant de passer directement à ASP.NET 5 fonctionnant sur .Net Core 5, mais ce serait une erreur. Étant donné que .Net Core nécessite un projet basé sur dnx et que les projets basés sur dnx prennent également en charge .Net 4.5.1 (ou version ultérieure), la première étape serait de passer à la nouvelle structure de projet introduite par asp.net 5. Cela nécessitera probablement une certaine expérimentation. et la documentation est spartiate à ce stade. La cible serait votre application existante (asp.net 4.5 fonctionnant sur .net framework 4.5.1 fonctionnant dans le dnx. Il n'y a pas d'assistant de migration de projet donc vous partirez d'un nouveau projet dnx (utilisez asp.net 5 "vide") modèle) et la copie dans votre code existant. Cela peut sembler un changement mineur, mais il rompt ce couplage étroit de l'application à un framework installé sur les fenêtres uniquement hôte. Une fois que la base de code s'exécute dans un environnement dnx, vous avez les bases nécessaires pour cibler d'autres environnements.

Phase 2) Migrez vers asp.net 5 (MVC 6). Vous viserez toujours le framework .net "complet" et vous exécuterez sur Windows. .Net core ne prend pas (et ne prendra jamais) en charge la version asp.net existante de votre projet (4.5). Cependant, asp.net 5 est compatible avec le framework complet (4.x) et le core (5). Cela vous donne la possibilité de passer à asp.net 5 sans passer au noyau .net. La cible à la fin de la phase 2 est l'application Web (fonctionnelle) utilisant asp.net 5 fonctionnant sur .net 4.x en dnx. Oui, toujours sous Windows, mais nous nous rapprochons de la compatibilité multiplateforme.

Phase 3) Prenez la liste d'inventaire des références et des dépendances BCL existantes qui ne sont pas prises en charge dans le noyau .net. Refactorisez les références BCL existantes qui ne sont pas prises en charge dans le noyau .net. N'oubliez pas que le noyau .net est un sous-ensemble du cadre complet, vous pourriez donc être chanceux et que tout le code existant répond à ce sous-ensemble, mais si vous ne le faites pas, vous devez trouver un moyen d'obtenir les mêmes fonctionnalités avec le sous-ensemble disponible dans le noyau .net.

Pour les dépendances (c'est-à-dire Autofac), il est très probable que vous ayez besoin d'une mise à niveau et il peut y avoir des changements de rupture qui doivent être résolus. La cible et la fin de la phase 3 est l'application web de la phase 2 mais sans dépendances incompatibles avec le core bcl. Le plus grand facteur hors de votre contrôle est les packages tiers. Si autofac ne libère pas de package compatible core clr, vous êtes bloqué (ou devrez envisager d'utiliser une alternative).

Phase 4) La fin de la phase 3 signifie que vous disposez d'une pile conforme au noyau .net mais que vous ciblez toujours le framework complet. Maintenant, vous allez enfin basculer la cible vers core clr (dnvm prend en charge plusieurs runtimes côte à côte = dnx). Je déploierais toujours à Windows à ce stade, une variable à la fois. À la fin de la phase 4, l'application Web s'exécute sur le noyau .net hébergé dans l'environnement Windows.

Phase 5). Vous pouvez maintenant travailler sur la résolution des dépendances Windows. Au minimum, pour migrer hors IIS, assurez-vous que la gestion des chemins est effectuée de manière neutre pour le système d'exploitation et qu'il n'y a aucun appel à des ressources spécifiques à Windows (comme le registre). Le noyau clr et bcl devraient être plus matures à ce stade afin que vous n'essayiez pas de viser une cible en mouvement.

Essayer de tout faire en une seule fois est à mon avis une recette pour un désastre. Avec autant de changements parallèles, vous commencerez avec une solution non fonctionnelle et elle restera probablement non fonctionnelle. En le prenant en plusieurs phases, vous pouvez migrer la solution vers une cible de compatibilité croisée tout en ayant une sortie fonctionnelle à chaque étape du processus.

19
Gerald Davis

Je sais que c'est une vieille question, mais je pense que je dois la mettre à jour. Parce que certaines applications de production migrent asp.net mvc vers asp.net core. Je rassemble une migration étape par étape. J'espère que ça va être utile.

Oui c'est possible.

1) Créez une nouvelle application Web ASP.NET Core vide portant le même nom que le projet précédent. L'espace de noms sera donc identique.

2) Installez les packages NuGet Microsoft.AspNetCore.Mvc Et Microsoft.AspNetCore.StaticFiles. Le runtime ASP.NET est modulaire et vous devez explicitement accepter de servir des fichiers statiques

3) Ouvrez le fichier .csproj et ajoutez une cible PrepareForPublish: par exemple

  <Exec Command="bower install" />
</Target>

4) Ouvrez le fichier Startup.cs et modifiez le code pour qu'il corresponde à ce qui suit:

namespace WebApp1
{
    public class Startup
    {
        public void ConfigureServices(IServiceCollection services)
        {
            services.AddMvc();
        }

        public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
        {
            loggerFactory.AddConsole();

            if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
            }

            app.UseStaticFiles();

            app.UseMvc(routes =>
            {
                routes.MapRoute(
                    name: "default",
                    template: "{controller=Home}/{action=Index}/{id?}");
            });
        }
    }
}

5) Ajoutez un dossier Contrôleurs, puis ajoutez la classe de contrôleur MVC portant le nom HomeController.cs au dossier Contrôleurs.

  • Ajoutez un dossier Vues.
  • Ajoutez un dossier Vues/Accueil.
  • Ajoutez une page de vue Index.cshtml, MVC au dossier Views/Home.

Pour le test intermédiaire, veuillez faire ce qui suit

Remplacez le contenu du fichier Views/Home/Index.cshtml par ce qui suit:

<h1>Hello world!</h1>

6) Migration des fonctionnalités du projet ASP.NET MVC. Nous devrons déplacer les éléments suivants:

  • contenu côté client (CSS, polices et scripts)
  • contrôleurs
  • vues
  • des modèles
  • regroupement
  • filtres
  • Connexion/déconnexion, identité

7) Copiez chacune des méthodes de OldController ASP.NET MVC vers NewController

8) Copiez les fichiers de vue Razor About.cshtml, Contact.cshtml Et Index.cshtml Du projet ASP.NET MVC vers le projet ASP.NET Core.

9) Exécutez l'application ASP.NET Core et testez chaque méthode.

10) Pour le contenu statique Ajoutez un fichier de configuration Bower nommé bower.json À la racine du projet (cliquez avec le bouton droit sur le projet, puis Ajouter> Nouvel élément> Fichier de configuration Bower). Ajouter Bootstrap et jQuery au fichier

11) Copiez le fichier favicon.ico de l'ancien projet MVC dans le dossier wwwroot du projet ASP.NET Core.

12) Copiez le fichier _ViewStart.cshtml De l'ancien dossier Vues du projet ASP.NET MVC dans le dossier Vues du projet ASP.NET Core. Le fichier _ViewStart.cshtml N'a pas changé dans ASP.NET Core MVC.

13) Créez un dossier Vues/Partagé.

14) Copiez le fichier _Layout.cshtml De l'ancien dossier Views/Shared du projet ASP.NET MVC dans le dossier Views/Shared du projet ASP.NET Core.

15) Modifiez certaines anciennes fonctionnalités de la vue du rasoir avec des nouvelles comme les suivantes

  • Remplacez @Styles.Render("~/Content/css") par un élément <link> Pour charger bootstrap.css
  • Supprimez @Scripts.Render("~/bundles/modernizr"). Mettez en commentaire la ligne @Html.Partial("_LoginPartial") (entourez la ligne avec @*...*@).
  • Remplacez @Scripts.Render("~/bundles/jquery") par un élément <script>.
  • Remplacez @Scripts.Render("~/bundles/bootstrap") par un élément <script>.
7
orhun.begendi

Je pense que vous mélangez les préoccupations ici. Votre déclaration de problème initiale est que vous avez une application MVC en cours d'exécution sur Windows qui doit s'exécuter sur Linux. Ce n'est pas en soi un problème. Vous continuez ensuite en disant que vous l'avez recherché et en êtes arrivé à la conclusion que vous devez installer ASP.Net 5 (core) afin d'utiliser votre site sous Linux, ce qui est faux.

Les projets ASP.Net MVC fonctionneront correctement dans Mono .

Mono est une implémentation open source de .NET Framework de Microsoft basée sur les normes ECMA pour C # et Common Language Runtime.

Cela étant dit, Mono est une implémentation open source. ASP.Net 5 est une offre officielle de Microsoft, mais il n'est pas directement rétrocompatible avec la base de code existante. Il fonctionne également au-dessus de Mono.

Vous devez évaluer vos besoins avec votre chef de projet pour déterminer si l'utilisation de Mono est acceptable; dans certains domaines sensibles (Santé par exemple), l'Open Source n'est pas largement accepté. Soyez prêt à expliquer que même si le Mono Framework est open source, votre application s'exécutant dans le Mono Framework ne l'est pas. En général, cependant, les organisations qui adoptent Linux utilisent plus de logiciels Open Source qu'elles ne le pensent, qu'elles le veuillent ou non.

En bout de ligne, vous pouvez certainement exécuter votre application MVC sur Linux sans beaucoup de changements à la base de code en utilisant le Mono Framework. Si l'utilisation de la distribution Linux officielle de Microsoft ASP.Net 5 est une exigence du projet, vous réécrirez de toute façon une partie importante de votre application, avant même de vous préoccuper de Linux contre Windows.

De plus, un autre addendum à noter, ASP.Net 5 est presque entièrement Open Source de Microsoft, de sorte que l'argument contre l'utilisation de Mono peut être théorique, même s'il sera probablement mentionné.

5
Claies