是否可以通過路徑而不是通過GUID引用託管項目中的COM DLL？

我有一個託管（asp.net，實際）項目引用一個COM DLL。眼下，在.csproj的參考如下：是否可以通過路徑而不是通過GUID引用託管項目中的COM DLL？

<COMReference Include="thenameinquestion"> 
    <Guid>{someguidhere}</Guid> 
    <VersionMajor>1</VersionMajor> 
    <VersionMinor>0</VersionMinor> 
    <Lcid>0</Lcid> 
    <WrapperTool>tlbimp</WrapperTool> 
</COMReference>

這工作，但它不幸的後果，即DLL需要在構建機器，這意味着上註冊（除其他事項外），它的不方便在同一臺生成機器上構建使用不同版本的DLL的多個版本的項目。

MSDN顯示ResolveComReference任務，看起來像是正確的事情，但我的谷歌搜索功能不夠好，拿出一個實際的使用示例。有可能做我想做的事嗎？我在正確的軌道上嗎？

來源

2009-07-09 Dan Davies Brackett

本文演示如何執行COM組件的免註冊激活。也許它會幫助：http://msdn.microsoft.com/en-us/library/ms973913.aspx

來源

2009-07-20 16:49:22

由於John Fisher已指出，您正在尋找Registration-Free COM Interop。關於這一點已經有很多問題了，請查看'tag at hand'regfreecom和密切相關的標籤sxs。

你會很容易看到，但是，這可能是一個棘手的領域，特別是：

似乎有此影響在Windows XP上confirmed錯誤，請參閱here瞭解詳情。儘管已經有一個修補程序可用，但只要您僅限於受控環境（例如，你的機器。
既然你是針對ASP.NET，你應該知道，與例如這意味着您無法控制託管過程，這可能會因部署平臺而異。這意味着提供所需的應用程序清單來控制主機內的COM組件的運行時綁定和激活並不容易（請參閱下一個可能的備選方案）。
ASP.NET 2.0似乎通過爲非託管組件降低並排功能而使事情變得更加複雜。我還沒有找到這方面的官方消息，但Isolating ASP .Net 2.0 Applications的作者似乎知道;他至少提供了一種解決方法，雖然看起來很複雜並且可能很脆弱。

總結這一點，我想強調的是'免註冊COM Interop'可以是非常有用的，並且可以輕鬆地解決很多場景。儘管如此，它可能無法讓您的特定場景和環境（託管ASP.NET）更容易甚至完全可能。

祝你好運，請讓我們知道你是否成功！

來源

2009-07-24 10:29:47

-1

看起來不可能 - Visual Studio只會查看引用中提到的GUID，它並不關心在那裏暗示的路徑。

我們的日常構建服務器有類似的問題 - 除非註冊COM服務器，否則COM客戶端將無法編譯。我們只是將註冊/註銷添加到構建序列中 - 它註冊（regsv32）組件，然後VS從命令行運行，並在VS完成時立即取消註冊該組件（regsvr32 -u）。運行流暢。

來源

2009-07-24 10:50:10 sharptooth

當您引用COM DLL時，Visual Studio會自動爲其生成一個interop程序集。我發現手動控制這個過程是解耦COM和.NET構建的好方法。

使用tlbimp.exe創建您自己的COM DLL的互操作程序集。有關命令行參數，請參閱MSDN。
在.NET項目中引用您的interop程序集而不是的COM DLL。

一旦你這樣做了，當你構建.NET解決方案時，不再需要在計算機上註冊COM DLL，只需要你的interop程序集。

互操作程序集可以永遠保持不變的文件夾，直到（a）COM DLL破壞二進制兼容性，或（b）更改.NET代碼實際使用的COM接口。

如果您有不同版本的COM DLL，它們都是二進制兼容的，那麼針對包含.NET代碼所需接口的最早版本編譯互操作程序集。您將不必爲不同的版本更新互操作程序集。

此外，如果您能夠假定COM DLL已經安裝在目標機器上，則不需要在安裝程序中包含COM DLL。

來源

2009-07-25 17:05:24

是否可以通過路徑而不是通過GUID引用託管項目中的COM DLL？

回答

相關問題