Dllhell与.NET

与其试图找出我正在处理的个人痛苦，我想给出10000英尺的概述。我一边学习.NET，一边怀疑我在这里遗漏了什么。 星期天我坐在那里加班，如果有人能拿出五分钱，我将不胜感激

---

下面是：

我们的主要产品是过程控制系统。 有许多扩展/定制系统的可能方法。传统上，我们将控制系统的释放与被控制的工艺装置的特定配置分开，以便将两者分开维护

C:\Control System base release\（我称之为CS$）这是基本版本。Bug修复等

C:\Delivery Project\（我称之为Proj$）这是被控制系统的信息

一点背景：

• 我们的服务工程师希望能够在不丢失定制数据的情况下重新安装或升级CS$文件夹
• 交付项目通常由XCOPY部署
• 两者之间有一些dll引用，在MFC中工作良好
• 在我们的实验室机器上，同时安装多个版本是很常见的
• 系统是从安装环境的交付项目中的.bat文件启动的，然后启动。发射过程是环境变量密集的

现在，在使用.NET时，我在适应这种模型方面遇到了一些困难。 当系统使用嵌入式.NET控件或显示winform时，mscorlib会按需加载，CS$\Run\bin是应用程序的基本路径。这给我带来了一些问题：

• 在Proj$下部署的.NET程序集位于应用程序基本路径之外
• 如果人们重新安装控制系统基座，则在CS$\Run\bin下部署的.NET程序集将被删除。当然，我可以将部署作为批量启动的一部分
• .NET程序集路径由驻留在Proj$文件夹结构中的文本配置提供。交付项目中的相对路径很常见，但当它们开始访问CS$时会出现问题，CS$可能会发生更改
• 在CS$\Run\bin下部署的.NET程序集可能具有更多依赖项。我可能在CS$\run\bin\ext1和CS$\run\bin\下有两个不同版本的Util1.dll。这导致CLR无法解析CS$\run\bin\ext1\util1.dll，因为探测路径顺序
• 我已经尝试过分离appdomains，但是在CS$\run\bin\ext1\ext1.dll中找到的类的实例可能有数百个。我大量使用单例（静态）来协调资源管理

不用说，我使用了很多反射器和Fuslogvw。还有其他我应该知道的工具吗？ 是否可以检查正在运行的进程中的CLR信息？由于mscorlib是按需加载的，我有时会发现CLR的应用程序库远远不够。这有时会阻止加载代码，因此我无法通过编程方式访问appdomain或将其输出到跟踪

在从应用程序基路径启动之前，是否有任何方法可以控制探测路径从调用程序集相对启动

GAC中的混合模式程序集能否访问CS$中的MFC资源

虽然我没有按需加载mscorlib的MFC代码库，但我有一句话要说。有什么可以做的吗？我将请求在加载mscorlib时将关键信息输出到跟踪（以及异常）

如能提供文章、工具或简短的描述，我将不胜感激

---

我感谢您花时间阅读本文，并在我在这里描述的遗留问题中保持清醒的头脑：）

如果.Net的程序集探测逻辑不适合您，您可以始终使用IHostAssemblyManager和IHostAssemblyStore使用自己的代码扩展CLR主机。请参阅或阅读以了解有关该选项的更多信息

---

另一种选择是重构应用程序以适应.Net的规则，而不是强制.Net按您的规则运行。如果你写下功能需求而不是技术需求，你可能会发现你可以用另一种方式实现与.Net相同的目标。与使用作为程序集标识的一部分等类似。

如果您记录了如何解决非托管程序集的此问题，则会有所帮助。指示Windows查找非托管DLL的选项受到的限制要大得多。如果您将.NET程序集安装到GAC，您的问题将很容易解决，但这与您的部署策略不太兼容

---

总之，通过实现AppDomain.AssemblyResolve事件，几乎可以肯定地解决您的问题。当CLR需要查找程序集但自身找不到时，将调用此函数。您的代码必须知道CS$和Proj$文件夹的位置，才能使其正常工作。

好东西。非常感谢。我仍然在.NET1.1中，在常规探测尝试并失败之前，它不允许我重写。我听你说过重构问题，但问题是在我们的控制系统中，.NET只是许多扩展点中的一个。项目和软件的分离在我们的分布和部署策略中得到了高度集成。如果程序集作为常规启动的一部分从控制系统基本文件夹中丢失，我可能必须退出启动脚本以进行检查，并在必要时重新部署这些程序集。这是否允许我加载不位于应用程序基本路径下方或GAC中的依赖程序集？是的，可以使用Assembly.LoadFrom（）在事件处理程序中。