在.Net Web服务中，是否可以确定程序集是否已加载到Web服务中？如果是的话，怎么做这样的检查？从这样的检查可以确定组件的原始位置？
这是一个漫长的故事，涉及在服务器上我们的应用程序的多个入口点之间共享的程序集，其中一些通过Web服务公开，而其他通过托管在普通Windows服务中的更传统的TCP套接字公开。可能还有其他Windows服务使用相同的共享程序集运行。每个的配置需求略有不同，并且类似System.Windows.Forms.Application.ExecutablePath的调用产生不同的结果，具体取决于“托管”程序集的内容。我需要能够可靠地计算程序集的位置来计算配置文件的位置。
在此方案中，Web.config / app.config不是选项。
可以在注册表中放入一个可用于确定应用程序和所有程序集所在位置的条目。但这并不像应用程序自己计算位置那样令人满意。
编辑：
我们可以从MyApp.asmx（Web服务）和MyService.exe（Windows服务）调用foo.dll。无论如何确定MyApp.asmx是否是从代码隐藏（MyApp.dll）加载foo.dll的应用程序？
答案 0 :(得分：1)
这将使所有程序集加载到当前执行上下文中：
Assembly[] loadedAssemblies = AppDomain.CurrentDomain.GetAssemblies();
答案 1 :(得分：0)
如果您拥有代码，最好添加一种初始化方法或某种类型的属性，可以通过调用代码来告诉程序集在哪里运行。实际上，您可以添加一个静态属性，它是配置文件的位置。
这也可以帮助您在其他场景中，例如在测试期间，您可能希望明确指定应该使用哪个配置文件，而不是嵌入逻辑来猜测要使用哪个配置文件。
答案 2 :(得分：0)
在研究网络服务的另一个方面时，我偶然发现了这个问题：
string path = Context.Request.ServerVariables["APPL_PHYSICAL_PATH"];
这将返回类似“C：\ inetpub \ wwwroot \ MyWebApp \”的内容，指示是否已安装该应用程序。具体路径取决于应用程序的安装位置。
正如问题所述，这不会直接帮助foo.dll弄清楚它是否是从Web服务调用的，因为foo.dll通常无法访问Context.Request。通过对foo.dll进行一些更改，它将允许Web服务告诉foo.dll应用程序根目录是什么。
答案 3 :(得分：-1)
您可以拨打电话：
Assembly.GetExecutingAssembly().CodeBase
在您的代码中，这将告诉您当前正在执行的程序集的位置。