En un clin d'œil, cela fait 4 ans que Microsoft a lancé la plateforme .net, et .net a également connu des mises à niveau de 1.0 à 1.1 puis à 2.0. En raison de l'attrait de diverses fonctionnalités supérieures d'asp.net 2.0 et de l'IDE vs 2005, tout le monde est occupé à apprendre la version 2.0 et à mettre à niveau le projet vers vs 2005 pour le développement. Mais en fait, de nombreux projets ne peuvent pas être mis à niveau vers de nouvelles versions pour diverses raisons. Au fil du temps, le problème de la maintenance des anciennes versions des projets devient de plus en plus problématique. Même si le .net est né il y a peu, 4 ans suffisent pour accumuler un grand nombre de projets.
J'ai un projet développé avec vs.net 2002, qui n'a pas été mis à niveau pour diverses raisons (principalement parce que le projet fonctionnait bien depuis un certain temps avant la sortie de vs.net 2003 et que d'autres programmes asp.net sur le serveur Impossible pour s'adapter aux exigences de sécurité de .net 1.1).
Lorsque la plate-forme de développement de l'entreprise a été mise à niveau, vs.net 2002 et vs.net 2003 ont été installés simultanément sur l'ordinateur, ce qui a temporairement résolu la maintenance des différentes versions du projet. Plus tard, le projet a dépassé la période de maintenance et n'a pas été mis à jour depuis longtemps. Mon ordinateur a également été réinstallé et vs.net 2002 a été complètement éliminé. Mais en 2005, les clients demandaient des modifications tous les un ou deux mois, et il fallait qu'ils soient rapides. Ils étaient tellement enthousiastes qu'ils ont dû apporter des modifications même après la période de maintenance. Mais voici le problème. Sans vs 2002, il ne peut pas être compilé.
Il est très difficile d'installer .net framework 1.0 sur l'ordinateur et d'appeler manuellement csc pour compiler le code modifié. Le projet a beaucoup de références et l'écriture de la ligne de commande est très compliquée. Ceci est particulièrement pénible lorsque le projet comporte de nombreux dossiers. J'ai également passé le test et écrit un programme pour le compiler, mais j'étais paresseux et je ne m'en suis jamais rendu compte.
Aujourd'hui, je dois à nouveau modifier le programme, et tout à coup je me suis rappelé que j'avais utilisé l'attribut Src de la directive @Page très tôt (en 2002, en utilisant cet attribut, asp.net utilisera son propre modèle de compilation au lieu d'utiliser CodeBehind). de l'IDE vs.net De cette façon, le code peut être publié sans le compiler dans une dll Lors de l'accès au site, asp, net compilera automatiquement le fichier aspx et le fichier .aspx.vb ensemble. Cette méthode présente deux inconvénients principaux : 1. Le fichier de code (.vb) doit être publié sur le serveur, 2. vs.net IDE ne le prend pas en charge. À cause du deuxième problème, j’ai arrêté de l’utiliser et je l’ai oublié. Maintenant, je crains de ne pas pouvoir compiler le programme. Tant que le code modifié peut prendre effet, les autres défauts ne seront pas pris en compte. Quoi qu'il en soit, tout le code source est publié sur le serveur. J'ai ajouté un attribut Src à la directive @Page, en utilisant la même valeur que l'attribut CodeBehind, pointant vers le fichier de code. Modifiez ensuite le code dans le fichier .vb. Actualisez, les modifications prennent effet et la maintenance est terminée. Tellement cool. C’est ce que je ferai à partir de maintenant. Étant donné que l'IDE vs.net ne le prend pas en charge et qu'il est mentionné sur MSDN, peu de gens savent peut-être que .net a ce modèle de compilation. Partagez-le maintenant. Si quelqu'un ressent la même douleur que moi, vous pouvez également essayer d'ajouter Src à la page, c'est simple et rapide, cela prendra effet. pour trouver des outils pour le compiler.
Résumé : Beaucoup de gens, moi y compris, préfèrent compiler le programme dans une DLL, qui ressemble davantage à un logiciel publié. En fait, la méthode consistant à "publier tout le code source sur le serveur et à compiler complètement le code pendant l'exécution" est très bonne et simplifie grandement les futurs travaux de maintenance. De nombreuses entreprises réalisent des projets pour des clients qui n'ont pas réellement besoin de cacher le code source aux clients. Dans ce cas, l'utilisation de cette méthode apportera d'énormes avantages aux futurs travaux de maintenance. Peu importe que .net soit mis à niveau plusieurs fois ou que la version correspondante des outils de développement soit installée sur votre ordinateur, vous n'avez pas à vous inquiéter. gérer tout.
Remarque : Toutes les versions d'asp.net prennent en charge ce mode de compilation, mais l'IDE de vs.net 2002 et 2003 ne le prend pas en charge et ne peut pas ouvrir la vue conception. L'IDE récemment publié par rapport à 2005 prend en charge ce mode de compilation. Lors de l'utilisation de l'attribut Src, l'attribut CodeBehind n'est plus obligatoire, mais il est recommandé de le conserver. Il peut également vous aider si vous devez soudainement revenir à la vue de calcul. L'attribut Inherits n'est pas obligatoire, mais il est fortement déconseillé de le supprimer, car si vous liez directement l'événement dans la déclaration de contrôle du fichier aspx (comme : OnClick="...."), il y aura un erreur sans l'attribut Inherits.
Source : BLOG cwbboy