OAuth的一个.NET开源实现

时间：2022-04-02 21:45:52

从编译DotNetOpenAuth中学到的程序集强签名知识

OAuth的一个.NET开源实现，官方网站：http://dotnetopenauth.net/ 。

从GitHub签出DotNetOpenAuth的源代码发现最新版本已到5.1，而NuGet中发布的版本只是4.3。新版中使用到了.NET 4.5的异步特性（async, await），于是决定直接用最新版。

用最新版，就要自己进行编译。用Visual Studio 2012打开解决方案文件进行编译，一次编译成功，但编译出的DotNetOpenAuth相关dll有20个，这么多dll引用起来不方便。发现DotNetOpenAuth提供了msbuild的配置文件，可以在编译时自动将dll文件进行合并（使用了ILMerge）。于是改用msbuild命令进行编译。

2. 用msbuild进行第一次编译

2.1. 使用的是DotNetOpenAuth的tools\drop.proj编译配置文件，为了加快编译速度，注释了下面的内容：

OAuth的一个.NET开源实现
<!--<ItemGroup>

    <ProjectsToBuild Include="$(ProjectRoot)samples\samples.proj">

        <Properties>TargetFrameworkVersion=v4.5</Properties>

    </ProjectsToBuild>

    --><!-- Sandcastle doesn't seem to be able to handle .NET 4.0 dependencies right now. --><!--

    <ProjectsToBuild Include="$(ProjectRoot)doc\doc.proj">

        <Properties>TargetFrameworkVersion=v4.5</Properties>

    </ProjectsToBuild>

</ItemGroup>-->
OAuth的一个.NET开源实现

2.2. 运行VS2012的命令行：Developer Command Prompt for VS2012

2.3. 运行msbuild命令：

msbuild tools/drop.proj

2.4. 编译成功

OAuth的一个.NET开源实现

2.5. 在drops\v4.5\Debug文件夹中得到合并后的DotNetOpenAuth.dll。

3. 测试已编译的DotNetOpenAuth

3.1. 在另外的项目中引用已编译出的DotNetOpenAuth.dll

3.2. 编译后运行项目，出现错误提示：

Could not load file or assembly 'DotNetOpenAuth' or one of its dependencies. Strong name signature could not be verified. The assembly may have been tampered with, or it was delay signed but not fully signed with the correct private key. (Exception from HRESULT: 0x80131045)

从这个错误信息中可以解读出：需要对DotNetOpenAuth进行强签名。

4. 使用强签名进行msbuild编译

4.1.  生成公钥

生成公钥需要借助sn.exe（sn是Strong Name的缩写），它是Visual Studio/Windows SDK中自带的一个工具。运行sn.exe命令需要进入Developer Command Prompt for VS2012。

具体操作步骤如下：

4.1.1. 生成密钥对（公钥/私钥）并保存至.pfx文件中

sn -k mykeyfile.pfx

4.1.2. 将密钥对从文件安装至密钥容器中

sn -i mykeyfile.pfx mykeycontainer

4.1.3. 从存放密钥对的.pfx文件中导出公钥至.pub文件

sn -p mykeyfile.pfx mykeyfile.pub

4.1.4. 显示.pub文件中存放的公钥

sn -q -t mykeyfile.pub

4.2. 使用生成的公钥进行msbuild编译

msbuild /p:KeyPairContainer=mykeycontainer,PublicKeyFile="<full path>mykeyfile.pub" tools/drop.proj

4.3. 编译成功

5. 测试已进行强签名编译的DotNetOpenAuth

原以为问题到此就解决了，哪知测试结果出人意料——同样的错误！。。。后来恍然大悟，不放在GAC中，强签名怎么会起作用呢？

6. 将DotNetOpenAuth注册到GAC

6.1. 进入Developer Command Prompt for VS2012命令行

6.2. 运行gacutil命令：

gacutil /i DotNetOpenAuth.dll

6.3. 却出现错误提示：

Failure adding assembly to the cache: Strong name signature could not be verified.  Was the assembly built delay-signed?

6.4. 解决方法——用sn命令忽略对强签名进行验证：

sn -Vr *,<之前创建的公钥>

6.5. 然后再运行gacutil，注册就成功了。

Assembly successfully added to the cache

7. 测试已注册至GAC的DotNetOpenAuth

7.1. 本以为到这里应该大功告成了。。。可是在VS2012中添加引用时，在Assemblies中怎么也找不到DotNetOpenAuth。

OAuth的一个.NET开源实现

DotNetOpenAuth不是已经注册到GAC中了吗？Assemblies不就是GAC中的assemblies吗？

7.2. 搜索网上的资料才了解到Visual Studio添加引用时的Assemblies与GAC一点关系没有，GAC是.NET程序运行时用到的东西，而且这里的assemblies只是VS专用的一个存放程序集的文件夹。可是我以前一直以为它显示的就是GAC中的程序集。是因为我的愚蠢呢，还是因为微软反直觉的设计？即使前者，好的设计应该——别让用户发呆（推荐阅读别让用户发呆——设计中的防呆策略）。

8. 问题解决

按通常的做法，在VS中添加引用时，选择Browse，选择DotNetOpenAuth.dll所存放的文件路径，点击OK。成功引用之后，编译/运行项目，就大功告成了。你会发现，已经在GAC中注册过的程序集，添加引用时，VS将自动将Copy Local属性设置为False；否则为True。这就是程序集在与不在GAC中的一个区别之处。

OAuth的一个.NET开源实现

9. 参考资料

https://github.com/DotNetOpenAuth/DotNetOpenAuth/wiki/ContributorQuickStart

 
 
 
标签: .NET

相关文章