Question

Chaque fois que je construis ou publie un site Web, Visual Studio tente d'extraire le fichier web.config afin d'ajouter de nombreux assemblys non requis.

En d'autres termes:

web.config avant:

<configuration>
   <system.web>
      <compilation>
         <assemblies>
         </assemblies>
      </compilation>
   </system.web>
</configuration>

web.config après:

<configuration>
   <system.web>
      <compilation>
         <assemblies>
             <add assembly="Microsoft.ReportViewer.Common... />
             <add assembly="Microsoft.ReportViewer.WinForms... />
             <add assembly="System.DirectoryServices... />
             <add assembly="System.Windows.Forms... />
             <add assembly="ADODB... />
             <add assembly="System.Management... />
             <add assembly="System.Data.OracleClient... />
             <add assembly="Microsoft.Build.Utilities... />
             <add assembly="Microsoft.ReportViewer.ProcessingObjectModel... />
             <add assembly="System.Design... />
             <add assembly="Microsoft.Build.Framework... />
         </assemblies>
      </compilation>
   </system.web>
</configuration>

Aucun de ces assemblages n'est requis et la plupart d'entre eux n'existent pas sur les serveurs de test ou de production cibles.

Je continue à les supprimer à chaque fois que je construis, mais cela devient réel ennuyeux très rapidement.

Pour le moment, ma solution consiste à laisser web.config en lecture seule. Par conséquent, Visual Studio ne peut pas y ajouter d'assemblys.

Mettre à jour

Captures d'écran comme preuve:

Pages de propriétés du projet avant :

 texte du lien

Web.Config avant:

 alt text

Pages de propriétés de projet après:

 alt text

Web.config après:

 alt text

Mettre à jour deux

Il convient de souligner explicitement que le site Web fonctionne sans que ces références superflues soient ajoutées. Ma solution provisoire consiste à conserver web.config en lecture seule et à appuyer sur Annuler chaque fois que Visual Studio se plaint d'être en lecture seule lorsqu'il tente de le modifier. Si je peux juste empêcher Visual Studio d’essayer de le modifier en premier lieu ...

Trois mises à jour

On dirait que ce n'est pas possible. Quelqu'un peut se sentir libre de donner la bonne réponse, " Vous ne pouvez pas empêcher Visual Studio d'ajouter des assemblys à votre Web.config ." et je vais le marquer.

La seule raison pour laquelle je pose la question, c’est que nous espérons que quelqu'un connaît l'option super secrète, ou la clé de registre, ou le paramètre de projet ou de solution, pour indiquer à Visual Studio d'arrêter de penser.

Quatre mises à jour

Je n’ai pas accepté la réponse acceptée et je l’accepterais si je le pouvais. J'espère toujours la panacée. Mais pour le moment je me penche vers:

  • Réponse: impossible ( manu08 )
  • Solution de contournement: clé de registre des assemblages GAC filtrés ( Nebakanezer )

Comment puis-je empêcher Visual Studio d'ajouter des assemblys à mon web.config?

Références

Était-ce utile?

La solution

J’ai utilisé VS2005 pour éditer un fichier .net 1.1 (VS2003) .aspx et l’ai enregistré, puis le serveur Web.config aura mystérieusement le net. 2.0 assemblages ajoutés:

Si j'ai utilisé VS2008 ou VS2010, cela ne se produit pas. Je pense donc que c’est un bogue de l’EDI VS2005.

Autres conseils

Peut-être que la "bibliothèque Avatar DotNet" fait référence à ces assemblées par lui-même. Les références d'un assemblage référencé sont nécessaires pour déployer correctement un projet. Sinon, comment l’ensemble référencé pourrait-il fonctionner?

Notez qu'il est possible que votre assembly référencé n'utilise pas ses propres références, bien qu'elles existent.

Modifier: vous pouvez utiliser le formidable outil ".Net Reflector". pour vérifier cela.

J'ai eu ce problème avec Visual Studio 2005 (mais je suis heureux de signaler que la solution fonctionne pour VS 2008, voir le texte en gras ci-dessous). Il existe une section de registre vérifiée par VS avant d’ajouter des assemblys au fichier web.config.

Voici la clé:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\Projects\{E24C65DC-7377-472B-9ABA-BC803B73C61A}\FilteredGACReferences

Supposons donc que vous ne voulez pas que Visual Studio ajoute l'assembly Microsoft.VisualStudio.Designer.Interfaces à votre web.config. Ajoutez l’entrée suivante à votre base de registre et vous êtes prêt.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\Projects\{E24C65DC-7377-472B-9ABA-BC803B73C61A}\FilteredGACReferences\Microsoft.VisualStudio.Designer.Interfaces

Cela a fonctionné parfaitement pour moi. Et oui, le reste de votre équipe devra faire de même, mais au moins vous ne devez pas supprimer manuellement les entrées à chaque fois:)

Pour que cela fonctionne avec VS 2008 - il suffit de changer la 8.0 dans le chemin du registre à 9.0

Convertissez-vous " Site Web " projeter vers une " application Web " projet.

Un " Site Web " n'a pas de fichier de projet, il contient donc toutes les références d'assemblées dans le fichier web.config. Un " projet Web " a un fichier de projet et toutes les références sont stockées dans le fichier de projet.

Supprimer les références.

  • S'il s'agit d'une application Web: vous pouvez voir les références sous Explorateur de solutions .

  • S'il s'agit d'un site Web: cliquez avec le bouton droit sur le projet dans l'Explorateur de solutions, puis sélectionnez Pages de propriétés . Gérez-les ici.

HTH

Si un assembly partagé les référence, ils seront également ajoutés au projet appelant.

Comme la bibliothèque Avatar fait ces autres références, Visual Studio ajoute également ces références au projet principal. Sinon, un appel à la bibliothèque Avatar pourrait échouer car la référence dont elle a besoin est manquante.

Cela peut sembler être un hack, mais selon vos besoins, une autre option serait de charger l’assemblage Avatar de manière dynamique à l’aide de Assembly.Load ou de LoadFrom au moment de l’exécution. Ceci garderait une référence en dehors du projet principal et devrait alors empêcher les lignes de référence supplémentaires dans le fichier web.config. Cela ne serait vraiment pratique que si vous utilisiez un petit nombre de classes du projet Avatar. Je créerais un troisième projet référencé par les deux projets et contenant des interfaces mises en œuvre par une ou plusieurs classes d'Avatar afin que le projet principal conserve un typage strict lors de la gestion des instances d'Avatar. J'admets que cela pourrait être beaucoup plus de travail que les réponses soumises précédemment Si vous êtes intéressé par cette méthode, recherchez sur Google pour créer des plugins en .Net

Tant que vous utilisez un site Web plutôt qu'une application Web, je ne connais aucun moyen d'empêcher Visual Studio d'ajouter des assemblys à votre Web.config. Ce même problème se pose également pour les solutions de mon entreprise.

Vous ne pouvez pas empêcher Visual Studio d'ajouter des assemblys à votre web.config.

Désolé, vous ne pouvez pas empêcher Visual Studio d'ajouter des assemblys à votre web.config , mais tout n'est pas perdu.

J'ai déjà frappé ça par le passé; quelqu'un avait ajouté des références (y compris WinForms) à un assemblage d'accès aux données de bas niveau. Le site Web utilisait l’assemblage d’accès aux données de bas niveau et, par conséquent, WinForms, etc. était ajouté au fichier web.config.

La solution a été de déplacer son code dans le bon assemblage et de supprimer la référence incorrecte.

Si vous ne pouvez pas trier comment l’ensemble qui contient les références non désirées et si vous savez que vous n’appelez pas de code qui dépend des références non souhaitées. Ensuite, vous pouvez (aucune d’entre elles n’est agréable)

  • Écrivez une action d'installation personnalisée qui automatise la suppression de ces références d'assemblages indésirables du Web.config
  • .
  • Écrivez une action MSBUILD personnalisée à supprimer ensuite au moment de la construction
  • Utilisez un autre fichier web.config manuscrit lorsque l'application est installée.

Cela peut prendre une éternité de comprendre pourquoi Visual Studio ajoute une référence au fichier web.config. Vous devez vérifier manuellement CHAQUE assemblage utilisé directement ou indirectement par le site Web.

Je sais et j'apprécie pourquoi Microsoft a inventé les sites Web dans ASP.NET 2.0, mais parfois, ils se contentent de sucer . Si cela vous convient, convertissez votre site en un projet d’application Web et les problèmes de ce type disparaîtront.

Si cela ne vous convient pas, essayez de re-factoriser autant de code que possible dans un projet de bibliothèque de classes séparé. Toute référence que vous pouvez déplacer hors du site Web et dans la bibliothèque de classes aura pour effet de réduire les modifications web.config .

EDIT: Pour clarifier, dans un site Web, le compilateur aspnet compile tout (balise, code-behind, lot), de sorte que toutes les références d'assemblées doivent aller dans web.config . Toutefois, dans un projet d'application Web, le compilateur C # ou VB compile les fichiers code-behind dans une DLL distincte, qui est ensuite référencée par le compilateur aspnet lors de la compilation du balisage. Dans ce scénario, les assemblys référencés uniquement dans des fichiers code-behind seront insérés dans la DLL code-behind et ne toucheront pas web.config . Seuls les assemblys directement référencés dans le balisage iront dans web.config .

Je ne crois pas que vous puissiez empêcher Visual Studio d'ajouter automatiquement des références aux assemblys référencés par d'autres.

Une solution consiste à créer un projet d’installation Web avec une action personnalisée qui automatise la suppression de ces références d'assemblages indésirables du web.config .

Ce sont tous les assemblages requis par votre projet, de quelque manière que ce soit, et l’aide à la compilation réalisée par ASP.NET sur vos pages au moment de l’exécution. Ils sont probablement importés par le code que vous utilisez dans votre projet ou par une autre bibliothèque qui les utilise.

Mais selon la documentation . Ce sont les assemblys définis dans votre global web.config qui se trouve dans C: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ CONFIG :

<assemblies>
    <add assembly="mscorlib" />
    <add assembly="System, ..." />
    <add assembly="System.Configuration, ..." />
    <add assembly="System.Web, ..." />
    <add assembly="System.Data, ..." />
    <add assembly="System.Web.Services, ..." />
    <add assembly="System.Xml, ..." />
    <add assembly="System.Drawing, ..." />
    <add assembly="System.EnterpriseServices, ..." />
    <add assembly="System.Web.Mobile, ..." />
    <add assembly="*" />
</assemblies>

Si vous regardez, une référence assembly = "* *" est en cours d'ajout. Et si vous lisez la documentation à propos de cette commande, elle indique:

  

Facultativement, vous pouvez spécifier le   astérisque (*) caractère générique à ajouter   chaque assemblée au sein du privé   cache d'assemblage pour l'application,   qui se trouve soit dans le \ bin   sous-répertoire d'une application ou dans   l'installation du .NET Framework   annuaire   (% systemroot% \ Microsoft.NET \ Framework \ version).

Cela signifie que tout assemblage de votre répertoire / bin ou du répertoire d'installation de .NET Framework sera déjà inclus.

Ce qui me dit que votre problème, c’est que les assemblys en cours d’inclusion sont déjà référencés d’une certaine manière dans votre projet. Et ils proviennent probablement de la bibliothèque Avatar Dot Net ou de certains contrôles de votre page. Vérifiez les " références " dossier de votre projet Visual Studio dans la bibliothèque Avatar pour ces références non souhaitées. C’est là que le processus de construction tire ces bibliothèques.

En d'autres termes, si vous ne souhaitez pas les inclure, nettoyez vos projets référencés de toutes les références de ces bibliothèques.

Vous pouvez également utiliser un analyseur XML MSBuild pour supprimer cette section de web.config chaque fois que vous exécutez votre processus de construction. Personnellement, j'utilise une tâche appelée XmlUpdate pour modifier certaines parties de mon fichier web.config afin de le rendre prêt pour la production. Si vous souhaitez faire de même, cela fait partie des tâches de la communauté MSBuild .

Si vous utilisez une machine vista ou server 08, vous pouvez utiliser l'utilitaire de ligne de commande appcmd pour le supprimer après la reconstruction plutôt que de le supprimer manuellement.

http://technet.microsoft.com/ en-us / library / cc772200 (WS.10) .aspx http://learn.iis.net/page.aspx / 114 / démarrer-avec-appcmdexe /

voir http://msdn.microsoft.com/en-us/ bibliothèque / ms178728.aspx

il est expliqué que ce que vous voyez dans la page de propriétés n'est pas tout, les références implicites existent également dans le fichier Machine.config et sont ajoutées lors de la compilation. J'espère que cela vous aidera.

Je commencerais par cocher la case "Utiliser". les déclarations dans vos fichiers de code ainsi que toutes les références dans vos fichiers .aspx, .ascx. On dirait que vous en avez référé quelques-uns (je sais que certains sont ajoutés par défaut à partir des modèles Ajouter un nouvel élément.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top