我已经做了一些额外的测试，我现在相信我的问题的根源是.NET如何定位程序集。
正如我在下面提到的，子目录中有.dll文件，但我在下面提到的.dll文件并不是每个目录中唯一的.dll文件。例如，在\ translation \ Customer目录中有一个Customer.dll文件和几个标准文件（Translation.dll，Mapping.dll，Execute.dll）。在\ translation \ Standard目录中有一个Standard.dll，然后是其他标准文件（Translation.dll，Mapping.dll，Execute.dll）。这些文件都是生成的代码（来自不同的项目），这就是为什么每个目录都有标准文件的副本以及与子目录直接相关的文件。
当在我的Windows服务应用程序中执行Customer.dll文件中的方法时，也会调用标准程序集中的其他方法（Translation.dll，Mapping.dll等）。我相信在同一目录中的.dll上没有执行对其他.dll文件的调用。
例如，我在/translation/Customer/Customer.dll上调用一个方法，然后调用Translation.dll上的方法。但是，应用程序首先找到/translation/Standard/Translation.dll并在该文件上调用该方法，而不是调用/translation/Customer/Translation.dll上的方法。
是否可以强制.NET在同一目录中调用这些关联的.dll文件？或者我必须做些什么来使每个目录中唯一命名的“标准”程序集？
我有一个C＃Windows服务应用程序，它监视目录并处理传入的文件。每个被处理的文件都有一组可配置的任务针对该文件运行。每个任务的代码都包含在外部.dll中，该外部.dll在运行时使用反射动态加载。外部.dll存在于主应用程序文件夹的几个子目录中，并且通过app.config文件中应用程序的<probing>元素中的条目授予对它们的访问权。
我最近扩展了子目录的数量，以便更好地组织外部.dlls，我遇到了<probing>元素的一些意想不到的功能。我正在运行一个测试来处理一个文件，该文件需要对文件执行2个任务。第一个任务存在于Customer.dll文件中，位于名为“\ translation \ Customer”的子文件夹中。第二个任务存在Standard.dll文件，位于名为“\ translation \ Standard”的子文件夹中。
如果我的探测元素看起来像<probing privatePath="translation\Customer;translation\Standard">那么第二个任务（在“标准”文件夹中运行.dll上的方法）将无法执行。
但是，如果我切换这些条目以使探测元素看起来像<probing privatePath="translation\Standard;translation\Customer">这两个任务都成功执行。
任何人都可以帮助我理解为什么探测元素中子目录的顺序会对这些子目录中包含的.dll的执行产生影响吗？
答案 0 :(得分：0)
进一步调查显示，这不是反射或装配加载问题。我遇到的问题是由于我正在反思的组件内部构建问题。错误是模糊的，它使问题看起来像它不是。感谢SWeko注意查看内部异常。这个评论帮了很多!!