在同一个解决方案/项目中，用Visual Studio瞄准32位和64位

I have a little dilemma on how to set up my visual studio builds for multi-targeting.

我在如何设置我的visual studio构建以实现多目标的问题上遇到了一些困难。

Background: c# .NET v2.0 with p/invoking into 3rd party 32 bit DLL's, SQL compact v3.5 SP1, with a Setup project. Right now, the platform target is set to x86 so it can be run on Windows x64.

背景:c# . net v2.0与p/调用到第三方32位DLL的，SQL compact v3.5 SP1，与一个安装项目。目前，平台目标被设置为x86，因此可以在Windows x64上运行。

The 3rd party company has just released 64 bit versions of their DLL's and I want to build a dedicated 64bit program.

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

This raises some questions which I haven't got the answers to yet. I want to have the exact same code base. I must build with references to either the 32bit set of DLL's or 64bit DLL's. (Both 3rd party and SQL Server Compact)

这就引出了一些我还没有答案的问题。我想要相同的代码库。我必须构建引用到32位的DLL或64位DLL的集合。(第三方和SQL Server Compact)

Can this be solved with 2 new sets of configurations (Debug64 and Release64) ?

可以用2组新的配置(Debug64和Release64)解决这个问题吗?

Must I create 2 separate setup projects(std. visual studio projects, no Wix or any other utility), or can this be solved within the same .msi?

我必须创建两个独立的安装项目(std)。visual studio项目，没有Wix或任何其他实用程序)，或者可以在相同的.msi中解决这个问题吗?

Any ideas and/or recommendations would be welcomed.

欢迎提出任何意见和/或建议。

7 个解决方案

#1

Yes, you can target both x86 and x64 with the same code base in the same project. In general, things will Just Work if you create the right solution configurations in VS.NET (although P/Invoke to entirely unmanaged DLLs will most likely require some conditional code): the items that I found to require special attention are:

是的，您可以在相同的项目中以相同的代码基础来针对x86和x64。一般来说，如果您在VS.NET中创建了正确的解决方案配置，事情就会正常工作(尽管P/Invoke to完全不受管理的dll):我发现需要特别注意的项目是:

• References to outside managed assemblies with the same name but their own specific bitness (this also applies to COM interop assemblies)
• 对具有相同名称但其特定位的外部托管程序集的引用(这也适用于COM interop程序集)
• The MSI package (which, as has already been noted, will need to target either x86 or x64)
• MSI包(如前所述，它需要针对x86或x64)
• Any custom .NET Installer Class-based actions in your MSI package
• MSI包中的任何自定义。net安装程序类操作

The assembly reference issue can't be solved entirely within VS.NET, as it will only allow you to add a reference with a given name to a project once. To work around this, edit your project file manually (in VS, right-click your project file in the Solution Explorer, select Unload Project, then right-click again and select Edit). After adding a reference to, say, the x86 version of an assembly, your project file will contain something like:

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

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

Wrap that Reference tag inside an ItemGroup tag indicating the solution configuration it applies to, e.g:

将引用标记封装到一个ItemGroup标记中，该标记指示它应用于的解决方案配置，例如:

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

Then, copy and paste the entire ItemGroup tag, and edit it to contain the details of your 64-bit DLL, e.g.:

然后，复制并粘贴整个ItemGroup标记，并将其编辑为包含64位DLL的详细信息，例如:

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

After reloading your project in VS.NET, the Assembly Reference dialog will be a bit confused by these changes, and you may encounter some warnings about assemblies with the wrong target processor, but all your builds will work just fine.

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

Solving the MSI issue is up next, and unfortunately this will require a non-VS.NET tool: I prefer Caphyon's Advanced Installer for that purpose, as it pulls off the basic trick involved (create a common MSI, as well as 32-bit and 64-bit specific MSIs, and use an .EXE setup launcher to extract the right version and do the required fixups at runtime) very, very well.

接下来要解决MSI问题，不幸的是这需要一个非vs。净工具:我更喜欢Caphyon先进的安装程序的目的,因为它脱下所涉及的基本技巧(创建一个共同的MSI,以及32位和64位具体的MSI,exe安装发射器来提取和使用正确的版本和在运行时所需的修正)非常、非常好。

You can probably achieve the same results using other tools or the Windows Installer XML (WiX) toolset, but Advanced Installer makes things so easy (and is quite affordable at that) that I've never really looked at alternatives.

您可能可以使用其他工具或Windows安装程序XML (WiX)工具集获得相同的结果，但是高级安装程序使事情变得如此简单(并且在这一点上是相当便宜的)，以至于我从未真正考虑过替代方法。

One thing you may still require WiX for though, even when using Advanced Installer, is for your .NET Installer Class custom actions. Although it's trivial to specify certain actions that should only run on certain platforms (using the VersionNT64 and NOT VersionNT64 execution conditions, respectively), the built-in AI custom actions will be executed using the 32-bit Framework, even on 64-bit machines.

尽管如此，您可能仍然需要WiX，即使使用高级安装程序，它是用于. net安装程序类自定义操作的。虽然指定只应该在某些平台上运行的某些操作(分别使用VersionNT64而不是VersionNT64执行条件)很容易，但是内置的AI自定义操作将使用32位框架执行，甚至在64位机器上也是如此。

This may be fixed in a future release, but for now (or when using a different tool to create your MSIs that has the same issue), you can use WiX 3.0's managed custom action support to create action DLLs with the proper bitness that will be executed using the corresponding Framework.

这可能在将来的版本中是固定的,但现在(或当你使用不同的工具来创建msi,同样的问题),您可以使用WiX 3.0的管理自定义动作支持创建行动dll与适当的位数,将使用相应的执行框架。

---

Edit: as of version 8.1.2, Advanced Installer correctly supports 64-bit custom actions. Since my original answer, its price has increased quite a bit, unfortunately, even though it's still extremely good value when compared to InstallShield and its ilk...

编辑:从8.1.2版本开始，高级安装程序正确地支持64位自定义操作。不幸的是，从我最初的答案开始，它的价格上涨了不少，尽管与InstallShield及其同类产品相比，它的价值仍然非常高……

---

Edit: If your DLLs are registered in the GAC, you can also use the standard reference tags this way (SQLite as an example):

编辑:如果您的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>

The condition is also reduced down to all build types, release or debug, and just specifies the processor architecture.

该条件还被简化为所有构建类型、发布或调试，并仅指定处理器体系结构。

#2

Let's say you have the DLLs build for both platforms, and they are in the following location:

假设您有两个平台的dll，它们位于以下位置:

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

You simply need to edit your .csproj file from this:

你只需要编辑你的。csproj文件从这里:

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

To this:

:

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

You should then be able to build your project targeting both platforms, and MSBuild will look in the correct directory for the chosen platform.

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

#3

Not sure of the total answer to your question - but thought I would point out a comment in the Additional Information section of the SQL Compact 3.5 SP1 download page seeing you are looking at x64 - hope it helps.

我不确定您的问题的全部答案——但是我想我应该在SQL Compact 3.5 SP1下载页面的附加信息部分指出一条注释——希望它能有所帮助。

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.

由于SQL Server Compact SP1的更改和额外的64位版本支持，SQL Server Compact 3.5的32位版本和SQL Server Compact 3.5的64位版本Compact SP1的64位版本的集中安装和混合模式环境可能会产生一些断断续续的问题。为了最小化冲突的可能性，并支持与平台无关的托管客户端应用程序部署，使用Windows Installer (MSI)文件集中安装64位的SQL Server Compact 3.5 SP1文件，还需要安装32位的SQL Server Compact 3.5 SP1 MSI文件。对于只需要本地64位的应用程序，可以使用64位版本的SQL Server Compact 3.5 SP1的私有部署。

I read this as "include the 32bit SQLCE files as well as the 64bit files" if distributing for 64bit clients.

如果分发给64位客户端，我将把它读为“包含32位SQLCE文件和64位文件”。

Makes life interesting I guess.. must say that I love the "what appears to be intermittent problems" line... sounds a bit like "you are imagining things, but just in case, do this..."

让生活变得有趣。必须说我喜欢“似乎是间歇性问题”这条线……听起来有点像“你在想象事情，但只是为了以防万一，做这个……”

#4

Regarding your last question. Most likely you cant solve this inside a single MSI. If you are using registry/system folders or anything related, the MSI itself must be aware of this and you must prepare a 64bit MSI to properly install on 32 bit machine.

关于你的最后一个问题。很可能你无法在一个MSI中解决这个问题。如果您正在使用注册表/系统文件夹或任何相关的东西，MSI本身必须意识到这一点，并且您必须准备一个64位MSI来正确地安装在32位机器上。

There is a possibility that you can make you product installed as a 32 it application and still be able to make it run as 64 bit one, but i think that may be somewhat hard to achieve.

有一种可能性是，您可以将产品安装为32 it应用程序，但仍然能够使其运行为64位1，但我认为这可能有点难以实现。

that being said i think you should be able to keep a single code base for everything. In my current work place we have managed to do so. (but it did took some juggling to make everything play together)

话虽如此，我认为您应该能够为所有事情保留一个单一的代码库。在我目前工作的地方，我们已经做到了。(但要让所有东西都在一起玩，确实需要玩些杂耍)

Hope this helps. Heres a link to some info related to 32/64 bit issues: http://blog.typemock.com/2008/07/registry-on-windows-64-bit-double-your.html

希望这个有帮助。这里有一个关于32/64位问题的信息链接:http://blog.typemock.com/2008/07/registry-on-windows-64位-double-your.html

#5

If you use Custom Actions written in .NET as part of your MSI installer then you have another problem.

如果您在。net中使用自定义操作作为MSI安装程序的一部分，那么您就会遇到另一个问题。

The 'shim' that runs these custom actions is always 32bit then your custom action will run 32bit as well, despite what target you specify.

运行这些自定义操作的“shim”总是32位，那么您的自定义操作也将运行32位，不管您指定的目标是什么。

More info & some ninja moves to get around (basically change the MSI to use the 64 bit version of this shim)

更多的信息&一些忍者的行动(基本上改变MSI使用64位版本的shim)

Building an MSI in Visual Studio 2005/2008 to work on a SharePoint 64

在Visual Studio 2005/2008中构建一个MSI来处理SharePoint 64

64-bit Managed Custom Actions with Visual Studio

64位管理自定义操作与Visual Studio。

#6

You can generate two solutions differently and merge them afterwards! I did this for VS 2010. and it works. I had 2 different solutions generated by CMake and I merged them

您可以生成两个不同的解决方案，然后合并它们!我为VS 2010做了这个。和它的工作原理。我有两个不同的解决方案由CMake生成，我合并了它们

#7

You can use a condition to an ItemGroup for the dll references in the project file.
This will cause visual studio to recheck the condition and references whenever you change the active configuration.
Just add a condition for each configuration.

您可以为项目文件中的dll引用使用ItemGroup的条件。这将导致visual studio在更改活动配置时重新检查条件和引用。只需为每个配置添加一个条件。

Example:

例子:

 <ItemGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x86' ">
    <Reference Include="DLLName">
      <HintPath>..\DLLName.dll</HintPath>
    </Reference>
    <ProjectReference Include="..\MyOtherProject.vcxproj">
      <Project>{AAAAAA-000000-BBBB-CCCC-TTTTTTTTTT}</Project>
      <Name>MyOtherProject</Name>
    </ProjectReference>
  </ItemGroup>