2009-05-12 12 views
6

Actuellement, notre code .net n'est pas spécifique au processeur, mais dépend des bibliothèques (Oracle/ODP.Net) qui le sont. Nous avons trouvé une solution où nous éditons le fichier csproj directement, et mettons les références dans les groupes d'items avec une clause Condition basée sur notre configuration de construction sélectionnée. Nous avons un débogage/une libération de 32 bits et un débogage/une libération de 64 bits, et les assemblys corrects sont des références lorsque vous construisez cette configuration.Références conditionnelles

Cela fonctionne plus ou moins au moment de la construction, mais il provoque toutes sortes de folie dans Visual Studio (2008). Le résultat final est que le même assemblage apparaît quatre fois sous les références, et trois ont le point d'exclamation jaune. Il génère également 76 avertissements dont je ne peux pas me débarrasser. Nous essayons de viser 0 avertissements parce que nous voulons savoir quand de nouveaux avertissements apparaissent, donc c'est un peu un problème.

Est-ce que quelqu'un est au courant d'une solution aux références conditionnelles qui lui permettent de ressembler à une référence unique (ce qu'elle est vraiment) et ne remplit pas mes avertissements au moment de la construction?

Répondre

1

La seule chose qui saute à l'esprit est d'avoir 4 fichiers de projets séparés ... mais avant de paniquer d'avoir à maintenir 4 fichiers chaque fois que vous ajoutez une classe, vous pouvez utiliser une autre astuce csproj ici:

<Compile Include="**\*.cs" /> 

qui (IIRC) dit "inclure tous les fichiers cs à n'importe quel niveau dans la structure du dossier".

1

Nous avons trouvé une réponse qui était un peu différente de ce que nous cherchions, mais je l'aime bien. Si vous ajoutez ceci à votre fichier de configuration sous runtime-> assemblyBinding

 
<dependentAssembly> 
<assemblyIdentity name="Oracle.DataAccess" publicKeyToken="89b483f429c47342" /> 
<bindingRedirect oldVersion="2.111.6.20" newVersion="2.111.6.0" /> 
</dependentAssembly> 

Ensuite, les versions 64 bits et 32 ​​bits fonctionnent avec la même construction. Tout ce que nous avons à faire est pas copier Oracle.DataAccess.dll localement lorsque nous déployons et laissez-le tirer du GAC.

Merci!