Visual Studio 2015 не находит внешние.dll даже после копирования в папку bin, но только после копирования в папку c:\Windows\

Question

Я пытаюсь создать Web-проект в Visual Studio 2015, который ссылается на aC# .dll-проект "dotnetWrapper", который является оболочкой aC# для проекта C++ "managedDllWrapper", который включает в себя некоторые сторонние 64-битные собственные C++ .dll.

Упомянутые проекты и веб-проект работают на.Net Framework 4.6.1 и x64. VS2015 использует iis express 64 bit.

Все компилируется нормально.

Когда я запускаю локальный веб-сервер в VS2015 (нажимаю зеленую кнопку запуска), я получаю сообщение об ошибке, что "managedDllWrapper.dll" или одна из его зависимостей не может быть найдена:

Ошибка сервера в приложении '/'

Не удалось загрузить файл или сборку managedDllWrapper.DLL или одну из ее зависимостей. Указанный модуль не может быть найден.

Описание: во время выполнения текущего веб-запроса произошло необработанное исключение. Пожалуйста, просмотрите трассировку стека для получения дополнительной информации об ошибке и о том, где она возникла в коде.

Сведения об исключении: System.IO.FileNotFoundException: не удалось загрузить файл или сборку managedDllWrapper.DLL или одну из ее зависимостей. Указанный модуль не может быть найден.

Ошибка источника:

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

Трассировки стека:

[FileNotFoundException: не удалось загрузить файл или сборку managedDllWrapper.DLL или одну из их зависимостей. Указанный модуль не может быть найден.] System.Reflection.RuntimeAssembly._nLoad(имя_файла AssemblyName, строка stringBase, доказательство AssemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& ​​stackMark, IntPtr pPrivHostBinder, логическое throwOnFileNectionSecleNessleSecleNessalSecenseSecureSecureNectionSeclement) BooleNecureSecenseSecuritySound)

System.Reflection.

System.Reflection.RuntimeAssembly.InternalLoad (String assemblyString, Доказательства ассемблирования Security, StackCrawlMark& ​​stackMark, IntPtr pPrivHostBinder, Логическое значение для интроспекции) +108

System.Reflection.RuntimeAssembly.InternalLoad (строка String AssemblyString, Evidence AssemblySecurity, StackCrawlMark& ​​stackMark, Boolean forIntrospection) +25

System.Reflection.Assembly.Load (String assemblyString) +34 System.Web.Configuration.CompilationSection.LoadAssemblyHelper (String assemblyName, Boolean starDirective) +49

[ConfigurationErrorsException: не удалось загрузить файл или сборку managedDllWrapper.DLL или одну из их зависимостей. Указанный модуль не может быть найден.]

System.Web.Configuration.CompilationSection.LoadAssemblyHelper (String assemblyName, Boolean starDirective) +772

System.Web.Configuration.CompilationSection.LoadAllAssembliesFromAppDomainBinDirectory () +259

System.Web.Configuration.CompilationSection.LoadAssembly (AssemblyInfo ai) +163

System.Web.Compilation.<> C.b__143_0 (AssemblyInfo ai) +29

System.Linq.d__16'2.MoveNext () +293

System.Linq.d__66'1.MoveNext () +100

System.Linq.d__63'1.MoveNext () +73

System.Web.UI.Util.GetTypeFromAssemblies (IEnumerable сборок, String typeName, Boolean ignoreCase) +217

System.Web.Compilation.BuildManager.GetType (String typeName, Boolean throwOnError, Boolean ignoreCase) +266

System.Web.Configuration.HandlerFactoryCache.GetTypeWithAssert (тип String) +48

System.Web.Configuration.HandlerFactoryCache.GetHandlerType (String type) +17

System.Web.Configuration.HandlerFactoryCache..ctor (тип String) +25

System.Web.HttpApplication.GetFactory (тип String) +104

System.Web.MaterializeHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute () +262

System.Web.HttpApplication.ExecuteStep (шаг IExecutionStep, логический и завершен синхронно) +137

Информация о версии: Microsoft .NET Framework Версия:4.0.30319; ASP.NET версия:4.6.1055.0

Обратите внимание, что собственные dll (зависимости) находятся в папке bin веб-проекта (скопировано вручную).

Когда я копирую нативные библиотеки в свою папку C:\Windows\, ​​веб-приложение работает без сбоев. Каким-то образом путь поиска DLL в веб-приложении указывает только на папку C:\Windows\, ​​но он также должен искать в папке выполнения (bin) веб-приложения, верно?

Когда я делаю не веб-приложение, а тестовое приложение консоли C#, которое также включает в себя оболочку со всеми dll, копирование dll в папку bin test-app работает нормально, и приложение запускается. Только веб-приложение имеет эту проблему, чтобы не принимать DLL-файлы в папке bin.

Кроме того, когда я копирую dll в каталог C:\Windows\ и запускаю веб-приложение, а затем снова пытаюсь удалить dll, он говорит, что их нельзя удалить, потому что

потому что файл открыт в IIS Express Worker Process.

Так что, возможно, это проблема IIS, а не VS2015, но я не могу настроить свой IIS (или я не знаю, как). Я использую IIS Express, который поставляется с Visual Studio 2015.

Все мои исследования в Google и stackru привели к:

• скопировать dll в папку bin (пробовал, но не работает, как описано выше, работает только для консольного приложения C#, но не для веб-приложения).
• Ссылка dlls прямо в проекте (не представляется возможным:)

  "[..]. dll не может быть добавлено. Пожалуйста, убедитесь, что файл доступен, и что это допустимая сборка или COM-компонент."

• проверьте, все ли 64-битное, и ту же версию.Net (проверено, 64-битное,.Net 4.6.1. Также: оно отлично работает для консольного приложения, но не для веб-приложения).
• измените файл web.config, чтобы добавить дополнительные папки.dll. Но это тоже не помогло.

Я был бы рад, если бы мой веб-проект мог найти.dll в папке, отличной от C:\Windows\, ​​так как я сомневаюсь, что мне будет разрешено добавить 17 .dll в папку C:\Windows\ на MS azurewebsites когда я хочу опубликовать сайт. Тогда путь должен быть как-то внутри папок приложения.

Answer 1

Я не решил проблему один на один, но я успешно обошел проблему:

Переписав оболочку C#/ C++ с явным dllimport, я обратился к файлам dll напрямую с помощью пути. Затем зависимая DLL просто должна быть в той же папке, что и указанная DLL. Это работает также в веб-приложениях.