签名组件与多个项目和开发的最佳实践 [英] Best practices for signing assemblies with multiple projects and developers

问题描述

我在寻找的建议和最佳实践应用签名的程序集在一个组织中有30多个开发人员，20多个解决方案和60多个项目。我们使用Visual Studio团队系统2008和TFS。

I’m looking for recommendations and best practices for applying signed assemblies in an organization with 30+ developers, 20+ solutions and 60+ projects. We’re using Visual Studio Team System 2008 and TFS.

在创建密钥和签名程序集是一个非常容易和简单的过程，我很担心我们如何管理是最好的方法。

While creating a key and signing the assembly is a very easy and straight forward procedure, I’m concerned how we manage this the best way.

我的想法至今：

• 每个溶液，其通常具有3至20个项目，将具有置于溶液中的根文件夹的单一的.pfx密钥文件。
• 在每个解决方案都将有一个独特的强密码的钥匙。

我们会遇到这种做法的任何问题？

Will we encounter any problems with that approach?

一些其他的想法：

• 使用相同的密钥文件进行跨解决方案的所有项目。这会不会让东西更容易为我们吗？它是一个坏主意？它甚至有可能？
• 如果每个项目都有自己独特的钥匙吗？为什么，为什么不呢？

任何投入，好/坏的经验和建议欢迎。 ：）

Any input, good/bad experiences and recommendations are welcomed. :)

推荐答案

在过去，我已经很有效地用于多种解决方案和项目的一个键。它是一种简单的方法，确保能够访问私钥文件只有人可以发布一个版本是经过强名称检查。

In the past, I've used a single key for multiple solutions and projects very effectively. Its a simple approach that ensures that only people with access to the private key file can publish a build that passes the strong name check.

请注意：要使用单独的密钥文件，我们发现它最简单的将文件添加为纽带，以每个项目

Note: To use the single key file, we found it easiest to add the file as a link to each project.

的一个缺点我看到的是，有可供开发人员密钥文件意味着它不是很私人，因为它应该是。理想的情况下，尽可能少的人可能（例如刚刚构建过程中）应该能够访问/知道密码。

The one disadvantage I see is that having the key file available to your developers means its not quite as private as it should be. Ideally, as few people as possible (eg just the build process) should have access / know the password.

在单个文件的方法保持简单的密钥的管理（这里只有一个），同时仍然允许强命名的好处。

The single file approach keeps the management of the keys simple (there's only one) while still allowing for the benefits of strong naming.

这篇关于签名组件与多个项目和开发的最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！