2010-10-01 3 views
6

Je rencontre un problème avec les DLL Devart qui ne sont pas copiées dans le dossier bin de mon application Web. J'ai mon projet d'application web qui fait référence à projectA. ProjectA fait référence à projectB. Les DLL Devart sont utilisées dans le projet B et ne sont pas copiées dans le dossier bin des projets d'application Web lors d'une génération. ProjectB référence également les DLL EL Unity et celles-ci sont copiées correctement. Toutes les DLL en question sont physiquement situées dans un dossier dans le projet B et c'est là que le point de référence. (Je n'ai pas les références pointant vers le GAC)Dll ne copie pas dans le dossier bin

Les DLL qui copient correctement sont Microsoft.Practices.Unity, Microsoft.Practices.Unity.Configuration et Microsoft.Practices.ServiceLocation.

Les DLL qui ne sont pas copiées correctement sont Devart.Data, Devart.Data.Oracle et Devart.Data.Oracle.Design.

est ici les références pour chaque dll ...

<Reference Include="Devart.Data, Version=5.0.124.0, Culture=neutral, PublicKeyToken=09af7300eec23701, processorArchitecture=MSIL"> 
    <HintPath>..\Dtn.PetroDex.Dal\ThirdPartyDlls\Devart.Data.dll</HintPath> 
    <SpecificVersion>False</SpecificVersion> 
    <Private>True</Private> 
</Reference> 
<Reference Include="Devart.Data.Oracle, Version=5.70.170.0, Culture=neutral, PublicKeyToken=09af7300eec23701, processorArchitecture=MSIL"> 
    <SpecificVersion>False</SpecificVersion> 
    <HintPath>..\Dtn.PetroDex.Dal\ThirdPartyDlls\Devart.Data.Oracle.dll</HintPath> 
    <Private>True</Private> 
</Reference> 
<Reference Include="Devart.Data.Oracle.Design, Version=5.70.170.0, Culture=neutral, PublicKeyToken=09af7300eec23701, processorArchitecture=MSIL"> 
    <SpecificVersion>False</SpecificVersion> 
    <HintPath>..\Dtn.PetroDex.Dal\ThirdPartyDlls\Devart.Data.Oracle.Design.dll</HintPath> 
    <Private>True</Private> 
</Reference> 
<Reference Include="Microsoft.Practices.ServiceLocation, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL"> 
    <HintPath>..\Dtn.PetroDex.Dal\ThirdPartyDlls\Microsoft.Practices.ServiceLocation.dll</HintPath> 
    <SpecificVersion>False</SpecificVersion> 
    <Private>True</Private> 
</Reference> 
<Reference Include="Microsoft.Practices.Unity, Version=2.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL"> 
    <HintPath>..\Dtn.PetroDex.Dal\ThirdPartyDlls\Microsoft.Practices.Unity.dll</HintPath> 
    <SpecificVersion>False</SpecificVersion> 
    <Private>True</Private> 
</Reference> 
<Reference Include="Microsoft.Practices.Unity.Configuration, Version=2.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL"> 
    <HintPath>..\Dtn.PetroDex.Dal\ThirdPartyDlls\Microsoft.Practices.Unity.Configuration.dll</HintPath> 
    <SpecificVersion>False</SpecificVersion> 
    <Private>True</Private> 
</Reference> 

Toute autre personne ayant ce problème? Est-ce que je fais cela mal? Merci

EDIT J'ai ouvert un moniteur de fichiers et regardé où Visual Studio chargeait la référence et pour Unity il obtenait les DLL à partir de l'emplacement que j'ai spécifié. Mais, pour les dlls Devart, ça regarde dans le GAC! Est-ce que les dll Devart pourraient causer ça? Cliquez avec le bouton droit de la souris sur les dll référencées et vérifiez si la copie locale est vraie.

Répondre

8
  1. vous pouvez également essayer de lire vos références une fois, cela avait résolu un problème similaire pour moi quand j'avais converti un projet VS2005 au projet VS2008.
+0

J'ai une copie locale égale à true. J'ai rajouté les références Devart plus d'une fois ... fais-moi confiance. Il semble que ce soit seulement les dll Devart. Pourraient-ils avoir un problème qui cause cela? –

+0

Je ne peux pas penser à autre chose, vous pourriez probablement essayer de copier des thèses pendant la construction de poste ou en renvoyant les dlls directement du projectA –

+0

aussi si vous avez les dlls de devart dans GAC essayez de les enlever et de reconstruire vos projets –

0

Si ces DLL se trouvent dans un sous-répertoire du projet B, assurez-vous que la propriété "Copie locale" pour chaque référence est définie sur true. En outre, si les fichiers DLL sont inclus en tant que fichiers dans votre projet, vérifiez les propriétés du studio visuel pour les fichiers eux-mêmes. L'action de construction doit être définie sur "Aucun" et le "Copier dans le répertoire de sortie" doit être réglé sur "Ne pas copier". EDIT: Il suffit de les avoir comme références avec copy local = true qui s'occupera de la copie. Si ces paramètres sont différents pour les différents DLL, cela peut expliquer pourquoi certains sont copiés dans le dossier bin et d'autres ne le sont pas.

11

J'ai eu un problème similaire avec les références externes. Le problème est que les bibliothèques inutilisées ne sont pas copiées. Utilisez-vous les bibliothèques Devart de votre projetB? N'importe quelle instance, héritage, n'importe quoi, ... ?? Veuillez essayer ceci: Installez une classe fictive des trois bibliothèques de votre projetB et recompilez. Cela a fonctionné pour moi. J'aimerais avoir l'explication formelle.

1

Définir comme copie locale ne fonctionne pas pour moi. La seule chose qui résout (est inutilisable) est de référencer un type contenu dans l'assembly.

3

Le problème apparaît également lorsque des DLL sont des dépendances d'autres personnes. Par exemple, Microsoft.ApplicationServer.Caching.AzureClientHelper.dll est utilisé en interne par Microsoft.ApplicationServer.Caching.Client. Même si j'ai copyLocal = True l'assembly d'assistance n'est pas copié car il n'est référencé nulle part directement dans mon code.Pour éviter ce problème, vous pouvez créer une variable de type privé comme ceci:

Type dependsOnThisTypeOfAssembly = typeof (TypeFromDependentAssembly); Cela fera une référence au type et l'assemblage sera copié localement pendant le processus de construction.

Questions connexes