Unikaj dziedziczenia web.config w podrzędnych aplikacjach internetowych przy użyciu inheritInChildApplications

Próbuję dodać

<location inheritInChildApplications="false">

do pliku web.config mojej nadrzędnej aplikacji internetowej, ale wygląda na to, że nie działa.

Moi rodzice web.configmają:

<configuration>
    <configSections>
    </configSections>

    // 10 or so custom config sections like log4net, hibernate,

    <connectionStrings>
    </connectionStrings>

    <appSettings>
    </appSettings>

    <system.diagnostics>
    </system.diagnostics>

    <system.web>
         <webParts>
         </webParts>
         <membership>
         </membership>

         <compilation>
         </compilation>
    </system.web>

    <location ..>
    <system.web>
        </system.web>
    </location>

    <system.webServer>
    </system.webServer>

Moja podrzędna aplikacja internetowa jest skonfigurowana jako aplikacja w usługach IIS i dziedziczy po aplikacji rodzica, web.configktóra powoduje problemy.

Gdzie dokładnie powinienem umieścić plik

<location inheritInChildApplications="false">

więc ignoruje wszystkie różne ustawienia web.config?

Jak wspomnieli komentatorzy poprzedniej odpowiedzi, nie możesz po prostu dodać linii ...

<location path="." inheritInChildApplications="false">

... tuż poniżej <configuration>. Zamiast tego musisz opakować poszczególne sekcje web.config, dla których chcesz wyłączyć dziedziczenie. Na przykład:

<!-- disable inheritance for the connectionStrings section -->
<location path="." inheritInChildApplications="false">
   <connectionStrings>
   </connectionStrings>
</location>

<!-- leave inheritance enabled for appSettings -->
<appSettings>
</appSettings>

<!-- disable inheritance for the system.web section -->
<location path="." inheritInChildApplications="false">
   <system.web>
        <webParts>
        </webParts>
        <membership>
        </membership>

        <compilation>
        </compilation>
      </system.web>
 </location>

Chociaż <clear />może to działać w przypadku niektórych sekcji konfiguracyjnych, są takie, które zamiast tego wymagają <remove name="...">dyrektywy, a jeszcze inne też nie obsługują. W takich sytuacjach prawdopodobnie należy ustawić inheritInChildApplications="false".

Musi przejść bezpośrednio pod <configuration>węzeł główny i musisz ustawić taką ścieżkę:

<?xml version="1.0"?>
<configuration>
    <location path="." inheritInChildApplications="false"> 
        <!-- Stuff that shouldn't be inherited goes in here -->
    </location>
</configuration>

Lepszym sposobem obsługi dziedziczenia konfiguracji jest użycie <clear/>w konfiguracji podrzędnej wszędzie tam, gdzie nie chcesz dziedziczyć. Więc jeśli nie chcesz dziedziczyć parametrów połączenia konfiguracji nadrzędnej, zrobiłbyś coś takiego:

<?xml version="1.0"?>
<configuration>
    <connectionStrings>
        <clear/>
        <!-- Child config's connection strings -->
    </connectionStrings>
</configuration>

Włożyłem wszystko w:

<location path="." inheritInChildApplications="false">
....
</location>

z wyjątkiem: <configSections/>, <connectionStrings/>i <runtime/>.

Są przypadki, w których nie chcemy dziedziczyć niektórych sekcji z <configSections />, ale nie możemy wstawić <section/>tagu <location/>, więc musimy utworzyć<secionGroup /> i umieścić nasze niechciane sekcje w tej grupie. Grupy sekcji można później wstawić do znacznika lokalizacji.

Więc musimy to zmienić:

<configSections>
  <section name="unwantedSection" />
</configSections>

W:

<configSections>
  <sectionGroup name="myNotInheritedSections">
    <section name="unwantedSection" />
  </sectionGroup>
</configSections>

<location path="." inheritInChildApplications="false">
    <myNotInheritedSections>
        <unwantedSection />
    </myNotInheritedSections>
</location>

Otrzymaliśmy błąd związany z tym po ostatnim wydaniu kodu w jednym z naszych środowisk programistycznych. Mamy aplikację, która jest dzieckiem innej aplikacji. Ten związek działał dobrze przez LATA aż do wczoraj.

Problem:
otrzymywaliśmy żółty błąd śledzenia stosu z powodu wprowadzenia zduplikowanych kluczy. Dzieje się tak, ponieważ zarówno plik web.config dla aplikacji podrzędnej, jak i nadrzędnej miał ten klucz. Ale to istniało przez wiele lat bez zmian. Dlaczego nagle teraz jest to problem?

Rozwiązanie:
nigdy nie stanowiło to problemu, ponieważ klucze AND były zawsze takie same. Wczoraj zaktualizowaliśmy nasze parametry połączenia SQL, aby uwzględnić nazwę aplikacji w parametrach połączenia. To sprawiło, że struna była wyjątkowa i nagle zaczęła zawodzić.

Nie szukając dokładnej przyczyny takiego stanu rzeczy, muszę założyć, że gdy aplikacja podrzędna dziedziczy wartości z pliku web.config nadrzędnego, ignoruje identyczne pary klucz / wartość.

Udało nam się to rozwiązać, opakowując parametry połączenia w ten sposób

    <location path="." inheritInChildApplications="false">
        <connectionStrings>
            <!-- Updated connection strings go here -->
        </connectionStrings>
    </location>

Edycja: zapomniałem wspomnieć, że dodałem to w web.config RODZICÓW. Nie musiałem modyfikować pliku web.config dziecka.

Dzięki za pomoc wszystkim, uratowaliśmy nasze tyłki.

Jeśli (jak rozumiem) próbujesz całkowicie zablokować dziedziczenie w konfiguracji internetowej swojej aplikacji podrzędnej, sugeruję unikanie używania tagu w pliku web.config. Zamiast tego utwórz nową pulę aplikacji i edytuj plik applicationHost.config (znajdujący się w% WINDIR% \ System32 \ inetsrv \ Config i% WINDIR% \ SysWOW64 \ inetsrv \ config). Musisz tylko znaleźć wpis dla swojej puli aplikacji i dodać atrybut enableConfigurationOverride="false"jak w poniższym przykładzie:

<add name="MyAppPool" autoStart="true" managedRuntimeVersion="v4.0" managedPipelineMode="Integrated" enableConfigurationOverride="false">
    <processModel identityType="NetworkService" />
</add>

Pozwoli to uniknąć dziedziczenia konfiguracji w aplikacjach obsługiwanych przez MyAppPool.

Matteo

To jest strona firmy Microsoft w locationtagu: http://msdn.microsoft.com/en-us/library/b6x6shw7%28v=vs.100%29.aspx

Może to być pomocne dla niektórych osób.

Otrzymujemy błędy dotyczące zduplikowanych dyrektyw konfiguracyjnych w jednej z naszych aplikacji. Po zbadaniu wygląda na to, że jest to spowodowane tym problemem .

W skrócie, nasza główna witryna sieci Web to ASP.NET 3.5 (czyli 2.0 z dodanymi określonymi bibliotekami), a my mamy aplikację podrzędną, która jest ASP.NET 4.0.

Dziedziczenie pliku web.config powoduje, że podaplikacja ASP.NET 4.0 dziedziczy plik web.config nadrzędnej aplikacji ASP.NET 3.5.

Jednak globalny (lub „główny”) plik web.config aplikacji ASP.NET 4.0, który znajduje się w C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Config \ web.config i C: \ Windows \ Microsoft. NET \ Framework64 \ v4.0.30319 \ Config \ web.config (w zależności od twojej bitness) już zawiera te sekcje konfiguracyjne.

Następnie aplikacja ASP.NET 4.0 próbuje scalić ze sobą główny ASP.NET 4.0 web.config i nadrzędny web.config (ten dla aplikacji ASP.NET 3.5) i działa jako duplikaty w węźle.

Jedynym rozwiązaniem, jakie udało mi się znaleźć, jest usunięcie sekcji konfiguracyjnych z nadrzędnego pliku web.config, a następnie jednego z nich

1. Ustal, że nie potrzebujesz ich w aplikacji root, a jeśli tak
2. Uaktualnij aplikację nadrzędną do ASP.NET 4.0 (aby uzyskała dostęp do configSections katalogu głównego web.config)