自定义操作中的RegAsm

Question

我有一个Outlook Addin，它是在针对.NET Framework 4.0的Visual Studio 2010中创建的。

此插件以前是用VB6编写的（因此只针对x86 Outlook）。

但是，我现在遇到问题，因为有两个版本的Outlook。

几年前我修改了这个，但有两个独立的MSI文件（一个针对x86，另一个针对x64 ......每个都有相应的启动条件，以防止用户在他们的Outlook上安装不正确的MSI）。

然而现在我遇到了更大的问题...越来越多的用户继续下载不正确的版本，他们生气了。

我希望制作1个安装程序文件并注册以下文件。

1. Shim x86
2. Shim x64

我已将这两个文件放在一个安装程序文件中（安装程序定位到x86），并且我通过订阅RegSvr32事件通过自定义操作运行Commit。

现在问题变成了我有一些.NET DLL。我基本上有一个DLL（它负责检查用户的注册是否满足）。

出于某种原因，即使我打电话给以下人员：

C:\Windows\Microsoft.NET\Framework\v4.0.30319\regasm.exe

对于基于x64的系统：

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\regasm.exe

对我的激活DLL和我的主DLL的完整调用如下：

C:\Windows\Microsoft.NET\Framework\v4.0.30319\regasm.exe /tlb MyDll.dll /Codebase

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\regasm.exe /tlb MyDll.dll /Codebase

代码运行成功（至少我的假设是它成功运行，因为Try/Catch中没有抛出错误）。

但是，当我通过我的应用程序进行调试并拨打CreateObject时，它只会返回一条错误，指出ActiveX Component cannot be created。

所以现在，情况变得更加复杂（我现在也很困惑），因为当我通过提升的命令提示符运行命令时代码似乎工作。

所以我有两个主要问题：

1. 我是否在自定义操作安装程序中正确运行命令？
2. 为什么命令通过提升的命令提示符工作（当我认为 MSI仍然以提升模式运行时？

如果需要，我可以发布更多代码。

Answer 1

好的，基本上，我自己解决了这个问题。

不需要使用long long来注册DLL。

我的两个垫片正在RegAsm方法期间运行的自定义操作安装程序中注册。

我基本上将Install运行到将两个Shims注册到系统。

另外，我摆脱了后期绑定。对RegSvr32的调用已替换为：

• 导入外部DLL作为参考
• 用早期绑定替换后期绑定（基本上使用该DLL的命名空间）

成功编译32位目标平台MSI后，我能够在x64 Outlook和x86 Outlook上安装它。