Я использую aspnet_compiler для предварительной компиляции веб-сайта asp.net. Затем я запускаю aspnet_merge, чтобы объединить предварительно скомпилированные сборки в одну.
К сожалению, aspnet_merge не включает ни одну из сборок в процесс слияния. Поэтому эта сборка остается неизменной. Еще более досадно, что эта сборка ссылается на одну из сборок, которые были объединены (и теперь удалены), и эта ссылка не обновляется aspnet_merge. Поэтому я получаю FileNotFoundException "Не удалось загрузить файл или сборку" при использовании этой dll.
Пока что я понял, что после этапа прекомпиляции большинство сборок именуются как
App_Web_xxxxxxxx.dll.
тогда как оскорбительная 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, пытаясь понять, какую логику он использует, когда решает, какие dll объединять, но, возможно, кто-то видел эту проблему раньше или имеет предложение?
Я ищу способ заставить aspnet_compiler создавать библиотеки dll, которые понимает aspnet_merge, или способ убедить aspnet_merge обновить все сборки, которые ссылаются на любые библиотеки app_web*, которые он удаляет. Спасибо!
Обновление: aspnet_merge игнорирует App_Web_nameofusercontrol.ascx.xxxxxxxx.dll, поскольку aspnet_compiler не создает соответствующий скомпилированный файл. Кроме того, пользовательский элемент управления, по-видимому, также скомпилирован в одну из сборок App_Web_xxxxxxxx.dll. Однако я не знаю, почему один и тот же пользовательский элемент управления компилируется в две разные сборки. Возможно, странная проблема с циклическими ссылками?
