在32位和64位开发站上部署.Net应用程序源控制（SVN）

Question

情况如下：
我们的开发团队拥有异构的操作系统，分散在32位和64位之间。 这并不理想，我们实际上计划将我们的基础设施同质化，但与此同时我们必须处理它。

问题是，当32位开发人员在SVN上检出64位解决方案时，他必须再次手动更改目标平台以进行编译（更不用说其他方面的问题）

我的问题是：
在这种情况下可以解决什么干净（虽然是临时的）解决方案，允许每个开发人员在从SVN签出和退出时保留其默认项目/平台设置。

我想 - 至少在第一次检查项目/解决方案时，开发人员仍然必须手动调整设置以正确编译它。 之后，根据相关的SVN过滤器，可以忽略一些设置文件（顺便说一下？）

我对所有聪明而详细的建议持开放态度。

谢谢。

Answer 1

您是否将.suo和.user文件签入源代码管理？ 因为这些应该是开发人员特定的， 不应包括在内。 非常确定suo为每个用户维护项目的构建状态。

另一种选择是从脚本执行构建。 例如，我有4个不同的构建脚本文件与autohotkey连接，以构建项目的后台发布和调试模式版本。 这可以通过msbuild或nant配置您希望项目配置的外观。

这有利于不占用视觉工作室。

它有进一步定制您的解决方案的缺点，但长期来看，我认为您处于更好的状态。

Answer 2

您是否有理由专门针对32位和64位的解决方案？ 例如：本机，非托管DLL？

如果使用“Any CPU”平台选项，则.NET将以64位或32位模式本机运行，具体取决于计算机上可用的内容。

编辑：如果必须静态设置CPU模式，则另一个选项是设置x86-32和x86-64构建配置，然后让开发人员在其末端选择适当的构建配置。

我强烈建议你弄清楚你的AnyCPU模式有什么问题，好像你没有 - 你需要为你的用户提供两个基于他们操作系统模式的安装包。

Answer 3

只要你只使用托管网络代码（没有本机32/64位代码），每个机构只能在64位和32位开发站上使用32位解决方案 。 在win7-64视觉工作室也是一个32位的应用程序。