Ошибка загрузки сторонней библиотеки dll из приложения Asp.Net - PullRequest
0 голосов
/ 19 февраля 2011

ситуация довольно сложная (и мой английский очень простой), но давайте попробуем объяснить:

Я занимаюсь разработкой веб-службы Asp.net, вызывающей метод из внешней библиотеки DLL.

Эта внешняя библиотека DLL вызывает некоторый метод из других библиотек .net.

Итак, мы имеем:

Asp.net WS ----> External.dll ----> other.NEt.Dll(---> other .netdll)

Вы должны знать, что внешняя библиотека DLL использует путь (заданный методом инициализации)чтобы решить его внутреннюю ссылку.

В заключение у меня есть веб-приложение с добавленной ссылкой на мой файл External.dll и полностью доверенный путь (c: \ EXTERNAL), полный всех .net dll, необходимых для внешнего.dll.

Оглядываясь вокруг, я нашел этот код для добавления в application_START:

Dim path As String = String.Concat(System.Environment.GetEnvironmentVariable("PATH"), ";", "c:\EXTERNAL)
    System.Environment.SetEnvironmentVariable("PATH", path, EnvironmentVariableTarget.Machine)

это добавило мой c: \ EXTERNAL в глобальную среду PATH.

Сэта конфигурация запускается с сервера разработки Visual Studio, я не получаю ошибок, и все работает правильно.

Когда я публикую приложение на моем локальном сервере IIS, оно выдает различные ошибки: Сначала результат - что-тоg like:

Failure reading <Myobject> control of <(static)> type
Unable to create <myobject> object (<C:\(WRONGPATH)\needed.net.dll> assembly)

Чтобы решить эту проблему, я попытался добавить необходимые .net dll в / bin моего приложения в wwwroot, но в результате получилось что-то вроде:

Failure reading <MyType> control of <Myobject> type
Error returned by .NET Framework: 
System.ArgumentException: Un oggetto di tipo 'ComNet.BaseControl.LoginDisplayLayout' non può essere convertito nel tipo 'ComNet.BaseControl.LoginDisplayLayout'.
   in System.RuntimeType.CheckValue(Object value, Binder binder, CultureInfo culture, BindingFlags invokeAttr)
   in System.Reflection.MethodBase.CheckArguments(Object[] parameters, Binder binder, BindingFlags invokeAttr, CultureInfo culture, Signature sig)
   in System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks)
   in System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   in System.Reflection.RuntimePropertyInfo.SetValue(Object obj, Object value, BindingFlags invokeAttr, Binder binder, Object[] index, CultureInfo culture)
   in System.Reflection.RuntimePropertyInfo.SetValue(Object obj, Object value, Object[] index)
   in CDotNetType.bSetProperty(CDotNetType* , Object gcrObj, SByte* pszNom, CSLevel* pclPile, Int32 nDimension, Int32* pnTabDimension, STOperationDotNet* pstOperation)

на этот раз похоже, что он загружает ту же самую DLL, но из другого места, вызывая конфликты.

Теперь это все.Мне сложно объяснить этот дьявольский ад, но в основном я хотел бы повторить то, что происходит, когда приложение хорошо работает на сервере разработки Visual Studio.Я также читал, что IIS не разрешает добавленную PATH без перезагрузки, поэтому я попытался добавить c: \ external вручную в PATH и перезагрузиться, но появляются те же ошибки.

Спасибо за чтение, я надеюсь, что кто-то может помочь.

(извините за грамматические или орфографические ошибки! (Я итальянец ..))

Никола

1 Ответ

1 голос
/ 20 февраля 2011

Попробуйте сбросить все внешние DLL-библиотеки .NET в каталог bin вашего сайта.

Когда вы добавляете ссылку в Visual Studio в отдельную библиотеку или проект, она обычно копирует библиотеки DLL из этого проекта в каталог BIN вашего веб-сайта, но не всегда захватывает файлы DLL, от которых зависит этот проект.

Так что если: yourwebsite.dll -> helper.dll -> helperComponent.dll -> widget.dll (где -> ссылка), при сборке только helper.dll попадает в каталог bin рядом с yourwebsite.dll. Как правило, вы хотите, чтобы все они были в одном месте. Тогда вам не нужно беспокоиться о своем пути или о чем-то подобном.

В качестве альтернативы, если все эти сборки имеют строгое имя, вы можете добавить их в глобальный кеш сборок, используя gacutil, и ссылаться на них по их идентификатору вместо файла.

Это было довольно хорошее прочтение об организации проекта. Раздел «Копировать локальный» играет на этом. Вы можете настроить xcopy в своих событиях после сборки, чтобы поместить ссылки 2-го и 3-го уровня в каталог bin под файлом решения.

http://www.simple -talk.com / DotNet / .net-рамка / секционирования-ваш-код база-сквозные .net-сборка-и-визуальная студия-проекты /

...