Я использую aspnet_compiler, чтобы предварительно скомпоновать сайт asp.net. Затем я запускаю aspnet_merge для объединения предварительно скомпилированных сборок в один.aspnet_merge вызывает dll не найдена ошибка
К сожалению, aspnet_merge не включает одну из сборок в процесс слияния. Следовательно, эта сборка остается неизменной. Еще более неудачно, эта сборка ссылается на одну из сборок, которую сделал, и теперь эта ссылка не обновляется aspnet_merge. Поэтому я получаю FileNotFoundException «Не удалось загрузить файл или сборку», когда эта dll используется.
До сих пор я понял, что после стадии прекомпиляции, большинство сборок названы как
App_Web_xxxxxxxx.dll.
тогда как дллы-нарушителя названа как:
App_Web_nameofusercontrol.ascx.xxxxxxxx.dll
Я думаю, именно поэтому aspnet_merge игнорируемых Это. Я подтвердил, что aspnet_merge игнорирует, используя параметр -log, он генерирует список входных сборок.
Я называю aspnet_compiler и aspnet_merge так:
aspnet_compiler.exe -v VirtualDirectoryName -p ActualDirectory c:\precompileoutput
aspnet_merge.exe c:\precompileoutput -o mergeddllname
В настоящее время я смотрел на декомпилированный код aspnet_merge, пытаясь выяснить, что логика это работает, когда он решает, какие DLLS слиться, но, возможно, кто-то видел этот вопрос раньше или имеет предложение?
Я ищу способ, чтобы aspnet_compiler создавал dll, который понимает aspnet_merge, для того, чтобы убедить aspnet_merge обновить все сборки, которые ссылаются на любую DLL-файл app_web *, который он удаляет. Благодаря!
Update: aspnet_merge игнорирует App_Web_nameofusercontrol.ascx.xxxxxxxx.dll, потому что aspnet_compiler не генерирует соответствующий .compiled файл. Кроме того, пользовательский контроль, похоже, также скомпилирован в одну из сборников App_Web_xxxxxxxx.dll. Однако я не знаю, почему один и тот же пользовательский элемент управления скомпилирован в две разные сборки. Возможно, странная круговая справочная проблема?