我在如何设置Visual Studio多目标构建方面遇到了一些困境。
背景: 使用c# .NET v2.0，使用第三方32位DLL的P/Invoke，SQL Compact v3.5 SP1和一个设置项目。 现在，平台目标设置为x86，以便在Windows x64上运行。
第三方公司刚刚发布了64位版本的它们的DLL，我想构建一个专用的64位程序。
这引起了一些问题，我还没有找到答案。 我希望有完全相同的代码库。 我必须使用对32位DLL或64位DLL的引用进行构建。 （都是第三方的和SQL Server Compact）
可以通过创建两个新的配置集（Debug64和Release64）来解决吗？
我必须创建2个单独的设置项目（标准的Visual Studio项目，没有Wix或任何其他工具），还是可以在同一个.msi中解决？
欢迎任何想法和/或建议。
是的，您可以在同一项目中使用相同的代码库针对x86和x64进行目标设置。通常情况下，在VS.NET中创建正确的解决方案配置即可实现自动适配（尽管对于完全非托管的DLL的P/Invoke可能需要一些条件代码）：我发现需要特别注意的项目包括：
程序集引用问题无法完全在VS.NET中解决，因为它只允许您向项目添加给定名称的引用一次。要解决此问题，请手动编辑您的项目文件（在VS中，右键单击解决方案资源管理器中的项目文件，选择卸载项目，然后再次右键单击并选择编辑）。添加对x86版本程序集的引用后，您的项目文件将包含以下内容：
<Reference Include="Filename, ..., processorArchitecture=x86">
<HintPath>C:\path\to\x86\DLL</HintPath>
</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>
编辑：如果您的DLL已在全局程序集缓存中注册，您也可以使用标准的引用标记来实现此目的（以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>
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将在所选择的平台的正确目录中查找。
<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>
使用x86/x64依赖项构建一个.Net应用程序
虽然其他答案提供了根据平台制作不同的构建解决方案，但我为您提供了一种只需使用“AnyCPU”配置就可以制作适用于x86和x64 dll的构建的选项。
您需要编写一些连接代码来实现这一点。
在运行时正确解析x86/x64-dlls的方法
步骤：
<ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>None</ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>
Add this postbuild script to your startup project, use and modify the paths of this script sp that it copies all your x86/x64 dlls in corresponding subfolders of your build bin\x86\ bin\x64\
xcopy /E /H /R /Y /I /D $(SolutionDir)\YourPathToX86Dlls $(TargetDir)\x86
xcopy /E /H /R /Y /I /D $(SolutionDir)\YourPathToX64Dlls $(TargetDir)\x64
--> When you would start application now, you get an exception that the assembly could not be found.
Register the AssemblyResolve event right at the beginning of your application entry point
AppDomain.CurrentDomain.AssemblyResolve += TryResolveArchitectureDependency;
withthis method:
/// <summary>
/// Event Handler for AppDomain.CurrentDomain.AssemblyResolve
/// </summary>
/// <param name="sender">The app domain</param>
/// <param name="resolveEventArgs">The resolve event args</param>
/// <returns>The architecture dependent assembly</returns>
public static Assembly TryResolveArchitectureDependency(object sender, ResolveEventArgs resolveEventArgs)
{
var dllName = resolveEventArgs.Name.Substring(0, resolveEventArgs.Name.IndexOf(","));
var anyCpuAssemblyPath = $".\\{dllName}.dll";
var architectureName = System.Environment.Is64BitProcess ? "x64" : "x86";
var assemblyPath = $".\\{architectureName}\\{dllName}.dll";
if (File.Exists(assemblyPath))
{
return Assembly.LoadFrom(assemblyPath);
}
return null;
}
优点：
缺点： - 当x86 / x64 dll不匹配时，在编译时没有错误。 - 您仍应在两种模式下运行测试！
可选地，在postbuild脚本中使用Corflags.exe创建一个专门用于x64架构的第二个可执行文件
其他变体尝试： - 如果您确保正确的dll已复制到启动时的二进制文件夹中（评估进程体系结构->将相应的dll从x64 / x86移动到bin文件夹中并返回），则无需使用AssemblyResolve事件处理程序。 - 在安装程序中评估体系结构，并删除错误体系结构的二进制文件并将正确的二进制文件移动到bin文件夹中。
我不确定你问题的完整答案，但我想指出SQL Compact 3.5 SP1下载页面的附加信息部分中的一条评论，因为你正在查看x64 - 希望它有所帮助。
由于 SQL Server Compact SP1 的更改和额外的 64 位版本支持，32 位版本的 SQL Server Compact 3.5 和 64 位版本的 SQL Server Compact 3.5 SP1 的集中安装和混合模式环境可能会出现间歇性问题。为了最大程度地减少冲突的可能性，并实现托管客户端应用程序的平台中立部署，使用 Windows Installer（MSI）文件集中安装 SQL Server Compact 3.5 SP1 的 64 位版本还需要安装 SQL Server Compact 3.5 SP1 MSI 文件的 32 位版本。对于仅需要本机 64 位的应用程序，可以使用私有部署的 64 位版本的 SQL Server Compact 3.5 SP1。你可以生成两个不同的解决方案，然后将它们合并在一起！我在VS 2010中做到了这一点，并且它是有效的。我使用CMake生成了2个不同的解决方案，然后将它们合并在一起。
如果您在MSI安装程序中使用.NET编写的自定义操作，则会遇到另一个问题。
运行这些自定义操作的“shim”始终是32位，因此无论您指定什么目标，您的自定义操作也将以32位运行。
更多信息和一些绕过方法（基本上是更改MSI以使用此shim的64位版本）
有可能您可以将产品安装为32位应用程序，但仍然能够使其作为64位运行，但我认为这可能有些难以实现。
话虽如此，我认为您应该能够为所有内容保留单个代码库。在我的当前工作场所，我们已经成功做到了这一点。（但是需要一些技巧才能让所有东西协同工作）
希望这可以帮助您。 以下是一些与32/64位问题相关的信息链接： http://blog.typemock.com/2008/07/registry-on-windows-64-bit-double-your.html