Проблема сгруппа конфигурации при обновлении до .NET 4.0 - PullRequest
Новая
       7

Проблема сгруппа конфигурации при обновлении до .NET 4.0

9 голосов
/ 09 июля 2010

Итак, мы обновили наш сайт с версии 3.5 SP1 -> .NET 4.

Когда мы запустили сайт, мы получили внутреннюю ошибку сервера (500), указав, что следующая группа конфигурации не может быть прочитана: 

<system.web.extensions>
        <scripting>
            <scriptResourceHandler enableCompression="true" enableCaching="true" />
            <webServices>
                <jsonSerialization maxJsonLength="999999" />
            </webServices>
        </scripting>
    </system.web.extensions>

Мы прокомментировали этот раздел, и веб-сайт работал нормально (но теперь у нас возникают проблемы с JSON - из-за вышеуказанного обязательного свойства).

Мы читали темы наЭта проблема, и большинство из них говорят: «Ваш пул приложений не работает 4.0».И это не проблема.

Я также читал темы о том, что IIS каким-то образом читает старый файл machine.config.

В .NET 4, как вы знаете, многоразделы web.config были перемещены в machine.config.

Поэтому мы помещаем этот раздел обратно в верхнюю часть web.config: 

<sectionGroup name="system.web.extensions" type="System.Web.Configuration.SystemWebExtensionsSectionGroup, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35">
            <sectionGroup name="scripting" type="System.Web.Configuration.ScriptingSectionGroup, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35">
                <section name="scriptResourceHandler" type="System.Web.Configuration.ScriptingScriptResourceHandlerSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" allowDefinition="MachineToApplication"/>
                <sectionGroup name="webServices" type="System.Web.Configuration.ScriptingWebServicesSectionGroup, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35">
                    <section name="jsonSerialization" type="System.Web.Configuration.ScriptingJsonSerializationSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" allowDefinition="Everywhere" />
                    <section name="profileService" type="System.Web.Configuration.ScriptingProfileServiceSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" allowDefinition="MachineToApplication" />
                    <section name="authenticationService" type="System.Web.Configuration.ScriptingAuthenticationServiceSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" allowDefinition="MachineToApplication" />
                    <section name="roleService" type="System.Web.Configuration.ScriptingRoleServiceSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" allowDefinition="MachineToApplication" />
                </sectionGroup>
            </sectionGroup>
        </sectionGroup>

И теперь веб-сайт кажетсяработать нормально.

Тем не менее, я немного обеспокоен, если это правильное решение.

Есть идеи людей?Это правильное исправление?

РЕДАКТИРОВАТЬ:

3 недели и без ответов ... блин.=)

Ответы [ 3 ]

2 голосов
/ 31 декабря 2010

Недавно я столкнулся с этой проблемой и смог ее решить после устранения неполадок. Надеюсь, то, что я сделал, поможет исправить и твою проблему. 1. Убедитесь, что пул приложений, который вы используете для сайта, использует конвейер .NET 4 2. Откройте ваш .csproj (или .vbproj, если у вас проект VB) в Блокноте и пошагово просмотрите файл и проверьте, есть ли какие-либо жестко закодированные ссылки на файлы v2.0 Framework. В моем случае у нас была задача «После сборки», которая использовала путь компилятора v2.0, который заставлял приложение по-прежнему использовать среду выполнения 2.0. Это было похоже на ниже. 

<Target Name=”AfterBuild” Condition=”’$(MvcBuildViews)’==’true’”>
<AspNetCompiler Condition=”’$(IsDesktopBuild)’ != ‘false’” VirtualPath=”temp” ToolPath=”$(WINDIR)\Microsoft.NET\Framework\v2.0.50727” PhysicalPath=”$(ProjectDir)\..\$(ProjectName)” />
<AspNetCompiler Condition=”’$(IsDesktopBuild)’ == ‘false’” VirtualPath=”temp” ToolPath=”$(WINDIR)\Microsoft.NET\Framework\v2.0.50727” PhysicalPath=”$(OutDir)\_PublishedWebsites\$(ProjectName)” />

Обязательно измените их на v4.0 или, что еще лучше, сделайте их настраиваемыми. Надеюсь, это поможет.

-Vamsi

2 голосов
/ 03 августа 2010

Поскольку у меня не было ответов, а активное гугление тоже не привело к любви, я решил оставить свое оригинальное исправление (добавив раздел system.web.extensions обратно в web.config).

0 голосов
/ 14 октября 2010

Еще два бита информации, которые могут или не могут помочь.

  1. единственное отличие от вышеупомянутого sectionGroup и моей машины sectionGroup - это версия = 3.5.0.0 здесь и версия = 4.0.0.0 вmachine.config.1.
  2. Ошибка в журнале событий: «Не удалось загрузить все фильтры ISAPI для сайта ...». Возможно, установлена ​​System.Web.Extensions, которая не зарегистрирована должным образом в .net 4?

Я бы с удовольствием проверил это, но, к сожалению, такое поведение я вижу только в производственной системе, а не в системе разработки.

...