11
votes

DLL de référence dans ASP.NET sans \ bin ou GAC

J'ai un projet ASP.NET sous contrôle source (subversion). Pour diverses raisons, je ne veux pas ajouter le répertoire \ bin ou son contenu au contrôle de la source, je l'ai donc SVN: ignoré. Les DLL sont chargées ici lors d'une version Visual Studio, et je peux commencer par un répertoire propre et / ou supprimer tout le contenu de ce répertoire et avoir toujours une construction réussie.

Il y a deux façons que je référent le code d'inclusion dans le projet:

  1. dans l'élément web.config //configuration/configsections/conem.web/compilation/Assemblages. Je peux toute DLL qui est dans le GAC de cette façon. Je fais cela pour toutes les DLL système.
  2. Dans la solution VS, il y a un paramètre à Projet / Projection / ProjecteReferences qui me permet de préciser les références incluses à d'autres projets de la solution.

    (Notez que ceci est différent des projets non-Web, où toutes les références aux dépendances externes sont stockés dans le fichier de projet. Il n'y a pas de fichier de projet pour les projets Web vs afin qu'ils doivent être stockés quelque part sinon.)

    Maintenant, j'ai une DLL compilée de 3ème partie que j'aimerais inclure dans le projet. Malheureusement, aucune des options de référence que j'ai trouvées ne semble fonctionner pour moi:

    1. Référencement via web.config / system.web / compilation / assemblages ne fonctionne pas à moins que la DLL n'existe pas dans le GAC; Vous ne pouvez pas utiliser de chemin de fichier. J'aimerais vraiment éviter une dépendance du GAC car cela signifiera une étape supplémentaire pour que le projet fonctionne sur chaque machine cible.
    2. Je n'ai pas trouvé de moyen d'inclure une référence de fichier dans la solution comme je peux faire avec des références de projet.
    3. Chaque fois que j'ajoute une référence de fichier en utilisant la boîte de dialogue "Ajouter une référence" de VS, il copie simplement la DLL vers le répertoire \ bin. Cela ne fonctionnera pas pour moi car My \ Bin Directory n'est pas persistant à travers les systèmes.

      Y a-t-il une autre manière que je peux faire une référence à un fichier DLL et qu'il doit rester en bâton?


0 commentaires

5 Réponses :


0
votes

Le seul moyen que j'ai pensé à Jusqu'à présent est d'avoir mon script de construction nant Copier la DLL à partir d'un répertoire extérieur extérieur (versionné) dans le répertoire \ bin avant la construction. Je n'aime pas beaucoup cela, car il introduit une dépendance de processus en dehors de Visual Studio: les développeurs doivent s'assurer que la bibliothèque est copiée avant d'essayer de construire à l'intérieur de VS.


0 commentaires

2
votes

Techniquement, à l'étape 3 un peu plus se passe. Visual Studio copie la DLL vers votre annuaire \ bin et ajoute un fichier nom.dll.refresh contenant le chemin d'accès à la DLL d'origine. Avec SourceSafe, le fichier .refresh est sous contrôle de version, de sorte que lorsque vous configurez un nouveau système et obtenir le dernier code de SourceSafe, Visual Studio peut trouver et copier la DLL de l'emplacement spécifié. Vous devriez être capable de mettre le fichier .refresh dans svn et de faire tout ce qui fonctionne.

En outre, je crée généralement un répertoire \ commun au-dessus de mon répertoire de projet, qui est là où je mets les DLL et j'inclus ce répertoire dans la solution (et le contrôle de source), de sorte que chaque version de mon projet dans le contrôle de la source ait les bonnes dlls.


3 commentaires

Je me suis demandé à ce sujet. Cependant, pour obtenir .refresh dans svn, je dois avoir \ bin, et si j'ai \ bin, je pourrais aussi bien simplement copier la DLL de toute façon.


Corrigez-moi si je me trompe, mais même avec \ commun dans la solution, vous devez toujours copier manuellement la DLL et / ou .refresh dans \ bin, non?


Le .refresh est créé automatiquement lorsque vous ajoutez une DLL via "Ajouter une référence". Tant que vous le mettez en contrôle de la source et que vous avez la DLL au même endroit sur toutes les machines, tout fonctionne. Autres machines Téléchargez le fichier .refresh à partir du contrôle de la source et pendant une version, copiez la DLL de l'emplacement spécifié. L'avantage de la mise en place de la commande de source au lieu de la DLL est que le fichier .reFresh n'est pas touché pendant une construction. La DLL est, ce qui entraîne une vérification inutile chaque fois que vous construisez.



0
votes

Je sauvegarder des assemblées 3ème partie sans code source dans le contrôle de la source. Dans leur propre répertoire en dehors du projet - `c: \ Projects \ 3RDPartyAssemblies 'de cette façon, de cette façon, tous les projets / développeurs qui ont besoin d'eux peuvent les faire référence.


4 commentaires

Mais comment obtenez-vous la référence à la DLL à coller au projet? C'est le creux de ma question.


Désolé je ne suis pas sûr si je vous comprends. Vous pouvez inclure une référence de fichier de la même manière qu'une référence de projet en choisissant l'onglet Parcourir. Il le copie sur le répertoire bin mais maintient toujours la référence.


En fait, dans mes tests, il ne contient pas la référence en dehors de la présence du fichier dans le répertoire \ bin. Si vous fermez la solution et supprimez la DLL / .refresh, alors lorsque vous rouvrez la solution, la référence sera sortie de la boîte de dialogue. Contrairement à des références de projet ou de GAC, les références de fichiers sont maintenues uniquement par la présence du fichier dans \ bin - à moins d'une autre façon de le faire, ce qui est ce que je demande.


Je vois. Est-ce un projet d'application Web ASP.NET, ou juste un site Web simple ASP.NET? Parce que j'ai créé un nouveau projet d'application Web, a ajouté une référence à une DLL externe, utilisée la DLL dans le code, construite, supprimé le bin Dir, couru à nouveau et tout a fonctionné.



0
votes

Les références de projet sont stockées dans le fichier .csproj ou .vbproj qui devrait être sous contrôle source. Le fichier .Refresh est totalement non pertinent et n'est qu'un fichier d'assistance pour le studio. Si vous créez un répertoire local sur le projet ou la solution et stockez toutes les références compilées, non déjà dans le GAC dans ce répertoire, vous pouvez ensuite ajouter ce répertoire au contrôle de la source et à la référence directement à partir de là. De cette façon, tous les développeurs sont garantis pour avoir la copie la plus récente (à partir du contrôle de la source) du .dll lorsqu'ils effectuent leur prochaine compilation et il n'aura jamais d'impact sur le / bin.

Obtenir vos développeurs à "Obtenir la dernière version" ... Vous êtes seul pour celui-là. Je ne l'ai toujours pas compris.

Peut-être un autre mémo.


2 commentaires

Les sites Web n'ont pas de .csproj ou .vbproj, d'où l'utilisation du fichier .refresh.


Vous êtes correct, monsieur. Je me suis mal exprimé. Les références pour un projet de site Web sont réellement conservées sous la clé ProjecteurReferences dans le fichier .SLN (dont le site Web doit avoir besoin mais ne peut pas). Woops.



5
votes

Si vous faites une sorte de développement sérieux, je vous recommanderais de migrer à l'écart du projet de site Web et d'un projet Web, car cela vous permet de gérer ce type de dépendances de la même manière dans toute votre solution.

Cependant, en supposant que vous ne puissiez pas faire cela, placez toutes les assemblées que vous devez faire référence à partir du projet Web dans un dossier quelque part (par exemple, lib \ Web) et ajoutez un événement de pré-construction à votre projet Web qui copie le contenu. de ce dossier dans le dossier bin du répertoire Web. Maintenant, chaque fois que vous souhaitez ajouter une dépendance à votre projet Web, vous pouvez le déposer dans le dossier LIB \ Web et ajouter la référence. Chaque fois que vous construisez, tous les assemblages référencés seront copiés dans le dossier afin que vous puissiez supprimer le dossier bin ou faire une commande propre et ne pas avoir de problème.


1 commentaires

La solution que vous fournissez ne fonctionne pas: nous ne pouvons pas ajouter un événement de pré-construit à un site Web.