问题标签 [strongname]

我在 VS 2005 中有一个项目解决方案，其中在 asp.net 中有一个 Web 应用程序和几个用 C# 编写的库，供 Web 应用程序使用。我们在其项目属性中使用以强名称签名的解决方案项目的所有 dll/exe。

现在，当我们构建整个解决方案并尝试在 IE 浏览器上通过 asp 开发服务器运行 Web 应用程序时，它会抛出以下异常：

程序集“abc.dll”的强名称验证失败。该文件可能已被篡改或已部分签名但未使用正确的私钥完全签名。

所以请帮助我如何克服这个问题。

谢谢，
阿吉特

我知道不可能 100% 保证破解你的真实软件。但我只想保护我的产品免受普通用户未经授权的访问。

.Net 框架具有强类型名称的功能，可用于保护软件，因为您可以指定将加载的程序集和公钥令牌。

那么，使用公钥令牌防止产品破解的最佳方法是什么？

我一直在尝试签署程序集并收到此错误：

“Utils.Connection”没有实现接口成员“Interfaces.IConnection.BugFactory()”。“Utils.Connection.BugFactory()”无法实现“Interfaces.IConnection.BugFactory()”，因为它没有匹配的返回类型“ThirdPartyLibrary.BugFactory”。

那个错误看起来像一个肮脏，肮脏的谎言！在Utils.Connection，我有这个方法：

我不认为new关键字是问题，因为 1）删除它不会停止错误，2）我在另一个实现不使用关键字的类时遇到IConnection同样的new错误 。更新： 如果我使用，override而不是new，我得到这个错误：

'Utils.Connection.BugFactory()'：无法覆盖，因为 'ThirdPartyLibrary.ConnectionClass.BugFactory' 不是函数

这是因为ThirdPartyLibrary.ConnectionClass.BugFactory是一个属性。

只有一个BugFactory类，因此接口需要BugFactory与方法返回的返回类型不同的返回类型不是问题。即使我明确地将我的方法标记为返回ThirdPartyLibrary.BugFactory，当我尝试对UtilsDLL 进行强命名时，我仍然会收到错误消息。

这可能ThirdPartyLibrary是不符合 CLS 的旧 COM 库的结果吗？我无法控制这个库。当我不尝试签署Utils程序集时，我没有收到接口错误。

我的大问题是：我如何签署这个程序集？

编辑：这里有什么IConnection：

这可能真的很容易，但我很难过（而且我是 c# 的菜鸟）。我有 3 个相互引用的程序集（例如，注册委托方法的通知或调用公共方法），所有这些程序集都可以正常编译，直到我尝试使用强名称对其进行签名。然后我无法编译它们中的任何一个，因为其他两个没有强名称。我错过了什么？我已经为这三个文件创建了一个强名称文件，但不能包含 snk 并编译它们。

从谷歌得到指令后，我尝试使用以下命令创建 StrongNameFile：

当我运行命令时，我收到一条错误消息：

我通过以下方式进行了尝试：

但是得到了同样的错误。请有人帮我解决这个问题。

好的，我在这里阅读了关于强命名程序集的所有问题，只是想澄清一些事情。

首先，根据我的阅读，除了GAC，强命名程序集可以防止恶意第三方更改和冒充您的代码。有一些链接到在强命名程序集之前发生的这种欺骗的一些真实世界示例会很棒。

如果安全或 GAC 不是问题，似乎仍然建议使用强名称程序集，因为：

1. 具有强命名程序集的客户端只有在签名后才能引用您的程序集。

2. 没有强命名程序集的客户端可以引用您的程序集，无论它是否已签名。

这是一个公平的分析吗？

我正在使用 Visual Studio 2008，并且我有一个包含多个项目的解决方案。我有 1 个 snk 来签署我的程序集，它位于解决方案文件夹中。

我已将 snk 链接到我的每个项目，但现在当我尝试使用链接的 snk 签署我的项目时，我无法通过文件对话框找到 snk 文件。

我在这里错过了一步吗？

我们有不同版本的非强名称程序集，并且在 app.exe.config 中没有绑定重定向/探测路径到它们。例如，MyDll (1.0.0.0_null_neutral) 和 MyDll (2.0.0.0_null_neutral)。相对于 app.exe，这些程序集存储在 LAC\MyDll_1.0.0.0_null_neutral 和 LAC\MyDll_2.0.0.0_null_neutral 中。

我的理解是，因为 MyDll 程序集不是强命名的，.NET 运行时不会区分不同版本的 MyDll。因此，如果已将 MyDll 1.0.0.0 加载到内存中并且执行了针对 MyDll 2.0.0.0 构建的某些代码，则 .NET 运行时将不会加载 MyDll 2.0.0.0。

但是，当我使用 VS2008 附加到该进程并查看模块窗口时，我注意到 MyDll 1.0.0.0 和 MyDll 2.0.0.0 都是从 LAC 文件夹加载的。

我的理解似乎在某个地方存在差距。有人可以指出吗？

编辑：感谢到目前为止的回复。是的，我跳过了那一点。可执行文件侦听 AssemblyResolve 事件，并通过查看 LAC 来处理它。

我很确定我之前看过一些 MSDN 文档，除非程序集是强命名的，否则这些版本会被忽略。我看看能不能挖出来

My application consists of three assemblies: a single EXE which references a couple of DLLs. The DLLs are private to my application - they are used only by this executable.

Should these assemblies be given a strong name?

FxCop suggests that they should - for all of the assemblies it currently produces:

CA2210: Sign <assembly> with a strong name key.

However, this advice says:

In general, you should avoid strong-naming application EXE assemblies.

and

you may want to avoid strong-naming components that are private to your application.

Should I give these assemblies a strong name? What are the benefits of doing so (or not doing so) in this case?

Edit:

Looking at several applications with a similar structure, there seems to be no consensus on this issue. The binaries of Paint.NET and Crack.NET are not strong-named, whereas those of .NET Reflector and Snoop are.

Interestingly, with the Expression suite Microsoft have taken the latter approach: in Expression Blend, for example, they have chosen to strong-name sign both Blend.exe and the accompanying DLLs (such as Microsoft.Expression.Blend.dll).

It seems that I am unlikely to receive a simple answer to my first question: "Should I give these assemblies a strong name?". However, my second question still stands:

Are there any benefits to strong-name signing binaries in this situation? Or, are there any benefits to not doing so?

Edit 2:

If there are no overwhelming reasons to go either way, I am inclined towards giving my assemblies a strong name. I'd thus be interested in whether anyone can expand upon this (from the first link):

"strong-naming can make it more difficult to manage dependencies and add unnecessary overhead for private components."

是否可以检查当前已经与您自己正在运行的应用程序进程分开运行的 .NET 应用程序的强名称？

编辑：为澄清起见，不需要硬编码路径到执行程序集的解决方案将是最理想的解决方案。

编辑#2：有什么方法可以在不使用反射的情况下做到这一点？