views:

691

answers:

2

Currently our .net code is not processor specific, but it depends on libraries (Oracle/ODP.Net) which are. We've found a solution where we edit the csproj file directly, and put the references in to item groups with a Condition clause based on our selected build configuration. We have 32 bit debug/release and 64bit debug/release, and the correct assemblies are references when you build that config.

This works more or less at build time, but it causes all kinds of wackiness in Visual Studio (2008). The end result is that the same assembly shows up four times under references, and three have the yellow exclamation mark. It also generates some 76 warnings that I can't get rid of. We try to aim for 0 warnings because we want to know when new ones show up so this is a bit of a problem.

Is anybody aware of a solution to conditional references that allow it to look like a single reference (which it really is) and doesn't fill up my warnings at build time?

+1  A: 

The only thing that leaps to mind is having 4 separate project files... but before you panic about having to maintain 4 files when ever you add a class, you can use another csproj trick here:

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

which (IIRC) says "include all cs files at any level in the folder structure".

Marc Gravell
+1  A: 

We found an answer that was a bit different than what we were looking for, but I kindof like it. If you add this to your config file under runtime->AssemblyBinding

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

Then the 64bit and 32bit versions work with the same build. All we have to do is not copy Oracle.DataAccess.dll locally when we deploy and let it pull it from the GAC.

Thanks!