Проблемы с DLL, вызывающие исключение приведения - PullRequest
1 голос
/ 06 июля 2010

Я разбил большой проект VS C # на более мелкие проекты, и, хотя все работало нормально, когда это был всего один проект, я получил ошибку, теперь, когда я разделил его.Возникает исключение при попытке приведения, хотя я не изменил ни один код.Исключением является следующее:

InvalidCastException
[A] MyApplication.MyProject.MyNamespace.Class не может быть приведен к [B] MyApplication.MyProject.MyNamespace.Class.Тип A происходит от «MyProgram, Version = 2.4.0.46, Culture = нейтральный, PublicKeyToken = null» в контексте «По умолчанию» в расположении «c: \ WINDOWS \ Microsoft.NET \ Framework \ v2.0.50727 \ Temporary ASP.NET Files».\ гс \ 78e25ad5 \ 28e4b7d \ сборка \ DL3 \ 877f6451 \ b808fef4_4e19cb01 \ MyProgram.DLL.Тип B происходит от «MyProgram, Version = 2.4.0.46, Culture = нейтральный, PublicKeyToken = null» в контексте «LoadFrom» в расположении «C: \ Source \ view \ Application \ Version \ core \ bin \ MyProgram.dll».

Как видите, два типа в актерском составе идентичны, единственными различиями являются контексты и локации.Метод с именем GetHelperPage () является источником проблемы - это внешний метод во внешнем приложении.Обычно это не будет проблемой, за исключением того, что внешнее приложение затем вызывает эту dll.Метод выглядит следующим образом:

[DllImport ("EpsComHelper.dll", EntryPoint = "EPSCOMClientGetPage", CallingConvention = CallingConvention.Cdecl, CharSet = CharSet.Ansi)]
частный статический extern intHelperGetPage (uint pClient, String sPage, StringBuilder sBuff, int nBuffSize);

Эта внешняя программа имеет правильный путь для DLL: "C: \ Source \ view \ Application \ Version \ core \ bin \ MyProgram.dll".Однако VS загружает dll во временные файлы и запускает его оттуда, как вы можете видеть по пути в исключении выше.Это делает его таким, что он выглядит в двух одинаковых библиотеках, что вызывает ошибку.Я видел ответы на Отражение и приведение , но у меня нет ConfigurationManager.AppSettings ["DLL_File_Path"] или Assembly.LoadFrom ("path.dll") где-нибудь в моем решении.Фактически, Assembly или LoadFrom или местоположение dll вообще никогда не упоминаются в решении.Все, что я могу думать, это то, что VS каким-то образом делает это за кулисами, и я не могу найти где-нибудь, где я могу это изменить.Любая помощь приветствуется.

Стек вызовов для ошибки:

RedCarpetCore.dll!RedCarpet.Core.EpsInProcess.EpsConnector.ChangeLogLevel(string[] args = {string[3]}) Line 3727 + 0x1d bytes
DotNetBridge.DLL!<Module>.RunMethodInProcess(sbyte* szAssembly = 0x035b7db4, sbyte* szFullyQualifiedName = 0x08ebfcf4, sbyte* szClientPtr = 0x0bccd26c, int nArgs = 2, sbyte** arrArgs = 0x0263190c) + 0x43f bytes
[Native to Managed Transition]
DotNetScriptPlugin.dll!034d9e5f()
ntdll.dll!7c827a29()
kernel32.dll!77e6570a()
MSVCR71.DLL!7c352d9b()
MSVCR71.DLL!7c3531c5()
MSVCR71.DLL!7c352e69()
MSVCR71.DLL!7c36a582()
MSVCR71.DLL!7c34f9a2()
MSVCR71.DLL!7c34f9a2()
MSVCR71.DLL!7c350135()
MSVCR71.DLL!7c36a582()
eprise.dll!01d15fa7()
eprevent.dll!01e218f0()
eprevent.dll!01e2ec73()
eprise.dll!01ccf427()
wcc200.dll!01c0a6c5()
oleaut32.dll!77d04141()
[Managed to Native Transition]
RedCarpetCore.DLL!RedCarpet.Core.EpsInProcess.EpsClient.GetPage(string s = "/sysinfo") Line 318 + 0x1a bytes

Вы заметите, что dll переключается где-то во всем беспорядке.DLL с заглавными буквами в начале находится во временных файлах, а DLL в конце с заглавными буквами - та, которая находится в корзине.

1 Ответ

1 голос
/ 16 августа 2010

Когда он вызывает внешнюю программу через HelperGetPage (), эта программа затем также вызывает этот dll. У него есть путь к этой dll по адресу C: \ Source \ view \ Application \ Version \ core \ bin \ MyProgram.dll, и хотя он, похоже, находит там правильную dll (как в идентичной dll с тем же именем) , это на самом деле не правильная DLL. DLL в этом бин генерируется при компиляции этого проекта, но эта dll затем копируется в бин основного проекта при компиляции. Путь правильной библиотеки DLL: C: \ Source \ view \ Application \ Version \ application \ bin \ MyProgram.dll. Несмотря на то, что dll идентичны, он запускается из папки application \ bin, а не из папки core \ bin, так что это dll, к которому должна обращаться внешняя программа, чтобы не вызвать перепутывание dll.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...