Я знаю, что опаздываю на вечеринку, но у меня была эта проблема сразу после того, как сегодня я снял последнюю версию x86/x64 (версия 1.0.88.0). Мой локальный IIS в VS2012 по умолчанию 32bit, и нет простого способа переключения на x64. Мой сервер работает на 64-разрядной версии.

В любом случае я установил пакет NuGet в проект DLL, и я получил эту ошибку. Что я должен был сделать, чтобы заставить его работать, мне пришлось установить его на основной сайт. Даже если он вообще не затрагивает классы SQLite.

Мое предположение заключается в том, что SQLite использует сборку ввода для определения загружаемой версии Interop.

У меня была эта проблема, потому что используемая dll была Sqlite в качестве зависимости (настроена в NuGet только с базовым пакетом Sqlite). Проект компилирует и копирует все dll файлы Sqlite, за исключением "SQLite.Interop.dll" (обе папки x86 и x64).

Решение было очень простым: просто добавьте пакет Sqlite.Core в качестве зависимости (с NuGet) к проекту, который вы создаете/выполняете, и dll-ы будут скопированы.

У меня была такая же проблема при использовании SQLite в проекте WPF, целью платформы которого было Any CPU. Я исправил его, выполнив следующие шаги:

• Откройте конструктор проекта в Visual Studio. Подробности о том, как это сделать, можно найти здесь.
• Перейдите на вкладку "Сборка".
• Отключите параметр prefer 32-bit.

В качестве альтернативы вы можете просто установить целевую платформу для платформы x86 или x64. Я думаю, эта проблема вызвана библиотекой System.Data.SQLite, использующей целевую платформу, чтобы получить местоположение файла SQLite.Interop.dll.

UPDATE:

Если проектор не может быть достигнут, просто откройте файл проекта (*.csproj) из текстового редактора и добавьте значение <Prefer32Bit>false</Prefer32Bit> в тег <PropertyGroup>...</PropertyGroup>.

Пример кода

<PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
    <ProjectGuid>[Set by Visual Studio]</ProjectGuid>
    <OutputType>Exe</OutputType>
    <AppDesignerFolder>Properties</AppDesignerFolder>
    <RootNamespace>[Set by Visual Studio]</RootNamespace>
    <AssemblyName>[Set by Visual Studio]</AssemblyName>
    <TargetFrameworkVersion>v4.5</TargetFrameworkVersion>
    <FileAlignment>[Set by Visual Studio]</FileAlignment>
    <!--Add the line below to your project file. Leave everything else untouched-->
    <Prefer32Bit>false</Prefer32Bit>
</PropertyGroup>

Вот как я исправил его в своем проекте.

Он работал, и когда коллега представил свои изменения, я получил сообщение "Невозможно загрузить исключение SQLite.Interop.dll DLL".

Развернув файл проекта .csproj, это было в версии NON-WORKING:

<ItemGroup>
     <Content Include="x64\SQLite.Interop.dll" />
     <Content Include="x86\SQLite.Interop.dll" />
</ItemGroup>

И это была версия WORKING:

<ItemGroup>
     <Content Include="x64\SQLite.Interop.dll">
          <CopyToOutputDirectory>Always</CopyToOutputDirectory>
      </Content>
      <Content Include="x86\SQLite.Interop.dll">
          <CopyToOutputDirectory>Always</CopyToOutputDirectory>
      </Content>
</ItemGroup>

Вернувшись назад, я не получил исключения. Файлы DLL были сброшены в соответствующие папки Debug\x64 (etc).

Когда вы перейдете в это состояние, попробуйте выполнить команду Rebuild-All. Если это исправляет проблему, у вас может быть такая же проблема.

Некоторые фон (мое понимание):

• SQLite имеет 1 управляемую сборку (System.Data.SQLite.dll) и несколько платформенные узлы (SQLite.Interop.dll). При установке SQLite с Nuget, Nuget добавит специфические для платформы сборки в ваш проект (в нескольких папках:\x86,\x64) и настраивает эти dll для "Копировать всегда".

• При загрузке управляемая сборка будет искать платформу специфических сборок внутри папок \x86 и\x64. Ты можешь видеть подробнее об этом здесь. Исключением является сборку, пытающуюся найти соответствующий (SQLite.Interop.dll) внутри эти папки (и сбои).

Мой сценарий:

У меня есть 2 проекта в моем решении; приложение WPF и библиотеку классов. Приложение WPF ссылается на библиотеку классов, а библиотека классов ссылается на SQLite (устанавливается через Nuget).

Проблема для меня заключалась в том, что когда я изменяю только приложение WPF, VS пытается выполнить частичную перестройку (понимая, что зависимая dll не изменилась). Где-то в этом процессе VS очищает содержимое папок \x86 и\x64 (сбрасывает SQLite.Interop.dll). Когда я делаю полное Rebuild-All, VS копирует папки и их содержимое правильно.

Мое решение:

Чтобы исправить это, в итоге я добавил процесс Post-Build с помощью xcopy, чтобы принудительно скопировать папки \x86 и\x64 из библиотеки классов в мой проект проекта \bin\WPF.

В качестве альтернативы вы можете делать более интересные вещи с помощью каталогов конфигурации/вывода сборки.

У меня была такая же проблема с Visual Studio Express 2013. Я пробовал несколько решений, упомянутых здесь и в других местах, безрезультатно. Я надеюсь, что это исправление поможет другим.

Я исправил его с помощью атрибута DeploymentItem моего тестового класса, который тестирует службу на основе SQLite.

Пример:

[TestClass]
[DeploymentItem(@"x86\SQLite.Interop.dll", "x86")] // this is the key
public class LocalStoreServiceTests
{

    [TestMethod]
    public void SomeTestThatWasFailing_DueToThisVeryIssue()
    {
         // ... test code here
    }
}

Это приводит к необходимости скопировать SQLite.Interop.dll в каталог x86 в соответствующей папке "TestResults".

Все зеленые. Все хорошо.

Обновление NuGet с Tools -> Extension and updates и переустановка SQLite.Core с помощью команды PM> Update-Package -reinstall System.Data.SQLite.Core исправлена ​​для меня.

Здесь действительно много ответов, но моя простая и понятная, без участия GAC.

Проблема заключалась в том, что исполняемому файлу нужна копия права SQLite.Interop.dll (x86 или x64) для доступа к нашей базе данных.

В большинстве архитектур есть слои, и в моем случае на уровне данных имеется требуемая DLL для SQLite Connection.

Итак, я просто поставил post build script в свое решение Data Layer Solution, и все сработало нормально.

TL; DR;

• Задайте все проекты вашего решения x86 или x64 в настройках сборки.

• Добавьте следующий проект Post-Build-Script в проект с помощью SQLite nuget Package:

  xcopy "$(TargetDir)x64" "$(SolutionDir)bin\Debug\" /y

Конечно, вам нужно изменить сборки script для Release Build и x86.

СТЛ; ДР;

Поместите ваш SQLite.Interop.dll рядом с файлом *.exe.

У меня была аналогичная проблема в решении нескольких проектов. SQLite.Interop.dll был необходим для одного из плагинов, распространяемых вместе с программным обеспечением с помощью ClickOnce.

Что касается отладки в visual studio, все работало нормально, но в развернутой версии отсутствовали папки x86/и x64/, содержащие эту DLL.

Решение о том, чтобы оно работало после развертывания с использованием ClickOnce, заключалось в том, чтобы создать в проекте запуска (также опубликованном) эти две вложенные папки, скопировать в них библиотеки DLL и установить их как Content Copy Always.

Таким образом, средство публикации ClickOnce автоматически включает эти файлы и папки в манифест и развертывает с ними программное обеспечение.

Установленная по умолчанию версия SQLite от NuGet для многоадресной архитектуры (x86, x64) демонстрирует описанное вами поведение. Если вы хотите загрузить правильную версию для реальной архитектуры, которую среда выполнения .NET выбрала для запуска вашего приложения на вашем компьютере, вы можете дать загрузчику DLL подсказку о том, где найти нужную библиотеку следующим образом:

Добавьте объявление для вызова функции kernel32.dll в SetDLLDirectory() перед вашей программой. Main():

    [System.Runtime.InteropServices.DllImport("kernel32.dll", CharSet = System.Runtime.InteropServices.CharSet.Unicode, SetLastError = true)]
    [return: System.Runtime.InteropServices.MarshalAs(System.Runtime.InteropServices.UnmanagedType.Bool)]
    static extern bool SetDllDirectory(string lpPathName);

Затем используйте свой собственный метод для определения правильного подкаталога, чтобы найти версию, специфичную для архитектуры SQLite.Interop.dll. Я использую следующий код:

    [STAThread]
    static void Main()
    {
        int wsize = IntPtr.Size;
        string libdir = (wsize == 4)?"x86":"x64";
        string appPath = System.IO.Path.GetDirectoryName(Application.ExecutablePath);
        SetDllDirectory(System.IO.Path.Combine(appPath, libdir));

даже если это старый пост, я хотел бы поделиться решением, которое я нашел здесь: http://system.data.sqlite.org/index.html/info/54e52d4c6f

Если вы не хотите читать всю проблему, решение должно скопировать файл "msvcr100.dll" (который можно найти в каталоге Windows\System32) по тому же пути, что и SQLite.Interop.dll.

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

НТН, Formentz

Я начал использовать Costura.Fody для сборки пакетов (.net) и вставлять и предварительно загружать собственные DLL. Это также помогает позже, с распространением, поскольку вы можете отправить один файл.

• Установите Костуру Фоди из Нугета.

• В проекте С# создайте папку с именем costrua32. Там добавьте любые родные dll, которые вы загружаете С#.

• Как только вы добавили их в эту папку. Нажмите на окно свойств и измените действие сборки на "Встроенный ресурс"

• Наконец, вам нужно изменить XML файл FodyWeavers.xml следующим образом. Здесь я сначала определяю загрузку sql dll. (обратите внимание, что вы отбрасываете .dll)

  Weavers
   Costura
    PreloadOrder
     SQLite.Interop
     tbb_debug
     tbb
    /PreloadOrder>
   /Costura
  /Weavers
  

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

Как говорится в SQLite wiki, развертывание вашего приложения должно быть:

Итак, вам нужно следовать правилам. Найдите dll, который соответствует вашей целевой платформе, и поместите ее в папку, описанную на картинке. Dll можно найти в файле YourSolution/packages/System.Data.SQLite.Core.% Version%/.

У меня были проблемы с развертыванием приложений, поэтому я просто добавил в свой проект правильный SQLite.Interop.dll, добавленную папку x86 в AppplicationFolder в проект установки и добавленные ссылки на файлы для dll.

Я не знаю, почему это еще не было включено, но я должен был провести исследование и найти это для себя, поэтому, надеюсь, кто-то найдет этот ответ и спасет проблему. Это было для приложения WPF. Он отлично работал на моем блоке Dev, но не работал на компьютере, где я его копировал, и получил ошибку Unable to load DLL 'SQLite.Interop.dll'. Я портировал все связанные с ним каталоги и файлы непосредственно из папки "Отладка" на этот другой компьютер, когда получил ту же ошибку, что и OP, когда я ее запускал. Моя папка "bin" , в которой были мои DLL, была скопирована в "Debug\bin", и все они были включены вместе с моими файлами приложений, когда я копировал их на другой компьютер, используя этот путь, поэтому он не пропускал никаких файлов.

Что я видел в других ответах, которые не применялись:

• Я не использовал пакет NuGet или вам нужно создавать папки x86 или x64, которые, кажется, создают пакет NuGet. Мои DLL (System.Data.SQLite и SQLite.Interop.dll вместе с System.Data.SQLite.config) находятся в папке "bin" в моем проекте и скопированы вручную (создайте папку "bin" в Solution Explorer в VS, вставьте DLL в эту папку в Проводнике Windows, используйте "Добавить > Существующий элемент", чтобы вносить файлы в папку/проект VS). Затем я ссылаюсь на них как на ссылочные сборки в моем проекте, используя это местоположение ( "Ссылки" > "Добавить ссылку" и перейдите к одному, ополаскивать, повторять для остальных). Это гарантирует, что мой проект точно знает, где они находятся.
• Мне не нужно ссылаться на любой DLL файл SQLite в моем app.config или даже на мой файл MyProject.csproj.
• Мне даже не нужно было указывать конкретный процессор! Моя сборка проекта для "Any CPU", хотя я имею только смешанные или 64-разрядные библиотеки DLL и буду работать только в Windows 7+, которые являются 64-разрядными операционными системами. (только для x86-единственных/32-разрядных DLL)
• Я уже указывал их как "Content" и "copy if newer" для этих DLL, когда я испытал ошибку OP.

Я нашел это, от https://system.data.sqlite.org/index.html/doc/trunk/www/faq.wiki#q20:

(11) Почему я пытаюсь запустить приложение DllNotFoundException (для sqlite3.dll или SQLite.Interop.dll)?

Либо названная библиотека динамических ссылок (DLL) не может быть расположена, либо она не может быть загружена из-за отсутствия зависимостей. Убедитесь, что указанная динамическая библиотека ссылок находится в каталоге приложения или в каталоге по системе PATH и повторите попытку. Кроме того, убедитесь, что необходимая распространяемая среда исполнения Visual С++ установлена ​​, если вы не используете динамическую библиотеку ссылок, которая была статически связана с ней.

Акцент на эту выделенную часть внутри абзаца. Целевой компьютер был свежим и не загружал программ, кроме .NET 4.0. Как только я установил С++, он смог выполнить команды SQLite. Это должно было быть одним из первых часто задаваемых вопросов и частью предпосылок, но он был похоронен в # 11. Мой компьютер разработки уже загрузил его, потому что он пришел с Visual Studio, так что почему он работал, там.

Скачать:
Visual С++, распространяемый для Visual Studio 2015:
https://www.microsoft.com/en-us/download/details.aspx?id=48145

Обновление 3 (накопительное обновление):
https://www.microsoft.com/en-us/download/details.aspx?id=53587

Я долгое время боролся с этим, и иногда я обнаружил, что установка теста неверна. Смотреть это изображение:

Я просто сниму настройку теста, и проблема исчезнет. В противном случае произойдет исключение. Надеюсь, это поможет кому-то. Не уверен, что это основная причина.

Если вы загрузите правильный двоичный файл для SQLite, затем скопируйте SQLite.Interop.dll в папку "Отпуск" или "Отладка" в соответствии с вашим вариантом сборки проекта.

Скопировать файлы SQLite.Interop.dll для x86 и x64 в папку отладки. эти файлы должны копироваться в папки "x86" и "x64" в папке отладки.

Перед установкой установите целевую платформу для x86 или x64 (а не любой CPU): Project- > Properties- > Build- > Платформа в Visual Studio.

У меня такая же проблема. Однако, наконец, я могу это исправить. В настоящее время я использую Visual Studio 2013 Community Edition. Я просто использую Добавить- > Существующий элемент... и просматриваю, где находятся файлы SQLite.Data.SQLite(в моем случае это "C:\Program Files (x86)\System.Data.SQLite\2013\бин). Не забудьте изменить тип того, что вы будете включать в Файлы сборки (*.dll; *.pdb). Выберите" SQLite.Interop.dll" в этой папке. Оттуда я могу продолжать без каких-либо проблем. Желаю вам всем удачи. ^ _ ^ Постскриптум Я создаю приложение для веб-форм. Я еще не пробовал в приложении для оконной формы или других приложений.

Короче

Чтобы заставить это работать и с NCrunch, мне пришлось добавить версии Interop.dll, поставляемые с пакетом NuGet, в виде дополнительных файлов в конфигурации NCrunch.

Мой случай

У меня было решение С# с одним проектом напрямую в зависимости от SQLite (вспомогательная библиотека) и проекта unit test, который использовал эту вспомогательную библиотеку. Я установил System.Data.SQLite.Core версии 1.0.97.0 как пакет NuGet.

В моем случае обходной путь предоставленный Marin, он работал в Visual Studio и в CI. Однако это все равно приведет к ошибкам в NCrunch.

В конфигурации NCrunch я добавил следующий путь в разделе "Дополнительные файлы для включения" в настройках проектов unit test:

..\packages\System.Data.SQLite.Core.1.0.97.0\build\net45\**.dll

Я столкнулся с этой проблемой, в решении с веб-проектом WebAPI/MVC5 и проектом тестирования функций, которое оборачивается одним и тем же проектом доступа к данным (или "Core" ). Я, как и многие другие здесь, использую копию, загруженную через NuGet в Visual Studio 2013.

То, что я сделал, было в Visual Studio, добавило папку решений x86 и x64 в тестер функций и веб-проекты. Затем я сделал Right Click | Add Existing Item... и добавил соответствующую библиотеку SQLite.interop.dll из ..\SolutionFolder\packages\System.Data.SQLite.Core.1.0.94.0\build\net451\[appropriate architecture] для каждой из этих папок. Затем я сделал a Right Click | Properties и установил Copy to Output Directory в Always Copy. В следующий раз, когда мне нужно было запустить мои функциональные тесты, тесты прошли успешно.

У меня была эта проблема, потому что Visual С++ 2010 распространялся без установки на моем компьютере. Если вы еще не установили распространяемый дистрибутив Visual С++ 2010 Download и установите это (проверьте x86 или 64 dll).

Для справки для любого, кто смотрит на этот вопрос:

Если вы используете пакет nuget, он устанавливает правило сборки, которое выполняет для вас копирование. (см. в разделе System.Data.SQLite.Core.1.0.94.0\build - или любую другую версию ядра, которую вы устанавливаете).

Установщик nuget автоматически добавляет правило в файл проекта.

Это все еще не устраняет проблему с тестовым случаем. Подход DeploymentItem (https://stackoverflow.com/questions/13028069/unable-to-load-dll-sqlite-interop-dll) - единственное, что, кажется, работает там.

Вы также можете получить эту ошибку, если пытаетесь запустить 32-разрядную dll в 64-битном проекте.

Я получил это, когда я разместил тот же файл (SQLite.Interop.dll в 32-разрядной версии) в папке x86 и x64.

Я работаю над простым консольным приложением, чтобы добавить некоторые тестовые данные в базу данных SQLite и получал эту ошибку. Конфигурация для проекта - "Любой процессор". Я исправил его, скопировав файл SQLite.Interop.dll в папку bin\debug. Лучшим способом было бы использовать метод @Wil, но как вы определяете это для конфигурации "Любой процессор"?

Я не знаю, был ли это хороший ответ, но я смог решить эту проблему, выполнив мое приложение под AppDomain с идентификатором "Local System".

Может ли быть конкуренция за сборку? Проверьте, есть ли другое приложение с блокировкой файлов в DLL.

Если это причина, для обнаружения нарушительной программы должно быть легко использовать инструмент Sysinternal Process Explorer.

НТН, Глина

Мое приложение - это веб-приложение (ASP.NET MVC), и мне пришлось изменить пул приложений для LocalSystem вместо ApplicationPoolIdentity. Для этого:

• Откройте диспетчер IIS
• Найдите пул приложений, на котором работает ваш сайт.
• Нажмите "Дополнительные настройки" из действий
• Измените идентификатор на LocalSystem

Я понятия не имею, почему это устраняет проблему.

Развернувшись на ответ Kugels, который работал на меня (VS2015 Enterprise), используя SQLite из dll, пакет Nuget можно удалить из основного проекта после сборки и тестирования:

1.Установите пакет Nuget в основной проект.

Install-Package System.Data.SQLite

2.Build Application и проверьте, работает ли ваше Sqlite-соединение:

select * from sqlite_master

3.Установить пакет Nuget из основной сборки.

UnInstall-Package System.Data.SQLite

4. Удалите ссылки dll для SQLite и EntityFramework:

System.Data.SQLite
System.Data.SQLite.EF6
System.Data.SQLite.Linq

5. Удалите ссылки Xml из основного файла проекта "packages.config".

Это сработало для меня и очистило мой проект.

Скопируйте файл SQLite.Interop.dll в каталог проекта.

src\
  project\
      bin\   <-- Past in bin
         x64\
           SQLite.Interop.dll <-- Copy this if 64
         x86\
           SQLite.Interop.dll <-- Copy this if 32

Шахта тоже не работала для модульных тестов, и по какой-то причине ответ Майкла Бромли, связанный с атрибутом DeploymentItem, не работал. Тем не менее, я работал с настройками теста. В VS2013 добавьте новый элемент в свое решение и найдите "настройки" и выберите файл шаблона "Настройки теста". Назовите его "SqliteUnitTests" или что-то еще и откройте его. Выберите "Развертывание" вправо и добавьте каталог/файл. Добавьте пути/каталоги в файл SQLite.Interop.dll. Для меня я добавил два пути: по одному для Project\bin\Debug\x64 и Console\bin\Debug\x86. Вы также можете добавить свой файл Sqlite в зависимости от того, как вы ожидаете, что ваш unit test/solution получит доступ к файлу.

Итак, моя проблема заключалась в том, что SQLite пытался загрузить во время разработки WPF. Поскольку я заботился только о среде x86, я задал предпочтение CPU этому и скопировал SQLite.Interop.dll из пакета Nuget в корневую директорию решения. Перезагрузили решение, и все проблемы исчезли. Итак, если у вас возникли проблемы с дизайном, поместите библиотеку в корневой каталог вашего решения.

Кроме того, во время выполнения я получал аналогичную проблему, поэтому мне пришлось поместить копию проекта SQLite.Interop.dll в свой проект и установить его для копирования, если он будет более новым в свойствах. Похоже, что предоставленные x86 и x64 папки полностью бесполезны. Требуется дальнейшее исследование, но в целом... просто проще вручную ссылаться на SQLite в вашем проекте, чем на использование пакета Nuget.

Кроме того, в официальном FAQ указывается следующее:

(20) Когда проект System.Data.SQLite компилируется и запускается из внутри Visual Studio, почему я получаю исключение DllNotFoundException или BadImageFormatException (для "sqlite3.dll" или "SQLite.Interop.dll" ) при попытке запуска или отладки приложения?

При компиляции и запуске решения из Visual Studio, которое использует проект System.Data.SQLite(включая тестовый проект), он очень важно выбрать правильную конфигурацию сборки и Платформа. Во-первых, управляемые приложения отлаживаются внутри Visual Studio не может использовать сборку смешанного режима (т.е. Потому что она всегда скомпилирован в каталог вывода сборки для конкретной платформы). Это необходимо правильно поддерживать двоичные файлы для нескольких платформ используя те же исходные файлы проекта. Поэтому только Конфигурации сборки "DebugNativeOnly" или "ReleaseNativeOnly" должны выбирается при запуске управляемого приложения изнутри Visual Студия, которая опирается на сборку System.Data.SQLite. Эти сборки конфигурации содержат пользовательский шаг после сборки, который копирует требуемая собственная сборка к управляемому выходному каталогу (то есть к разрешить запуск управляемых двоичных файлов на месте). Однако это шаг после сборки будет выполняться только в том случае, если выбранная платформа соответствует операционной системе (например, "Win32" для 32-разрядной Windows и "x64" для 64-битной Windows). Таким образом, дважды проверьте выбранную платформу сборки на операционную систему перед попыткой запустить управляемый проект в решении.

https://system.data.sqlite.org/index.html/doc/trunk/www/faq.wiki#q20

Я хотел опубликовать здесь из-за сложности этой проблемы. Моим решением было вернуться к .Net 4.0. Я тестировал в течение 3 дней и не смог получить System.Data.SQLite.Core.1.0.98.0 для работы с .Net 4.5 или .Net 4.5.1.

Тестирование было исчерпывающим на 3 компьютерах, 2 серверах на одном компьютере. Я не смог добраться до источника проблемы. Я пробовал редактировать файл .vsproj. Я добавил SQLite.interop.dll во все папки практически. Я применил пакет ко всем папкам GAC и удалил и повторно применил индивидуально. Со временем удалено.

У меня есть System.Data.SQLite.Core.1.0.98.0, работающий с .Net 4.0. Я намерен продолжать попытки миграции, но я думаю, что сначала приступим к новому проекту и посмотрю, смогу ли я заставить его работать таким образом. Первоначально это было веб-приложение .Net 3.5, и в моих путешествиях я нашел много информации, все еще ссылающейся на эту структуру.

Я сам столкнулся с этой проблемой, но это оказалось другой причиной:

System.DllNotFoundException was caught 
Unable to load DLL 'SQLite.Interop.dll': Access is denied. 

В этом случае код был (косвенно) вызван из веб-сервиса, размещенного IIS (настроенного для сборки x86). Наконец, я отследил его до пула приложений в IIS: первоначально я использовал "ASP.NET V4.0 Integrated" (что привело к этой ошибке), но когда я изменил его на "DefaultAppPool" , проблема исчезла.

(Уф!)