Развертывание приложения Windows 8 Metro, использующего SQLite - программирование

Развертывание приложения Windows 8 Metro, использующего SQLite

Фон

Мы используем System Center 2012 для развертывания приложения в стиле Metro в стиле Windows 8 на планшетах Samsung в области Windows 8 Enterprise x64. Сланцы соединяются с доменом и поддерживают постоянное соединение DirectAccess, позволяя System Center подталкивать приложения и обновления к устройствам.

Мы должны развернуть наше приложение на потенциально сотни устройств в поле, поэтому мы пошли по пути System Center. Сертификат подписания кода устанавливается на каждом устройстве с использованием групповой политики. Чтобы развернуть приложение, вы просто предоставляете выход пакета и указываете коллекцию устройств для его установки. Приложение просто появляется на устройстве через несколько минут.

Проблема, с которой мы сталкиваемся, заключается в том, что когда System Center развертывает наше приложение, зависимость SQLite теряется, и ни один из наших данных не работает.

О нашем проекте

Наше приложение - это приложение WinJS, использующее SQLite в качестве бэкэнд. Однако весь наш код доступа к данным находится в проекте С# WinMD, который ссылается на проект WinJS. Мы используем библиотеку sqlite-net, чтобы поговорить с SQLite - мы включили источник этого в наш проект С#.

В Visual Studio мы установили расширение SQLite для Windows Runtime, как описано в статье Тима Хейера. Приложение Metro ссылается на это.

Тестирование с использованием других методов развертывания

Доступ к данным SQLite из приложения отлично работает при его отладке или запуске локально - как в Debug/Release, так и в x86/x64.

Процесс упаковки приложений предоставляет PowerShell script, который можно использовать для установки приложения и лицензии разработчика, если это необходимо. При установке нашего приложения с помощью PowerShell script доступ к данным SQLite также отлично работает. Проверено это путем упаковки и установки версий Debug/Release и x86/x64 приложения.

Устранение неполадок

Когда приложение сначала пытается использовать SQLite, мы видим, что исключение не может найти sqlite3.dll.

Мы пробовали/проверяли следующее:

  • Подтвердите, что мы развертываем сборку Release/x64
  • Изучите приложение в WinRAR и убедитесь, что он содержит sqlite3.dll
  • Ссылка на расширение SQLite для Windows Runtime из проекта С# вместо проекта WinJS
  • Также ссылается на время выполнения С++, это вызвало отказ System Center при развертывании приложения. Не знаю, почему еще, но изучая его.

UPDATE Проблема в том, что System Center испытывает проблемы с развертыванием зависимости библиотеки Visual С++ Runtime, необходимой библиотеке SQLite. К сожалению, это уже не вопрос программирования. Мы получаем некоторую помощь в этом, и я отправлю исправление.

4b9b3361

Ответ 1

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

Рекомендация

Когда вы ссылаетесь на пакет Runtime Visual С++ из нашего проекта Metro, System Center не может развернуть приложение на устройства, потому что есть проблема с развертыванием правильной версии зависимости для соответствующей архитектуры и создания аромата.

Наши машины разработки Visual Studio 2012 (и упаковка проекта для развертывания) используют более новую версию Visual С++ Runtime (50727), чем то, что доступно при новой установке Windows 8 (50712).

Работала с командой System Center и подтвердила, что это была ошибка в версии, которую мы использовали, и уже была рассмотрена в будущих сборках. Мы будем работать над обновлением среды, но это займет пару недель.

Обход

Я подтвердил и протестировал следующее обходное решение:

  • Удалить ссылку на пакет Runtime Microsoft Visual С++ из проекта Metro
  • Установите x64 версию Visual С++ Redistributable для Visual Studio 2012 - http://www.microsoft.com/en-us/download/details.aspx?id=3
  • Развертывание приложения

Работает как шарм, потому что правильная версия зависимости уже существует. Очевидно, что это не долгосрочное решение, если мы хотим также нацелиться на x86 и ARM, но мы получим этот горб.