2009-09-28 7 views
2

J'ai une application Web ASP.Net qui est déployée sur un certain nombre de serveurs clients différents et hébergée dans IIS (6 ou 7 selon le site). Le système est basé sur un ensemble de pages ASP.Net (aspx) assez complexes. En raison de l'évolution rapide des exigences, nous devons souvent ajouter des formulaires au système. Pour le moment, nous utilisons une approche assez maladroite consistant à ajouter le formulaire au projet et à redéployer l'ensemble du projet sur le serveur client. Je cherche à construire un mécanisme qui nous permettra d'aller dans l'écran de configuration de notre système et d'appeler un webservice hébergé sur notre serveur web central qui fournira une liste de formulaires (peut-être emballés d'une manière ou d'une autre similaires dans un fichier WAR Java) que le client peut choisir d'installer. L'installation ajouterait en quelque sorte le formulaire à l'IIS du client le rendant disponible dans leur système. L'idée est pour une sorte de magasin d'applications de forme aspx où nos clients peuvent choisir les formes dont ils ont besoin et les installer et plutôt que de devoir prendre le temps d'effectuer plusieurs déploiements que nous déployons simplement une fois sur notre serveur web central.Ajout d'un formulaire ASP.Net à une application Web ASP.Net déployée existante

Est-ce que quelqu'un a des idées sur la façon de faire cela? Quelles technologies puis-je utiliser pour que cela se produise?

Répondre

2

Si vous utilisez des projets d'application Web, ce n'est pas si simple car tous vos formulaires 'code-behind' seront compilés en une seule DLL. Chaque fois que vous ajoutez un nouveau formulaire, l'assembly d'application de site doit être redéployé dans le dossier /bin. Si vous utilisiez les applications Web sans nouveau style telles que présentées dans Visual Studio 2005, il serait peut-être possible de faire ce que vous cherchez, car vous pouvez compiler chaque page dans sa propre DLL (Correction des noms et des assemblages d'une seule page dans le dialogue Publish Web Site). J'ai essayé cela dans le passé et c'est un peu hasardeux pour être honnête. De plus, ne pas avoir un bon dossier de projet est une douleur totale pour les projets plus importants et plus complexes.

Une autre approche serait de mettre tout votre balisage et 'code-behind' dans le même fichier .aspx au lieu d'avoir des fichiers code-behind .aspx.cs. Je pense que cela ferait d'eux des unités autonomes de code qui seraient compilées à la volée, mais le problème ici est que tout le site devrait être construit de cette façon ... je pense.

Ce sont les méthodes prêtes à l'emploi disponibles dans Visual Studio (2008). Si vous avez besoin de quelque chose de plus complexe, vous devrez concevoir une infrastructure pour y arriver malheureusement.

+0

Merci pour ça, j'avais des doutes sur le fait que je devrais construire quelque chose mais je voulais que quelqu'un le confirme, alors je n'avais pas l'impression de "réinventer la roue"! – colethecoder

0

Il semble que vous êtes intéressé à trouver un moyen de déployer uniquement les modifications! Ce n'est généralement pas une bonne idée de déployer uniquement les modifications car il est assez facile de rater un fichier ou deux, puis l'ensemble de l'application se bloque. Je pense que vous devriez vous concentrer davantage sur la construction et le déploiement de l'automatisation qui vous aidera à déployer sur plusieurs serveurs en cliquant sur un bouton.

+0

Je vois ce que vous dites mais ce que je veux, c'est que les clients puissent télécharger les formulaires dont ils ont besoin plutôt que de déployer tous les formulaires sur chacun d'entre eux, d'où la fonctionnalité «app store». L'automatisation du build et du déploiement ne va pas m'aider à le faire. – colethecoder

1

En fait, vous n'avez pas besoin de redéployer une application Web entière lorsque vous modifiez ou ajoutez un formulaire Web à une application préexistante. Publiez le site comme d'habitude, puis prenez simplement la page .aspx qui a été ajoutée, etc. Maintenant, récupérez les fichiers .dll associés qui ont été touchés quand la page a été ajoutée, créée. Cela pourrait être quelque chose d'aussi simple que les sites .dll ou vous pourriez inclure un bus .dll et un accès aux données .dll. Mais vous n'avez en aucun cas besoin de déplacer tous les fichiers alors que la plupart n'ont pas été modifiés. Pour une configuration préconfigurée avec ce système, vous pouvez utiliser un outil tel que nAnt et créer un script de construction qui s'appuiera sur les fichiers nécessaires, puis empaqueter ces fichiers dans un fichier zip auto-extractible qui placerait les fichiers , .dlls dans les chemins corrects sur le serveur Web cible.

Dieu merci pour votre projet, et j'espère que cela aidera certains.

Questions connexes