У нас есть пакет jar, преобразованный в DLL-библиотеку .Net с использованием IKVMC.
(ikvmc mylib.jar -target: library -out: mylib)
Мы можем назвать это Converted.dll
Этот Jar-файл содержит некоторые ресурсы .cfg.
При использовании DLL внутри основного приложения, тестовой консоли .net, все нормально ...
Мы можем назвать это Caller.exe
Мы переместили (на которую ссылаются) преобразованную .Net DLL в другую библиотеку DLL, чтобы обернуть и раскрыть только некоторые методы.
Мы можем назвать это WrapperOfConverted.dll
Так что в Caller.exe мы ссылаемся на WrapperOfConverted.dll вместо Converted.dll
Теперь, когда мы вызываем из консольного приложения (Caller.exe) упаковщик (WrapperOfConverted.dll), он не может загрузить файлы данных «.cfg» (они находятся внутри Converted.dll).
Странно ... может быть, мы должны каким-то образом преобразовать?
UPDATE:
В Caller, внутри bin \ debug, у меня есть ссылки на WrapperOfConverted.dll и Converd.dll (на которые ссылается WrapperOfConverted.dll)
Декомпилируя с помощью ILSpy Converted.dll, внутри dll я отчетливо вижу папку «Ресурсы», внутри находится файл с именем исходного jar, ILSpy помечает этот файл как внедренный / общедоступный. Я могу сохранить этот файл из ILSpy. Сохранено как файл jar. Вложенности. Внутри находится структура исходного jar-файла, все папки с классами пусты, но папки ресурсов с файлами cfg заполнены файлами.
Таким образом, данные cfg присутствуют в Converted.dll, но WrapperOfConverted.dll не может получить к ним доступ. Это только при наличии тройной ссылки (Caller REFERENCES WrapperOfonverted REFERENCES Convertible)
Если я прямо из Caller REFERENCE Converted, все кажется ОК.
Еще одна странная вещь: я пытался ссылаться также на Converted внутри Caller, сначала вызывать какой-то универсальный метод convert, когда Caller затем вызывает некоторые методы WrapperOfConverted, а WrapperOfConverted вызывает внутри себя методы Converted, проблема больше не существует, это видит файл данных cfg!