Не могу загрузить SQLite с перерывами - PullRequest
Новая
       3

Не могу загрузить SQLite с перерывами

1 голос
/ 12 февраля 2012

У меня есть приложение .NET 4, которое состоит из приложения и двух библиотек классов. Все используют ссылку на System.Data.SQLite. Я использую версию SQLite для x86, и все мои сборки установлены на x86.

На некоторых машинах, когда я пытаюсь что-то сделать в приложении, которое использует SQLite, я получаю необработанное исключение:

Не удалось загрузить файл или сборку 'System.Data.SQLite, версия = 1.0.79.0, Культура = нейтральная, PublicKeyToken = db937bc2d44ff139 'или одна из ее зависимостей. Была предпринята попытка загрузить программу с неверным формат.

Я в этом разбираюсь, так как я пробовал библиотеки SQLite .NET 3.5 и .NET 4 в x86 и x64, и я получаю ту же ошибку. Я тестировал на четырех машинах. Следующие отлично работают:

  • Win7 Ultimate x64
  • Win7 Pro x64
  • Server 2008 x64

Следующее бросить исключение:

  • Win7 Ultimate x64 (компьютер пользователя)
  • WinXP внутри XP Mode на Win7 Ultimate x64, который работает

Если бы это была проблема с архитектурой, я бы ожидал, что XP Mode, работающий на работающей Win7 x64, также будет работать, но это не так. Кроме того, ни один из test.exe файлов includede с пакетом SQLite не работает внутри VMWare, что заставляет меня думать, что чего-то не хватает.

Я запустил FUSLOGVW на машине в режиме XP, и это запись для System.Data.SQLite: 

The operation was successful.
Bind result: hr = 0x0. The operation completed successfully.

Assembly manager loaded from:  c:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\clr.dll
Running under executable  C:\Documents and Settings\XPMUser\Desktop\Release\ChickenPing.exe
--- A detailed error log follows. 

=== Pre-bind state information ===
LOG: User = VIRTUALXP-92688\XPMUser
LOG: DisplayName = System.Data.SQLite, Version=1.0.79.0, Culture=neutral, PublicKeyToken=db937bc2d44ff139
 (Fully-specified)
LOG: Appbase = file:///C:/Documents and Settings/XPMUser/Desktop/Release/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = ChickenPing.exe
Calling assembly : ChickenPing.DAL, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Documents and Settings\XPMUser\Desktop\Release\ChickenPing.exe.Config
LOG: Using host configuration file: 
LOG: Using machine configuration file from c:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Post-policy reference: System.Data.SQLite, Version=1.0.79.0, Culture=neutral, PublicKeyToken=db937bc2d44ff139
LOG: GAC Lookup was unsuccessful.
LOG: Attempting download of new URL file:///C:/Documents and Settings/XPMUser/Desktop/Release/System.Data.SQLite.DLL.
LOG: Assembly download was successful. Attempting setup of file: C:\Documents and Settings\XPMUser\Desktop\Release\System.Data.SQLite.dll
LOG: Entering run-from-source setup phase.
LOG: Assembly Name is: System.Data.SQLite, Version=1.0.79.0, Culture=neutral, PublicKeyToken=db937bc2d44ff139
LOG: Binding succeeds. Returns assembly from C:\Documents and Settings\XPMUser\Desktop\Release\System.Data.SQLite.dll.
LOG: Assembly is loaded in default load context.

Что указывает на успех, но необработанное исключение все еще возникает?

Ответы [ 3 ]

2 голосов
/ 13 февраля 2012

Это было несколько неясно отследить. Оказывается, требуется распространяемое время выполнения VC ++ 2010. Насколько я знаю, System.Data.SQLite никогда не имел такой зависимости, или, по крайней мере, я никогда не знал об этом.

2 голосов
/ 19 мая 2012

Как своего рода дополнение к принятому в настоящее время ответу: они фактически создают статически связанные двоичные файлы, теперь с перенаправлением VC, скомпилированным прямо в DLL, которая не имеет этой зависимости (потому что она статически связана непосредственно с DLL).

1 голос
/ 12 февраля 2012

Ваше приложение скомпилировано явно для x86 ?

Если ваше приложение скомпилировано для обеих архитектур, то оно будет использовать x64 часть на x64 машине и вызовет x86 dll ->, что поднять свое исключение ...

...