更新 - 下面的原始问题
我做了一些额外的测试，现在我相信我的问题的根源是.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">第二个任务（在“Standard”文件夹中运行.dll上的方法）将无法执行。
但是，如果我切换这些条目以使探测元素看起来像<probing privatePath="translation\Standard;translation\Customer">这两个任务都成功执行。
任何人都可以帮助我理解为什么探测元素中的子目录的顺序会对这些子目录中包含的.dll的执行产生影响吗？
Update - Original Question Below
I've done some additional testing and I now believe that the source of my problems is how .NET is locating the assemblies.
As I mentioned below there are .dll files in subdirectories but the .dll files I mentioned below are not the only .dll files in each directory. For example, in the \translation\Customer directory there is a Customer.dll file and a couple standard files (Translation.dll, Mapping.dll, Execute.dll). In the \translation\Standard directory there is a Standard.dll and then the other standard files (Translation.dll, Mapping.dll, Execute.dll). These files are all generated code (from different projects) which is why each directory has copies of the standard files as well as a file that's directly related to the subdirectory.
When a method from the Customer.dll file is executed in my Windows Service application other methods in the standard assemblies (Translation.dll, Mapping.dll, etc...) will also be called. I believe that calls to other .dll files are not being executed on the .dll in the same directory.
For example, I call a method on /translation/Customer/Customer.dll and, in turn, that calls a method on Translation.dll. However, instead of the calling the method on /translation/Customer/Translation.dll the application is finding /translation/Standard/Translation.dll first and calling the method on that file.
Is it possible to force .NET to make calls to these associated .dll files within the same directory? Or do I have to do something to make the "standard" assemblies uniquely named in each directory?
Original Question:
I have a C# Windows Service application that monitors a directory and processes incoming files. Each file that gets processed has a configurable set of tasks run against the file. The code for each task is contained in an external .dll that is loaded dynamically at run time using reflection. The external .dlls exist in several subdirectories of the main application folder and access to them is granted via entries in the application's <probing> element in the app.config file.
I've recently expanded the number of subdirectories to better organize the external .dlls and I've encountered some unexpected functionality with the <probing> element. I am running a test to process a file that requires 2 tasks to be executed against the file. The first task exists in the file Customer.dll and is located in a subfolder called "\translation\Customer". The second task exists the file Standard.dll and is located in a subfolder called "\translation\Standard".
If my probing element looks like this <probing privatePath="translation\Customer;translation\Standard"> the second task (running a method on a .dll in the "Standard" folder) will fail to execute.
However, if I switch these entries so that the probing element looks like this <probing privatePath="translation\Standard;translation\Customer"> both tasks execute successfully.
Can anyone help me understand why the order of subdirectories in the probing element would have an effect on the execution of .dlls contained within those subdirectories?
最满意答案
进一步调查显示，这不是反射或装配加载问题。 我遇到的问题是由于我正在反思的组件内部构建问题。 错误是模糊的，它使问题看起来像它不是。 感谢SWeko注意查看内部异常。 这个评论帮了很多!!
Further investigation has revealed that this was not a reflection or assembly loading problem. The problems I was experiencing was due to build issues inside the assemblies I was reflecting on. The errors were obscure and it made the problem look like something it wasn't. Thanks to SWeko for noting to look into the inner exceptions. That comment helped a lot!!
更多推荐
发布评论