Страницы ASP.net с 64-битной сборкой в ​​Visual Studio 2010

Question

Короткая версия :

Я использую 64-битную dll (system.data.sqlite) в приложении Asp.net MVC в VS 2010. Приложение работает и отлаживается нормально,но все страницы aspx и ascx показывают ошибки при редактировании в Visual Studio 2010 и intellisense не работает.

Это ошибка регрессии VS2010 .У кого-нибудь есть работа вокруг?

(ИЛИ)

Кто-нибудь знает о бесплатной, надежной, готовой к работе встраиваемой базе данных, которая не вызывает проблем с 32/64 битами?Подробности

Очевидно, это работало в Visual Studio 2008, а это известная ошибка регрессии в Visual Studio 2010 в течение нескольких месяцев .Я не хочу возвращаться к VS 2008, и я не хочу отлаживать в 32-битном режиме.

У меня есть веб-приложение, которое нужно отлаживать и развертывать в 64-битном режиме, потому что оно использует некоторые неуправляемые 64-битные dll, такие как system.data.sqlite.Кроме того, я предпочитаю отладку в 64-битном режиме, потому что она позволяет нам тестировать некоторые случаи использования памяти.

После долгих хлопот Asp.net развернется и будет работать нормально.Однако все страницы aspx и ascx показывают ошибки, и intellisense не работает при их редактировании в Visual Studio 2010. Очевидно, это работало в Visual Studio 2008, и это известная проблема в Visual Studio 2010 в течение нескольких месяцев ,Я не хочу возвращаться к VS 2008.

Была работа вокруг , опубликованная на SO здесь , но она не работала в моих тестах, ограничивает отладку до 32-битного режима, а такжечувствует себя немного хакером (я думаю, что это работает только для веб-сайтов в стиле VS Express).Кто-нибудь сделал эту работу в веб-приложении или лучше обходил?

Для тех, кто интересуется, Visual Studio 2010 имеет две другие проблемы с 64-битными библиотеками, которые мне удалось обойти.

Проблема 1 - Cassini: Cassini может отлаживать только в 32-битном режиме

Решение 1 - CassiniDev или Localhost: Отладка с использованием localhost или compile CassiniDev (открытый вариант cassini) в 64-битном режиме.Мне нравится простота нулевой конфигурации отладки нового веб-приложения с помощью cassini, поэтому я использовал CassiniDev.Вы просто вставляете dll в C: \ Program Files (x86) \ Common Files \ microsoft shared \ DevServer \ 10.0 и это работает (я рекомендовал сделать резервную копию версии Cassini, которую вы будете переписывать).

Проблема 2 - MSTest: По умолчанию модульные тесты запускаются с MSTest не удается загрузить 64-битные DLL .

Решение 2 - AnyCPU &64-битный хост-процесс Инструкции здесь , установите local.testsettings в AnyCPU и 64-битный хост-процесс

Я начинаю думать, что вся установка слишком хакерская, и я нахожусь нана грани отказа и реструктуризации моего приложения, чтобы не использовать 64-битную DLL.Я также очень разочарован тем, что Visual Studio 2010 вызвал все эти проблемы.Может кто-нибудь заставить MS исправить созданную ими ошибку регрессии?

Или

Мы хотим использовать встраиваемую базу данных.Кто-нибудь знает о бесплатной, надежной, готовой к работе встраиваемой базе данных, которая не вызывает проблемы 32/64 бит?

Answer 1

У меня была x64 dll в каталоге bin проекта веб-сайта.Веб-сайт будет работать в пуле 64-разрядных приложений IIS, но он не будет работать в Cassini.Visual Studio также выдает ошибки (неправильный формат) каждый раз, когда я открывал страницу, из-за которой среда IDE мучительно медленно работала.

Проекты веб-сайтов (в отличие от проектов веб-приложений) динамически компилируются.Однако Visual Studio будет использовать только 32-битный aspnet_compiler.Это верно при использовании инспектора страниц или при использовании пункта меню «Компилировать веб-сайт».Я не могу найти способ изменить это поведение.IIS на 64-разрядной версии будет использовать 64-разрядную версию aspnet_compiler для динамической компиляции, и все отлично работает.

Единственное работоспособное решение, позволяющее Visual Studio остановить выброс ошибок, - это удалить dll x64 из каталога bin и динамически загрузить его во время выполнения, как указано здесь .

Это можно сделать с помощью assemblyBinding и probing в файле web.config.privatePath должен быть подкаталогом вашего каталога приложений, а не за его пределами.

<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <probing privatePath="dlllocation" />
    </assemblyBinding>
  </runtime>
<configuration>

Вам также необходимо добавить код в любой файл aspx ДО директивы @Page

<%@ Assembly Name="fileNameWithoutExtension" %>
<%@ Import Namespace="NameSpace" %>

Answer 2

Боюсь, что не может быть обходного пути, который позволяет 64-битной отладке Asp.net с 64-битной неуправляемой зависимостью dll, которая не сломает редактор веб-форм.Я думаю, что команда VS Asp.net считает 64-битные зависимости крайним случаем и исправит редактор веб-форм, когда у них будет время ... будьте осторожны.

Вы всегда можете отладить в 32-битном режиме, а затем развернуть 64-битнуюнадлежащее тестирование.

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