我们有一个jar包，使用IKVMC在.Net DLL库中转换。 （ikvmc mylib.jar -target：library -out：mylib） 我们可以将其命名为Converted.dll
此Jar包含一些资源“ .cfg”数据。
在主应用程序（测试控制台.net）中使用DLL时，一切正常... 我们可以将其命名为Caller.exe
我们将.Net转换的DLL移动（引用）到另一个DLL库中，以仅包装和公开某些方法。 我们可以将其命名为WrapperOfConverted.dll
因此在Caller.exe中，我们引用WrapperOfConverted.dll而不是Converted.dll
现在，当我们从控制台应用程序（Caller.exe）调用包装程序（WrapperOfConverted.dll）时，它无法加载“ .cfg”数据文件（它们位于Converted.dll中）。
这很奇怪...也许我们必须以某种特定方式进行转换？
更新：
在Caller中的bin \ debug中，我引用了WrapperOfConverted.dll和Converd.dll（由WrapperOfConverted.dll引用）
使用ILSpy反编译Converted.dll，我可以清楚地看到dll中有一个“ Resources”文件夹，里面有一个带有原始jar名称的文件，ILSpy将该文件标记为嵌入式/公共。我可以从ILSpy保存该文件。另存为jar文件。解压缩。里面是原始jar的结构，所有带有类的文件夹都是空的，但是带有cfg文件的资源文件夹中已经充满了文件。
因此，数据cfg存在于Converted.dll中，但WrapperOfConverted.dll无法访问它。仅当存在三重引用时（调用方引用WrapperOfonverted REFERENCES Converteed） 如果我直接来自于Caller REFERENCE Converted，一切似乎都可以。
另一个奇怪的事情是：我尝试在Caller中也引用了Converted，首先调用了转换的通用方法，当Caller然后在WrapperOfConverted中调用了某些方法，并且WrapperOfConverted在其内部的Converted方法中调用时，问题不再存在了，它看到cfg数据文件！