Comment partager des ressources Web communes entre des applications Web dans Visual Studio?

Question

J'ai trois projets d'application Web qui partagent une bibliothèque commune de contrôles serveur personnalisés. Le partage du code derrière les fichiers est facile - ils sont compilés dans une DLL que je référence dans les autres projets en utilisant une référence de projet. Mais comment gérer des fichiers comme JavaScript, des feuilles de style et des images? J'essaye de faire ceci "la voie de Visual Studio" de sorte qu'il soit aussi facile que possible de comprendre et déboguer.

La configuration actuelle est un peu comme ceci:

 
CommonControlsWebApp 
+- CustomControls 
+- resources 
    +- images 
    +- scripts 
    +- stylesheets 

WebApp1 
+- resources* 

WebApp2 
+- resources* 

WebApp3 
+- resources* 

*) répertoire virtuel dans IIS.

Le répertoire virtuel de chaque application Web pointe vers le répertoire de ressources de mon CommonControlsWebApp. Ceci est configuré dans IIS. Visual Studio n'est pas capable de comprendre ce lien, donc le débogage nécessite que je me connecte au processus IIS manuellement.

Une autre solution pourrait être d'inclure chaque ressource dans la DLL commune en utilisant WebResourceAttribute. Mais cela transformerait src liens en quelque chose comme WebResource.axd? D = GUID quand je regarde la source de mes pages Web, et j'ai peur que cela rende assez déroutant pour déboguer.

Une troisième solution consisterait à utiliser Subversion pour inclure les mêmes fichiers dans les trois solutions. Personne dans l'équipe n'a essayé cela auparavant, donc nous ne sommes pas sûrs de la façon dont cela fonctionnerait. Je pense qu'il me manque une bonne solution évidente sur la façon de configurer les projets. Aucune suggestion?

Answer 1

De nombreux développeurs de contrôles regroupent leurs ressources Web à l'aide de la seconde méthode que vous décrivez - en les ajoutant en tant que ressources incorporées dans le fichier .dll. De cette façon, vous pouvez distribuer les contrôles sans devoir copier un tas de dossiers et de fichiers dans chaque site Web qui veut les utiliser, et assurez-vous que les chemins de dossiers correspondent tous, etc. Vous bénéficiez également de la localisation/internationalisation beaucoup plus facile de vos ressources.

Cependant, la chose WebResource.axd est un inconvénient. Vous pouvez généralement "déboguer" les URL avec quelque chose comme Firebug pour voir ce qui a réellement été retourné par la requête, mais je suis d'accord, cela peut être pénible si quelque chose ne fonctionne pas correctement. Un autre inconvénient est que si vous avez des dizaines de ressources pour un contrôle serveur, surtout si elles sont référencées plusieurs fois (pensez à une arborescence avec des centaines de petites images sur les nœuds), alors les URL peuvent ajouter une tonne d'octets réels à la finale Sortie HTML

Si vos besoins de distribution/localisation dépassent vos besoins d'optimisation/débogage, je considérerais l'intégration des ressources. Si ce n'est pas le cas, alors vous pourriez certainement faire # 3 - tout copier sur votre site Web en utilisant Subversion. Découvrez SVN Externals pour savoir comment le configurer. Un peu de temps investi dans l'apprentissage maintenant pourrait vous faire économiser des tonnes sur la route!

Answer 2

J'ai choisi la solution la plus simple et j'ai mis tous mes projets dans une solution unique. Ensuite, j'ai créé un projet WebUserControlLibrary dans lequel j'ai mis tous les contrôles partagés.

Pour les obtenir dans l'autre projet, je puis configuré l'événement de construction pour chaque projet de copier le SCU dans un dossier spécial:

copy "$(SolutionDir)WebUserControlLibrary\UserControls\*.ascx" 
    "$(ProjectDir)ImportedUserControls\UserControls" 

Et bien sûr, font référence au WebUserControlLibrary des projets qui en ont besoin.

avantages de cette approche:

• Debugging dans les travaux de Visual Studio,
• Aucune reproduction Code

Inconvénients:

• solution Maladroit :)
• Après avoir changé un fichier .ascx, le projet a être reconstruit. Cela signifie qu'il n'est pas possible de modifier le code HTML et d'actualiser la page dans Internet Explorer et de voir les résultats directement.

Answer 3

J'ai deux ou trois options pour jeter dans le seau:

Option 1: Utilisez un projet partagé pour vos ressources: http://rion.io/2017/03/22/sharing-is-caring-using-shared-projects-in-asp-net/

options 2 Transformez votre bibliothèque de classes dans un paquet NuGet. Je ne crois pas que vous avez à faire beaucoup lors de l'emballage autre que ce qui suit pour inclure tous les dossiers et fichiers withing le dossier du projet NuGet:

c: \ nuget.exe emballer YOURPROJ.csproj -IncludeReferencedProjects Plate-forme -prop = AnyCPU -Exclude **. Tt -Exclude **. Txt