Daily Archives: 2009.08.24. 5:45

ASP.NET 4: fogyókúrán a web.config

Aki hosszabb ideje foglalkozik már az ASP.NET-tel, annak biztosan feltűnt, hogy minden verzióval jelentősen hízott a web.config. Elég csak létrehozni egy új webhelyet Visual Studioban és kapunk egy több képernyős konfig fájlt, ami ráadásul szinte minden webalkalmazásnál ugyanaz. A beállítások többségéhez többnyire hozzá sem nyúlunk (tegye fel a kezét, aki kiszedte a .vb fájlok fordítására vonatkozó beállításokat egy C# projektből), viszont nap mint nap kerülgetjük. A helyzet az IIS 7-tel csak “rosszabbodott”, hiszen Windows Server 2008-on már a webkiszolgáló beállításai is a web.configba kerülnek.

Erre a problémára úgy látszik Redmondban is felfigyeltek, mert a .NET Framework 4-től kezdve a beállítások nagy része átkerül a machine.config fájlba és az ott szereplő értékeket az egyes webalkalmazások öröklik. Ez a gyors fogyókúra alapesetben ennyire fogja redukálni a web.configot (béta 2 példa – változhat):

  <?xml version="1.0"?>
  <configuration>
    <system.web>
      <compilation targetFramework="4.0" />
    </system.web>
  </configuration>

Sőt, ha a webalkalmazásunk .NET Framework 4 application poolban fut, akkor a fenti “4.0” az alapértelmezett targetFramework érték, tehát akár üres is lehet a web.configunk.

Ami már most is működik

Van éppen egy projektünk, amiben az IIS 7 UrlRewrite modulját használjuk. Nagyon jó eszköz, azonban alapértelmezés szerint ez is a web.configba pakolja a létrehozott szabályokat, ami a mi esetünkben jelen pillanatban közel 200 sor és ez a szám gyors ütemben növekszik. Ezért azt a megoldást választottuk, hogy a szabályokat kitettük külön .config fájlba a configSource attribútum használatával. A web.configban a modul által használt rewrite szekcióból ez maradt:

  <rewrite>
    <rules configSource="web_rewrite_rules.config" />
  </rewrite>

A web_rewrite_rules.config fájl pedig így kezdődik:

  <?xml version="1.0" encoding="UTF-8"?>
  <rules>
    <rule ...>
      ...
    </rule>
...
</rules>

Ez a módszer tökéletesen működik .NET Framework 3.5 és IIS 7.5 (Windows 7) alatt, az IIS Management Console felismeri a configSource attribútumot és a grafikus felületen végzett módosításokat a külső fájlba írja. Eddig egy mellékhatást tapasztaltunk: a hivatkozott külső fájl módosítása esetén nem indul újra automatikusan a webalkalmazás és mivel a beállítások gyorsítótárban tárolódnak, a rendszer észre sem veszi, hogy változtattunk valamin. Az már a konkrét helyzettől függ, hogy ez éppen előny vagy hátrány.

Advertisements

SharePoint Access Web Datasheet hiba

Egy Windows SharePoint Services webhely egyik adatlap nézetben megjelenő listája a minap az alábbi hibaüzenettel üdvözölt:

“The Access Web Datasheet is attempting to retrieve data from a different domain. You will be redirected to an error page. Contact your system administrator to resolve this error.”

A legszebb az egészben, hogy mindez csak akkor jelent meg, amikor a listát a http://intranet címen keresztül értem el, amikor FQDN-en keresztül, akkor működött simán. Ezek után nem lepődtem meg, hogy a guglizás eredménye az lett, hogy nézzek körül az Alternate Access Mappings beállításoknál.

A megoldás azonban lényegesen egyszerűbb volt: elfogyott a szabad hely a C: meghajtón. Kiderült, hogy a bűnös maga a WSS volt, a keresőmotor elindított egy teljes újraindexelést és közben telehányta a naplót a C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions12LOGS mappában. Magasabbra vettem a naplózási küszöböt a Központi Felügyelet oldalon, kitöröltem a LOGS mappa tartalmát és azóta megint szépen forog a gép.

Hogy ennek mi köze a fenti hibaüzenethez? Szerintem semmi. Contact your developer to fix this error message.