从GAC中注册的COM可见DLL访问非COM可见DLL方法 [英] Accessing a non-COM visible DLL method from a COM visible DLL registered in GAC

问题描述

我的网站应用程序使用以特定身份运行的C#COM +组件来访问从经典ASP调用的SQL Server.

在网站应用程序中还有一个利用\ bin DLL的Web服务，其中包含一种将一些数据插入SQL Server数据库的方法(我们称其为 MyApp.Database.dll )./p>

从网站前端，我希望能够为经过身份验证的用户提供相同的功能.

出于明显的原因，我不想在COM +组件内的 MyApp.Database.dll 中重复代码.

我的想法是利用ASP中的COM +组件来调用 MyApp.Database.dll 方法，以使用应用程序凭据访问SQL数据库，因为ASP以用户身份运行并且没有访问权限到SQL Server.

我似乎遇到的问题是，尽管我可以在我的COM +组件项目(在参考"下和使用MyApp.Database.dll"下)中引用MyApp.Database.dll，但实际上它还是调试COM +组件时，当尝试从MyApp.Database.dll调用该方法时，它告诉我'无法加载文件或程序集'MyApp.Database，版本= 3.3.3.11658，文化=中性，PublicKeyToken =. ....'或其依赖项之一.'

MyApp.Database.dll 未在GAC中注册(为避免这种情况，其他应用程序也正在使用它)，并且未使用再通气(我尝试了此操作，但仍然没有效果).版本正确，并且已将 MyApp.Database.dll 放置在COM +组件的应用程序文件夹中.

我错过了什么吗?还是无法做到这一点?

预先感谢您的帮助.

解决方案

这是一个常见的错误期望:仅仅是因为您的.NET COM DLL是在某个给定的文件夹(由/codebase参数或RegAsm设置的文件夹)中找到的- -这并不意味着.NET会在该文件夹中查找其他内容.

通常来说，不会.通过COM互操作加载.NET程序集是一种特殊情况.对于其他所有内容，程序集将根据该过程的Fusion绑定策略 加载到AppDomain中，这与.NET COM DLL的位置无关.该过程实际上是dllhost.exe，iisexpress.exe或w3wp.exe(取决于IIS的版本).

您有一些选择.

首先，一个显而易见的解决方案是将MyApp.Database.dll放入GAC，因为.NET始终在其中.有时候，这是正确的选择(我已经做到了，而且行得通).您拒绝这样做，并且您有自己的理由；没关系.

第二，我相信您可以使用web.config文件更改绑定策略.请参阅此处: http://msdn.microsoft. com/en-us/library/823z9h8w(v = vs.110).aspx .是的，您的ASP Classic项目可以具有一个web.config.显然，它对您的ASP Classic脚本没有影响，但是(取决于IIS的版本)、. NET和/或IIS本身使用它进行配置.恐怕我无法使用此替代方法，因为我之前从未尝试过，但我很乐意探索该选项-让我知道它的运行方式.

第三种选择-我个人的选择:您说这个DLL已经是一个Web服务，对吗?只需通过COM DLL中的Web服务调用即可调用该功能.不需要使用魔术文件夹，GAC和绑定策略进行处理.干净得多.唯一的麻烦就是跟踪您的Web服务所在的配置-我敢打赌，无论如何，您已经为数据库连接进行了配置，因此添加起来应该不难.

如果您想知道.NET在哪里寻找DLL，请仔细阅读以下内容:

• 如何在.NET中启用程序集绑定失败日志记录(融合)
• http://www.hanselman.com/blog/BackToBasicsUsingFusionLogViewerToDebugObscureLoaderError>.
• http://www.hanselman.com/blog/MoreOnAssemblyBindingStrongNamingAndGADPublishedPolicy

祝您好运，请告诉我们什么对您有用.

My website application uses C# COM+ components running under a particular identity to access SQL Server, invoked from classic ASP.

There's also a web service that utilises a \bin DLL in the website application that contains a method to insert some data into the SQL Server database (let's call it MyApp.Database.dll).

From the website front end, I want to be able to provide authenticated users with this same functionality.

I don't want to duplicate code in MyApp.Database.dll within the COM+ component for obvious reasons.

My idea was to utilise the COM+ component from ASP to invoke the MyApp.Database.dll method to access the SQL database using the application credential since the ASP is running as the user and has no access to SQL Server.

Problem I've seem to run into is that although I can reference MyApp.Database.dll in my COM+ component project (under 'References' and 'using MyApp.Database.dll'), when it comes to actually running or debugging the COM+ component, when it tries to invoke the method from MyApp.Database.dll, it tells me 'Could not load files or assembly 'MyApp.Database, Version=3.3.3.11658, Culture=neutral, PublicKeyToken=.....' or one of its dependencies.'

The MyApp.Database.dll is not registered in GAC (trying to avoid this, it's also used by other applications as well), and hasn't had its codebase registered in the registry using regasm (I tried this and still didn't work). The version is correct, and I've placed MyApp.Database.dll in the application folder of the COM+ component.

Am I missing something or is it not possible to do this?

Thanks in advance for your help.

解决方案

This is a common mistaken expectation: just because your .NET COM DLL was found in some given folder (the folder set by the /codebase argument or RegAsm) -- it doesn't mean .NET will look on that folder for anything else.

Generally speaking, it won't. Loading a .NET assemblies via COM interop is a special case. For everything else, assemblies will be loaded in the AppDomain based on the Fusion binding policy for the process - which has nothing to do with where your .NET COM DLL is. The process is actually (depending on your version of IIS) either dllhost.exe, iisexpress.exe or w3wp.exe.

You have a few options.

First, the obvious solution is putting MyApp.Database.dll in the GAC, since .NET always looks there. Sometimes that's the right choice (I've done that and it works). You have declined to do so and you have your reasons; that's Ok.

Second, I believe you can change the binding policy with a web.config file. See here: http://msdn.microsoft.com/en-us/library/823z9h8w(v=vs.110).aspx. Yes, your ASP Classic project can have a web.config. Obviously it has no effect on your ASP Classic scripts, but (depending on the version of IIS), .NET and/or IIS itself use it for configuration. I'm afraid that I can't help you much with this alternative because I've never had to try it before, but you're welcome to explore that option - let me know how it goes.

Third option - my personal choice: You said this DLL is already a web service, right? Just call the functionality with a web service call from your COM DLL. That doesn't require mucking with magic folders, GAC and binding policies. Much cleaner. The only mild complication is tracking in configuration where your web service is located - and I bet you already do that for your database connection anyway, so it shouldn't be hard to add.

If you are curious to know where .NET is looking for the DLL, read up on these guys:

• How to enable assembly bind failure logging (Fusion) in .NET
• http://www.hanselman.com/blog/BackToBasicsUsingFusionLogViewerToDebugObscureLoaderErrors.aspx
• http://www.hanselman.com/blog/MoreOnAssemblyBindingStrongNamingTheGACPublisherPolicyAndDynamicallyLoadedAssemblies.aspx

Good luck, and please let us know what worked for you.

这篇关于从GAC中注册的COM可见DLL访问非COM可见DLL方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！