NGEN'd сборки не загружаются

Я пытаюсь измерить влияние производительности NGENing моих сборок по сравнению с нет, но я не могу заставить свой исполняемый файл загружать сборки NGEN. Я выполнил следующее из командной строки VS2010:

ngen install MyApp.exe

Это завершено без каких-либо проблем, и я подтвердил, что все мои сборки зависимостей были созданы в каталоге C:\Windows\assembly\NativeImages_v4.0.30319_32\MyCompanyName #.

Затем я запустил свое приложение и посмотрел на Process Explorer, он загружал все мои сборки из каталога локальных двоичных файлов, а не загружал файлы *.ni.dll из папки NativeImages_x. Я зарегистрировал привязки с помощью fuslogvw. Вот пример записи в журнале:

*** Assembly Binder Log Entry (6/29/2011 @ 10:14:04 AM) ***
The operation failed.
Bind result: hr = 0x80070002. The system cannot find the file specified.
Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
Running under executable C:\Path\To\My\Binaries\MyCompanyName.MyApp.exe
--- A detailed error log follows.
=== Pre-bind state information ===
LOG: User = username
LOG: DisplayName = MyCompanyName.MyAssembly, Version=1.0.2.0, Culture=neutral, PublicKeyToken=null (Fully-specified)
LOG: Appbase = file:///C:/Path/To/My/Binaries/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = MyCompanyName.MyApp.exe
Calling assembly : MyCompanyName.AnotherAssembly, Version=1.0.2.0, Culture=neutral, PublicKeyToken=null.
===
LOG: Start binding of native image MyCompanyName.MyAssembly, Version=1.0.2.0, Culture=neutral, PublicKeyToken=null.
WRN: No matching native image found.
LOG: IL assembly loaded from C:\Path\To\My\Binaries\MyCompanyName.MyAssembly.dll

Есть ли у кого-нибудь мысли о том, что здесь происходит? Я проверил, что соответствующая нативная сборка существует:

C:\Windows\assembly\NativeImages_v4.0.30319_32\MyCompanyName#\3a041121abf7fbdce89836c32f2d217e\MyCompanyName.MyAssembly.ni.dll

Почему он не связывает его правильно? FWIW, приложение использует MEF совсем немного; Я не знаю, повлияет ли это на загрузку сборок.

2 ответа

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


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

Ваш подход правильный. Вызовите все сборки с помощью NGEN.

ngen install c:\myfiles\MyLib.dll /ExeConfig:c:\myapps\MyApp.exe

В этом случае вам нужно удалить эти сборки вручную из кеша, когда приложение будет удалено.

ngen uninstall c:\myfiles\MyLib.dll /ExeConfig:c:\myapps\MyApp.exe

Смотрите также: http://msdn.microsoft.com/en-us/library/6t9t5wcf(v=vs.100).aspx

licensed under cc by-sa 3.0 with attribution.