Vista és .NET 3.0 kategória bejegyzései

WCF szolgáltatás IIS-en: 404 Page Not Found

Ebbe elég könnyű belefutni és pofonegyszerű a megoldás, csak nem biztos, hogy elsőre beugrik, ezért inkább leírom. Adott egy prímán megírt WCF szolgáltatás, ám amikor IIS-re telepítjük, nem működik. Böngészőben megnézve az .svc fájlt HTTP Error 404: Not Found fogad, pedig a fájl ott van. Csak szegény IIS nem tud róla.

A Windows Communication Foundationt ugyanúgy regisztrálni kell a webkiszolgálóba, mint az ASP.NET-et. ASP.NET esetén erre az aspnet_regiis.exe szolgál, WCF esetén pedig a ServiceModelReg.exe. Az ész nélküli telepítést ugyanúgy a –i kapcsoló szolgáltatja, a telepítés ellenőrzésére viszont a –vi kapcsolót kell használnunk. A ServiceModelReg.exe a .NET Framework 3.0 telepítése után a C:WindowsMicrosoft.NETFrameworkv3.0Windows Communication Foundation mappában található, futtatásához rendszergazdai jogok szükségesek.

Reklámok

Windows Live Messenger error 81000451

A kíváncsiság néha erősebb a józan észnél, ezért időnként hajlamos vagyok az éles gépemre béta szoftvereket telepíteni. Bár nem vagyok chatfüggő, feltettem az új Live Writer mellé a Live Messengert is, aminek meg is lett az eredménye, be sem tudok jelentkezni.

Pontosabban:

Signing in to Windows Live Messenger Beta failed because the service is temporarily unavailable. Please try again later. Error code: 81000451

Némi guglizás után rájöttem, hogy a csoportokhoz nem szabad, nem lett volna szabad hozzányúlni. A block és a leave funkciók, különösen üres csoportoknál okozzák a gondot. Egy darabig megoldást jelentett, hogy a Messenger indítása előtt töröltem az alábbi mappákat:

  • C:UsersfelhasználónévAppDataLocalMicrosoftMessenger
  • C:UsersfelhasználónévAppDataLocalMicrosoftWindows Live Contacts
  • C:UsersfelhasználónévAppDataRoamingMicrosoftMSN Messenger

Egy ideje azonban ez sem segít, nem sikerül a bejelentkezés, sőt sem frissíteni, sem eltávolítani nem sikerült sem a Messengert, sem a Writert.

Szerencsére ma megjelent az új (várhatóan utolsó) Windows Live Essentials béta verzió. A telepítő érdekessége, hogy már tartalmazza a Silverlight 2-t is, amit nem kötelező telepítenünk. További információk és letöltés itt: http://download.live.com/

Technorati Tags: ,,

Vista SP2 és Windows Server 2008 SP2 CPP

Készül a Vista és a Windows Server 2008 második javítócsomagja, a fejlesztés most érkezett a nyilvános béta fázishoz. Érdemes kicsit előretekinteni, hogy mire is számíthatunk.

Az első, amit érdemes megfigyelni, hogy egyetlen telepítő csomag lesz, amely Vistán és Windows Serveren is működni fog. Ez leginkább annak köszönhető, hogy a Windows Server 2008 magja megegyzik a Windows Vista SP1-gyel, azaz a Windows Server 2008 tartalmazza az SP1-t.

Szerintem részben ebből következik, hogy az új javítócsomag nem lesz kumulatív, azaz csak akkor fog futni, ha előtte már az SP1-t telepítettük. Ez elsőre elég szokatlan, fájdalmas szakítás a korábbi hagyományokkal, de csak Vistán lesz macera. Persze várhatóan meg fog jelenni a slipstreamelt telepítő is és szűz rendszereken azt fogjuk futtatni.

Cserébe sikerült elérniük, hogy a Windows Update-ről letöltődő változat mindössze 40-90 MB körül van (bővebben a számokról itt lehet olvasni).

Ebből persze már sejtjük, hogy túl sok újdonságra nem számíthatunk, ettől még nem válik a gépünk Windows Server 2008 R2-vé. Íme egy ízelítő az újdonságokból, kiemelések tőlem:

  • Kb. 10%-kal jobb energiagazdálkodás. Ez szerintem egyre fontosabb, nem csak a laptopok és a data centerek költségei miatt, hanem mert így talán néhány fával több marad az unokáinknak.
  • Hálózattal kapcsolatos javítások elsősorban Bluetooth és Wi-Fi terén. Na ez sem fog ártani…
  • Service pack clean-up tool: visszakapjuk a feleslegesen foglalt diszk területet (bár ilyen már most is van, lásd vsp1cln.exe)
  • Teljesítmény javítások: Windows Search 4.0 és végre talán a sidebar sem fogja folyamatosan pörgetni a processzort.
  • Hyper-V RTM: természetesen csak Serveren, Vistán továbbra is marad a Virtual PC.

Nektek melyik fontos, vagy mit hiányoltok?

A béta programmal (Customer Preview Program, CPP) és a telepítővel kapcsolatos információk és letöltések itt találhatóak.

IRQL_NOT_LESS_OR_EQUAL

Most, hogy elkészült a Windows XP SP3, sőt az MSDN és TechNet előfizetők már slipstreamelt változatot is letölthetnek, úgy gondoltam éppen ideje, hogy az otthoni gépemet újratelepítsem. Nem éppen mai hardverről van szó, az alaplap gyártója 2003-ban adott ki utoljára hardvert, mégis a gépen eddig stabilan ment az XP, mióta csak az SP2-vel slipstreamelt változatot feltelepítettem.

Szóval adott ez a gép, amin jól használható sebességgel, hiba nélkül ment minden hosszú évek óta, erre most a Windows XP telepítő IRQL_NOT_LESS_OR_EQUAL és DRIVER_IRQL_NOT_LESS_OR_EQUAL hibákkal elszállt többször is. Volt, hogy a formázást sem tudta megcsinálni, de volt, hogy még előbb kék halált dobott. Az apróbetűs részből kiderült, hogy az atapi.sys-t okolja, de kicsit furcsának találtam, hogy éppen most legyen meghajtó vagy memória probléma.

Hozzányúlva a géphez rögtön kiderült, hogy melege van, ráadásul szokatlanul melege. Úgy látszik a mindennapi használat során nem pörög ilyen intenzíven a diszk és a CD meghajtó, van ideje a ventillátoroknak érvényesülni vagy egyszerűen csak ez volt az első meleg nap az idén. A gép oldalát megbontva hiba nélkül felment a telepítő és azóta vígan fut az XP a maga 147MB-os commit charge értékével.

 

Technorati Tags: ,,

Activation Error: Code 0x8007232b

Épp egy Windows Server 2008 VPC-t telepítek és aktiválás közben az alábbi sokat mondó hibaüzenetet kaptam:

Activation Error: Code 0x8007232b
DNS Name does not exist

A KB929826 szerint ez akkor fordulhat elő, ha volume-licensed mediáról akarunk Vistát telepíteni. Nálam az lett a megoldás, hogy a Computer properties ablakban a Change product key gombra kattintva megadtam ismét a termékkulcsot és hagytam, hogy utána a Windows automatikusan aktiválja magát.

Csinálj magadnak saját MSDN-t

Talán nem közismert, de az MSDN és a TechNet Library tartalma elérhető egy webszolgáltatáson keresztül, ez az ún. MTPS, az MSDN/TechNet Publishing System. Aki nem hiszi, járjon utána, és olvassa el a doksit, vagy nézze meg a webszolga WSDL-jét.

Ezen a nyilvános webszolgáltatáson keresztül letöltögethetjük a minket érdeklő fejezeteket az netről és ha kedvünk támad, akkor gyúrhatunk belőle saját MSDN-t is. A CodePlexen megtalálható PackageThis alkalmazás pontosan ezt teszi lehetővé, méghozzá barátságos WinForms felületen keresztül, így nem kell beleásnunk magunkat az API-ba.

Ha megtetszik és használni szeretnénk, feltétlenül olvassuk el a Prerequisites fejezetet az oldalon, mert szükség lesz a HTML Help SDK-ra a CHM fájlok előállításához. Aki esetleg úgy jár, mint én, hogy a HTML Help Workshop telepítője félmunkát végez, az hozza létre az alábbi registry kulcsot, mert a PackageThis ezt keresi:

HKCUSoftwareMicrosoftHTML Help WorkshopInstallDir (REG_SZ) = C:Program FilesHTML Help Workshop

Újabb hálás köszönet Lutz Roeder Reflectorának, hogy erre segített fényt deríteni 🙂

Az ok, ami miatt ráakadtam erre az alkalmazásra az volt, hogy ha .NET 3.0 alatt akartam Windows Workflow Foundationnel foglalkozni, a help telepítéséhez szükség volt a legfrissebb Vista SDK-ra, ami bizony néhány gigabájt. Persze a Visual Studio 2008-cal mindez a múltté, mégis kényelmesebb lehet egy kisebb méretű help fájlt átmásolni, mint a teljes MSDN-t telepíteni. A PackageThisben bepipáltam a közel 5000 WF-fel foglalkozó MSDN topicot, majd elindítottam a letöltést, végül eredményként egy kevesebb, mint 6 MB-os, azaz hat megabájtos CHM fájlt kaptam. Persze nem annyira szép, mint a teljes MSDN, és azt sem állítom, hogy minden tökéletesen benne van, de legalább ráfér egy pendrive-ra, nem beszélve arról, hogy az index és a keresés nagyságrendekkel gyorsabb. Már csak ezért is megér egy próbát.

Az MSDN Kompetencia Központ oldalára feltöltöttem a PackageThis forrás fájlt (.xml) és a CHM fájlt ehhez a cikkhez, hátha érdekel valakit.

 

VS05-08 migráció: miért nem megy a virtualizáció?

Érdekes jelenség: van egy kódrészletem, ami tökéletesen megy, ha Visual Studio 2005 alatt létrehozott projektbe teszem bele, ám elszáll, ha Visual Studio 2008 alól próbálom használni. A kód a Program Files mappába próbál írni, így valahogy:

    string programFiles = Environment.GetFolderPath( Environment.SpecialFolder.ProgramFiles );
    string subFolder = Path.Combine( programFiles, "MSDNKK teszt" );
    Directory.CreateDirectory( subFolder );

Egyszerű .NET 2.0 System.IO, semmi extra. Kihasználom, hogy Vista alatt működik a mappa virtualizáció, tehát ha nincs is jogom írni a Program Files mappába, a Vista majd létrehozza ezen az útvonalon:

C:UsersbalassyAppDataLocalVirtualStoreProgram FilesMSDNKK teszt

Ez tökéletesen működik VS 2005 alól, ám VS 2008 alatt ugyanez a kód mintha kikerülné a mappa virtualizációt és jön az XP alatt megszokott kivétel:

System.UnauthorizedAccessException: Access to the path ‘C:Program FilesMSDNKK teszt’ is denied.

A megoldás a bin mappában lakik, még pedig alkalmazásnév.vshost.exe.manifest néven – a VS 2008 ugyanis létrehozza ezt a fájlt, a VS 2005 viszont nem. Ez van benne:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
        <assemblyIdentity version="1.0.0.0" name="MyApplication.app"/>
        <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
            <security>
                <requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
                    <requestedExecutionLevel level="asInvoker" uiAccess="false"/>
                </requestedPrivileges>
            </security>
        </trustInfo>
    </assembly>

A lényeg a requestedExecutionLevel, amit a Studio jó érzékkel asInvoker értékkel hoz létre – ez a javasolt. Ha így hagyjuk, azzal azt jelezzük az operációs rendszernek, hogy jól nevelt Windows alkalmazásról van szó, ami ugyanolyan access tokennel futhat, mint a szülő process. Már pedig egy jól nevelt alkalmazás nem irogat a Program Files mappába és egyéb közös területekre (pl. HKLM) sem, és ha ez így van, akkor a Windows szépen kikapcsolja a virtualizációt!

Nosza próbáljuk meg átállítani ezt az értéket! Választhatunk a lehetséges highestAvailable vagy requireAdministrator közül bármelyiket, virtualizációnk akkor sem lesz! Hiszen pont ez a lényeg, a helyi admin épp a Program Files mappába akar írni.

Ez a kapcsoló azért jó valamire:

asInvoker vs requireAdministrator

Ahogy a pajzs ikon is jelzi, megkaphatjuk érte a consent vagy a credential promptot, attól függően, hogy rendszergazdák vagyunk vagy mezei felhasználók. Adminként pedig már nem lesz szükségünk a virtualizációra.

Már csak egy információval vagyok adós: hogyan lehet mindezt szabályozni Visual Studio 2008-ban. Természetesen a Project Properties ablakban:

Project Properties: manifest

Alapértelmezés szerint ez az opció Embed manifest with default settings értéken áll, ezért hozza létre a Studio a bin mapában a .manifest állományt. Ha ezt ki akarjuk kapcsolni és vissza akarunk állni a Visual Studio 2005 üzemmódra, akkor válasszuk a Create application without a manifest értéket és legalább legyen lelkiismeret furdalásunk, hogy miért nem írunk "jól nevelt" alkalmazást.

Helyette inkább másoljuk le a generált fájlt, nevezzük át mondjuk app.manifestre, vegyük fel a Solution Explorerbe, majd válasszuk ki a fenti ablakban. Így jól kézben tarthatjuk ezt a beállítást és ha valóban írni akarunk közös mappákba vagy registry kulcsokba, akkor rajzoltassuk oda azt a pajzsot, hadd lássa ország-világ, hogy ennek az alkalmazásnak admin jog kell!

A requestedExecutionLevel beállítással kapcsolatban bővebb információ az MSDN UAC példájában található, a cikkhez tartozó példakód pedig letölthető az MSDN Kompetencia Központ oldaláról.

 

Technorati tags: , ,