对于如何为多目标设置视觉工作室版本，我有些困惑。

背景：c.NET v2.0，带有p /调用带有安装程序项目的第三方32位DLL，SQL compact v3.5 SP1.
现在，平台目标已设置为x86，因此可以在Windows x64上运行。

这家第三方公司刚刚发布了其DLL的64位版本，我想构建一个专用的64位程序。

这就提出了一些我还没有答案的问题。
我想要完全相同的代码库。
我必须使用对32位DLL或者64位DLL的引用进行构建。
(第3方和SQL Server Compact)

可以使用2套新的配置集(Debug64和Release64)解决此问题吗？

我必须创建2个单独的安装项目(std。visual studio项目，没有Wix或者任何其他实用程序)，还是可以在同一.msi中解决此问题？

任何想法和/或者建议都将受到欢迎。

解决方案

不确定问题的总答案，但我想我会在SQL Compact 3.5 SP1下载页面的"其他信息"部分中指出一条评论，看到我们正在使用x64希望对我们有所帮助。

Due to changes in SQL Server Compact
  SP1 and additional 64-bit version
  support, centrally installed and mixed
  mode environments of 32-bit version of
  SQL Server Compact 3.5 and 64-bit
  version of SQL Server Compact 3.5 SP1
  can create what appear to be
  intermittent problems. To minimize the
  potential for conflicts, and to enable
  platform neutral deployment of managed
  client applications, centrally
  installing the 64-bit version of SQL
  Server Compact 3.5 SP1 using the
  Windows Installer (MSI) file also
  requires installing the 32-bit version
  of SQL Server Compact 3.5 SP1 MSI
  file. For applications that only
  require native 64-bit, private
  deployment of the 64-bit version of
  SQL Server Compact 3.5 SP1 can be
  utilized.

如果分发64位客户端，我将其读为"包括32位SQLCE文件和64位文件"。

我想让生活变得有趣。.必须说，我喜欢"似乎是间歇性问题"这一行……​​听起来有点像"我们在想象事物，但以防万一，做到这一点……"

关于最后一个问题。我们很可能无法在单个MSI中解决此问题。
如果使用注册表/系统文件夹或者任何相关文件，则MSI本身必须知道这一点，并且必须准备64位MSI才能正确安装在32位计算机上。

我们有可能使产品作为32 it应用程序安装，并且仍然能够使其以64位版本运行，但是我认为这可能很难实现。

话虽这么说，我认为我们应该能够为所有内容保留单个代码库。在我目前的工作地点，我们设法做到了。 (但确实需要花些时间才能使所有内容一起播放)

希望这可以帮助。
这里是一些与32/64位问题相关的信息的链接：
http://blog.typemock.com/2008/07/registry-on-windows-64-bit-double-your.html

是的，我们可以在同一项目中使用相同的代码库同时针对x86和x64. 通常，如果我们在VS.NET中创建正确的解决方案配置，那么一切就将正常进行(尽管P / Invoke到完全不受管理的DLL很可能需要一些条件代码)：我发现需要特别注意的项目是：

• 引用具有相同名称但具有特定位数的外部托管程序集(这也适用于COM互操作程序集)
• MSI程序包(如前所述，它需要以x86或者x64为目标)
• MSI程序包中任何基于自定义.NET Installer类的操作

程序集引用问题不能完全在VS.NET中解决，因为它仅允许我们一次将具有给定名称的引用添加到项目中。若要解决此问题，请手动编辑项目文件(在VS中，在解决方案资源管理器中右键单击项目文件，选择"卸载项目"，然后再次右键单击并选择"编辑")。在添加对某个程序集的x86版本的引用之后，项目文件将包含以下内容：

<Reference Include="Filename, ..., processorArchitecture=x86">
  <HintPath>C:\path\to\x86\DLL</HintPath>
</Reference>

将该Reference标记包装在ItemGroup标记内，指示其适用的解决方案配置，例如：

<ItemGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">
   <Reference ...>....</Reference>
</ItemGroup>

然后，复制并粘贴整个ItemGroup标记，然后对其进行编辑以包含64位DLL的详细信息，例如：

<ItemGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x64' ">
  <Reference Include="Filename, ..., processorArchitecture=AMD64">
     <HintPath>C:\path\to\x64\DLL</HintPath>
   </Reference>
</ItemGroup>

在VS.NET中重新加载项目后，"程序集引用"对话框将对这些更改感到有些困惑，并且我们可能会遇到有关目标处理器使用错误的程序集的一些警告，但是所有构建都可以正常工作。

接下来要解决MSI问题，不幸的是，这将需要非VS.NET工具：我更喜欢Caphyon的Advanced Installer，因为它可以实现所涉及的基本技巧(创建通用的MSI以及32位和特定于64位的MSI，并使用.EXE安装程序启动器提取正确的版本并在运行时进行所需的修复)。

我们可能可以使用其他工具或者Windows Installer XML(WiX)工具集来达到相同的结果，但是Advanced Installer使事情变得如此简单(而且价格合理)，我从未真正考虑过替代方案。

即使使用Advanced Installer，我们可能仍然需要WiX的一件事是.NET Installer类的自定义操作。尽管指定仅在某些平台上运行的某些操作很简单(分别使用VersionNT64和NOT VersionNT64执行条件)，但是内置的AI自定义操作也将使用32位框架(即使在64位计算机上)执行。

可能会在将来的版本中修复此问题，但现在(或者使用其他工具创建存在相同问题的MSI时)，可以使用WiX 3.0的托管自定义操作支持来创建具有适当位数的操作DLL。将使用相应的框架执行。

编辑：从版本8.1.2开始，高级安装程序正确支持64位自定义操作。自从我最初的回答以来，不幸的是，它的价格已经上涨了很多，尽管与InstallShield及其同类产品相比仍具有很高的价值...

编辑：如果DLL是在GAC中注册的，我们还可以通过这种方式使用标准参考标记(以SQLite为例)：

<ItemGroup Condition="'$(Platform)' == 'x86'">
    <Reference Include="System.Data.SQLite, Version=1.0.80.0, Culture=neutral, PublicKeyToken=db937bc2d44ff139, processorArchitecture=x86" />
</ItemGroup>
<ItemGroup Condition="'$(Platform)' == 'x64'">
    <Reference Include="System.Data.SQLite, Version=1.0.80.0, Culture=neutral, PublicKeyToken=db937bc2d44ff139, processorArchitecture=AMD64" />
</ItemGroup>

该条件也减少到所有构建类型(发行或者调试)，仅指定处理器体系结构。

假设我们已经为两个平台构建了DLL，并且它们位于以下位置：

C:\whatever\x86\whatever.dll
C:\whatever\x64\whatever.dll

我们只需要从此编辑.csproj文件：

<HintPath>C:\whatever\x86\whatever.dll</HintPath>

对此：

<HintPath>C:\whatever$(Platform)\whatever.dll</HintPath>

然后，我们应该能够针对两个平台构建项目，并且MSBuild将在所选平台的正确目录中查找。

如果我们将以.NET编写的自定义操作用作MSI安装程序的一部分，那么我们将遇到另一个问题。

运行这些自定义操作的"填充程序"始终为32位，然后，尽管我们指定了什么目标，自定义操作也将运行32位。

更多信息和一些忍者移动来解决(基本上将MSI更改为使用此Shim的64位版本)

在Visual Studio 2005/2008中构建MSI以在SharePoint 64上工作

使用Visual Studio的64位托管自定义操作