Мы перемещаем наш продукт ASP.NET с .NET Framework 3.5 до 4.5.1 в качестве части этого, нашим клиентам необходимо будет изменить свой пул приложений с версии CLR версии 2.0 на 4.0.Предупреждать клиентов о неправильной версии исполнения в пуле приложений
Подавляющее большинство наших клиентов устанавливают с помощью MSI, который правильно настраивает пул приложений. Иногда у нас есть клиенты, которые вручную настраивают свои пулы приложений для приложения. Мы хотим сказать им: «Эй, у вас неправильная версия CLR, выбранная в пуле приложений», используя сам продукт.
Мы достигли чего-то подобного для режима трубопровода. Мы сделали это, сделав HttpModule, что имеет предпосылку integratedMode:
<system.webServer>
<modules>
<add preCondition="integratedMode" name="IisPipelineCheckModule" type="IisPiplineCheckModule, OurAssembly, Culture=neutral, PublicKeyToken=ba36f1f458df13fd" />
</modules>
Все это HTTP модуль делает это выплюнуть страницу HTML инструктирования их изменить AppPool к классическому трубопровода (который мы требуем):
application.Response.ClearContent();
application.Response.ContentType = "text/html";
application.Response.WriteFile(application.Server.MapPath("~/pipeline.htm"));
application.Response.End();
Мы попытались сделать что-то подобное, добавив во время выполнения версии предпосылки для 2.0 инструктировать клиент, чтобы изменить версию среды выполнения до 4,0:
<add preCondition="runtimeVersionv2.0" name="IisNetFxCheckModule" type="NetFxVersionCheckModule, SomeAssemblyCompiledFor20Clr, Culture=neutral, PublicKeyToken=ba36f1f458df13fd" />
К сожалению, у этого есть несколько проблем. Если приложение AppPool установлено на CLR 2.0 неправильно, оно даже не может пройти анализ синтаксиса web.config, поскольку он может содержать элементы и атрибуты, которые являются новыми для 4.0, например <httpRuntime requestValidationMode="2.0" />. Это взорвется, прежде чем он даже приблизится к выполнению HttpModule. Аналогично, если «bin» содержит сборки, скомпилированные для 4.0 CLR, будут сбои загрузки сборки, указывающие, что сборка была построена для более новой версии среды выполнения.
Я думаю, что то, что я ищу, невозможно, невозможно занять достаточно времени в течение срока службы приложения, чтобы предупредить о некорректной версии CLR, прежде чем бункер будет даже исследован для сборок или Анализируется web.config.
Есть ли что-то, что я упустил, где это возможно? Мы можем предположить, что версия IIS - 7.0 или выше.
+1 Теперь * это * вопрос! _Learned_ что-то уже, просто прочитав _question_ - Woot! – EdSF
Действительно ли это должно быть на раннем этапе жизненного цикла? Вы можете проверить 'System.Environment.Version' где-то в точке входа (например, Page_Init of Default.aspx) –
@YuriyGalanter Это должно быть * раннее *, прежде чем структура ASP.NET будет даже загружена. 'Page_Init' не будет работать, потому что IIS не может даже пройти точку загрузки web.config. Даже если он * может * пройти мимо web.config (скажем, нам удалось сделать его совместимым с 2.0), менеджер сборки ASP.NET будет бомбить на 'CompileGlobalAsax', потому что будут собраны в бункере, скомпилированном для 4.0, который выиграл Не загружайте. – vcsjones