Tag Archives: Windows 8

ISO fájl megnyitása nem sikerül

Windows 8 alatt már nem egyszer belefutottam az alábbi hibaüzenetbe, mikor egy ISO fájlt próbáltam a Windows Explorer segítségével mountolni:

“You don’t have permission to mount the file.”

 

no-permission-to-mount-the-file

Pánikra semmi ok, vaklárma az egész, valójában szépen megcsinálta, amit kértünk tőle, ott virít az új meghajtó a My Computerben.

 

Technorati Tags: ,,

Ingyenes e-book Windows (Phone) 8.1 fejlesztéshez

2843.9780735611111f_7E0540F4A Windows 8 megjelenésével egy időben adta ki a Microsoft Press Kraig Brockschmidt Programming Windows Store Apps with HTML, CSS and JavaScript c. könyvét ingyenes e-book formájában. A 8.1 verzió megjelenésével a könyv kissé elavult, de szerencsére Kraig nem csüggedve tovább dolgozott rajta.

Most jelent meg a könyv második kiadása, amely 478 oldallal kibővítve immár a Windows 8.1 újdonságait is lefedi, sőt jelentős része alkalmazható Windows Phone 8.1 fejlesztéseknél is. A teljes könyv így 1311 oldalas lett, és szerencsére továbbra is ingyenesen tölthető le a Microsoft Virtual Academy oldaláról a kapcsolódó példakódokkal együtt.

 

IIS távoli felügyelete Windows 8.1-ről

Az Internet Information Services (IIS) Manager (inetmgr.exe) egyik kiváló szolgáltatása, hogy a saját gépünkön elindítva, grafikus felületen keresztül, távolról felügyelhetjük vele a webszervereinket. Ehhez nem kell mást tennünk, mint kiválasztanunk a File menüből a Connect to a Server menüpontot:

inetmgr-connect-to-file-menu

Ez végigvezet egy varázslón, és ha a szerveren telepítve van a Web Management Service, akkor pillanatok alatt csatlakozhatunk a webszerverünkhöz, webhelyünkhöz vagy webalkalmazásunkhoz.

A gond akkor van, ha nincs ilyen menüpont, márpedig nincs. Sem Windows 7-en, sem Windows 8-on, sem 8.1-en. bezzeg Save Connections van (igaz, disabled állapotban), de vajon minek?

inetmgr-default

Windows 7 esetén még történeti okokra hivatkozva talán megértem, de az újabb kliens operációs rendszerek esetén nem találok magyarázatot. Ha már mindenképp külön kell letölteni, akkor lehetne például az RSAT része.

Oldjuk meg hát a problémát, irány a Web Platform Installer, ahol például a “remote” szóra keresve pillanatok alatt megtalálhatjuk az IIS Manager for Remote Administration v1.1 verziót:

inetmgr-webpi-search

Senkit ne tévesszen meg a két évvel ez előtti dátum, pont ez kell nekünk. Bökjünk a sorban az Add, majd alul az Install gombokra, végül a következő ablakban az I Accept gombra kattintva fogadjuk el a licenc előírásait. Elindul a letöltés, megkezdődik a telepítés, majd jön a hidegzuhany:

inetmgr-webpi-sorry

Nem sikerült a telepítés, mert Windows 7 vagy újabb kell neki. De hát ez egy Windows 8.1, jaj!

Próbálkozzunk meg ismét a telepítéssel, de most a licenc elfogadása ablakban kattintsunk inkább a Direct Download Link hivatkozásra:

inetmgr-webpi-licence

Ennek hatására az alapértelmezett böngészőnk letölti a telepítőt oda, ahova mi szeretnénk. A letöltési cím egyébként a hibaüzenet melletti View log here gombra kattintva megjelenő naplófájlból is kicsalható, az én esetemben ez volt:

http://download.microsoft.com/download/D/A/5/DA588562-C4A4-4337-AE36-3A4548700CDF/inetmgr_amd64_v1.1_en-US.msi

Mielőtt elindítjuk a telepítőt, nyissuk meg az MSI fájlhoz tartozó Properties ablakot és a Compatiblity fülön álljunk vissza korábbi Windows verzióra:

inetmgr-compatibility

Nyomkodjuk végig a varázslót, indítsuk újra az IIS Managert és már kapcsolódhatunk is a szerverünkhöz, ahonnan előfordulhat, hogy az első alkalommal újabb modulok töltődnek le:

inetmgr-features

 

Technorati-címkék: ,

12GB-os NVIDIA driver csomag

A Windows Update-en feltűnt ma egy opcionális frissítés NVIDIA driver update for NVIDIA Quadro NVS 150M néven és én elkövettem azt a hibát, hogy engedélyeztem a telepítését.

nvidia-update

Ott kezdtem el gyanakodni, hogy ebből gond lesz, amikor megjelent az üzenet, hogy elindult a 300MB-nyi telepítő letöltése. Gondoltam naivan, hogy majd kiszedi belőle azt a pár megabájtnyi fájlt, amire tényleg szükség van, de aztán legnagyobb meglepetésemre pár perccel később 12 gigabájtnyi szabad helyem tűnt el a C: meghajtóról. Ez már önmagában is idegesítő, de ha ez volt az ember utolsó 12GB-ja, akkor különösen.

A WinDirStat szépen kirajzolta, hogy a C:\Windows\System32\DriverStore\FileRepository mappa foglal sok helyet, azon belül is a sok friss dátumú, nv-vel kezdődő nevű, egyenként 300MB-os könyvtárak. Jó lenne megnézni, mik ezek. Ezt lehet parancssorból is, így:

dism /online /get-drivers /format:table

Nekem azonban jobban bejön a CodePlexről letölthető DriverStore Explorer, ami mindezt grafikus felületen tudja, valahogy így (ez már a pucolás utáni állapot):

driverstore-explorer

Ha csak 1 NVIDIA driver lett volna a listában, akkor a Delete Package gombbal vidáman kitakarítottam volna, de az én listámban volt vagy 30. Akkor most melyiket töröljem?

Eszembe jutott, hogy a Windows 8.1 Disk Cleanup eszközében már van opció a felesleges driverek törlésére is:

driver-cleanup

Sajnos ez pont nulla bájtnyival segített, nem voltam előrébb.

A Programs and Features ablakból megtudtam, hogy a 327.02 verziót sikerült telepítenem a Windows Update-ről, majd ezek után elmentem az NVIDIA Drivers Download oldalára, ahol örömmel láttam, hogy van frissebb verzió, most éppen 331.65. Ugyan ennek a letöltése is 214MB, de a manuális telepítésnél legalább a kezünkben van az irányítás.

A sikeres letöltés után eltávolítottam a korábbi verziót és végignyomogatva a telepítő varázslót feltettem a frisset. Így nem csak olyan opciót kaptam, hogy akarok-e nView-t, de a Perform a clean installation pipa bebillentésével a telepítő szépen kitakarította  a korábbi eszközmeghajtót:

clean-install

A telepítés simán ment, visszakaptam a tárhelyemet, és ráadásul frissebb eszközmeghajtóm is van (szerencsére ez is WHQL tesztelt).

Azt hiszem ez volt az utolsó alkalom, hogy Windows Update-ről telepítettem NVIDIA drivert.

 

Technorati-címkék: ,,

Run as Administrator érdekesség Windows 8.1-en

Négy hete használom a Windows 8.1 RTM változatát, természetesen szokás szerint nem admin felhasználóként. Amikor mégis kell valamihez admin jog, akkor a jól bevált Run as Administrator opcióval indítom. Például az IIS Managert:

RunAs-1

Erre feljön a szokásos jelszó bekérő ablak:

RunAs-2

Ahova beírom a felhasználónevemet és a helyes jelszavamat:

RunAs-3

Majd Enterre nem történik semmi. Micsoda, ez már sok éve hibátlanul működött?!

Hetekig bosszankodtam miatta, mert ez volt az egyetlen napi problémám a Windows 8-cal (ugyanez történik az UAC promptnál is), de aztán véletlenül rájöttem, hogy én voltam a béna, hiszen nem olvastam el a használati utasítást.

Emlékeztető magamnak: RTFM!

 

Technorati-címkék: ,

Hibernálás engedélyezése Windows 8-on

A frissen telepített Windows 8.1 RTM gyönyörűen felismert minden eszközt a gépemben, semmilyen driver hiba nem volt, mégsem jelent meg a Hibernate opció a Shut down or sign out menüben. Első körben engedélyeztem a hibernálást a powercfg /h on paranccsal, ami hiba nélkül le is futott, a menüpont mégsem jelent meg.

Úgy tűnik, azt külön engedélyezni kell, méghozzá így:

A Power Options ablak bal oldalán található a Choose what the power buttons do menüpont:

hibernate-power-options

A megjelenő Define power buttons and turn on password protection ablak alján lehet engedélyezni a hibernáló gomb megjelenítését rendszergazdai jogosultságokkal:

hibernate-shutdown-settings

Ezután már lehet több helyről is hibernálni:

hibernate-shutdown-menu

hibernate-shutdown-charm

 

Technorati-címkék: ,

ASP.NET 4.0 űrlap alapú hitelesítés IE11 alatt

Korábban már említettem, hogy a böngészők detektálásán alapuló megoldások gondot okozhatnak, amikor megjelenik egy új böngésző vagy egy új böngésző verzió. Sajnos mivel az ASP.NET korábbi verziói is tartalmaznak böngésző detektálós részeket, az Internet Explorer 11 megjelenése ott is gondot okozhat.

Véletlen egybeesés, hogy az említett cikk után egy nappal Eric Lawrence is írt egy cikket az IE11-ről és a User-Agent sniffingről. Néhány érdekesség belőle:

  • Az IE csapat szándékosan úgy választotta meg a UA stringet, hogy a weboldalak inkább WebKites böngészőnek ismerjék fel, mint régebbi IE verziónak.
  • A nyár folyamán az ASP.NET csapat kiadott frissítéseket a probléma megoldására, például .NET 4.0-hoz a KB2836939-et. A többi frissítés listája megtalálható a cikkben.

Mi egy olyan problémába futottunk bele korábban, hogy az IE11 lelkesen felküldte az ASP.NET forms authentication cookie-t a szervernek, de a szerver fittyet hányt rá. A web.config fájlban lévő forms elemnél korábban nem szerepelt a cookieless attribútum, mert az alapértelmezett UseDeviceProfile eddig tökéletesen működött, most viszont explicit módon be kellett állítanunk a UseCookies értéket, hogy az oldal IE11-gyel is működjön rendesen.

Itt egy régebbi szerverről volt szó, amin ASP.NET 4.0 futott a fenti frissítés nélkül, 4.5-ön ezt nem tapasztaltuk.

Megjegyzem a cookieless="UseCookies" biztonság szempontból is a javasolt beállítás.

 

Technorati-címkék: ,,,

IE11 User-Agent string

A Windows 8.1-ben megjelenő Internet Explorer 11-hez tartozó User-Agent string (ez az, amit a HTTP kérésben a böngésző felküld a szervernek) a következő:

Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko

Akkor lesz nyilvánvaló, hogy mi ebben az érdekes, ha összehasonlítjuk a korábbiakkal, például az IE10 és az IE9 azonosítójával:

Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Trident/6.0)
Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)

A formátum tehát teljesen megváltozott, sőt az MSIE jelölés teljesen eltűnt! Ez akkor okozhat gondot, ha valamilyen kliens vagy szerver oldali kódunkba böngészőfüggő viselkedést írtunk, ugyanis a régebbi kódunk nem biztos, hogy jól fogja felismerni az új böngészőt.

Az ASP.NET platformban is vannak olyan részek, amik tekintettel vannak a kliens böngészőjére, és sajnos korábban már volt rá példa, hogy egyes funkciók nem jól működtek az újabb böngészőkkel.

Szerencsére az ASP.NET böngésző detektáló része a .browser fájlok segítségével rugalmasan alakítható, amit az is jól mutat, hogy Windows 8.1-en a C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\Browsers mappában található ie.browser fájl már az új User-Agent stringnek megfelelő részt is tartalmaz:

<browser id="InternetExplorer" parentID="Mozilla">
   <identification>
     <userAgent match="Trident/(?'layoutVersion'[7-9]|0*[1-9]\d+)(\.\d+)?;(.*;)?\s*rv:(?'version'(?'major'\d+)(\.(?'minor'\d+)))" />
     <userAgent nonMatch="IEMobile" />
     <userAgent nonMatch="MSIE " />
   </identification>
   <capabilities>
     <capability name="browser"              value="InternetExplorer" />
     <capability name="version"              value="${version}" />
     <capability name="majorversion"         value="${major}" />
     <capability name="minorversion"         value="${minor}" />
     <capability name="layoutEngine"         value="Trident" />
     <capability name="layoutEngineVersion"  value="${layoutVersion}" />
     <capability name="type"                 value="InternetExplorer${major}" />
   </capabilities>
</browser>

A tapasztalatunk az, hogy érdemes tesztelni az új böngészővel a régi webalkalmazásokat, még akkor is, ha a saját kódunkba nem írtunk böngészőfüggő részeket, mert a platform is tartalmaz ilyeneket. Különösen akkor érdemes odafigyelni, ha a szerver oldalon még ASP.NET 4.0 van, tehát nem a legfrissebb 4.5 (amit az in-place upgrade miatt nem mindenhol mernek telepíteni).

Egy következő cikkben írok majd néhány konkrét ASP.NET-es problémáról, amibe belefutottunk IE11-gyel.

 

Technorati-címkék: ,,

Tesztelés több Internet Explorer verzión

Gyakran visszatérő kérdés, hogy hogyan lehet kényelmesen több Internet Explorer verzión tesztelni a weboldalunkat. A kérdés azért izgalmas, mert míg más böngészőket lehet  több verzióban egymás mellé telepíteni, addig az Internet Explorernek – mivel össze van nőve az operációs rendszerrel – csak egy verziója lehet a gépünkön.

Korábban írtam már erről, azonban azóta a lehetőségeink csökkentek:

Az IETester ugyan támogatja a Windows 8-at és az IE10-et, de elég lassan fejlődik, és a hiányosságai továbbra is megmaradnak.

A Microsoft Expression SuperPreview-t az egész termékcsaláddal együtt süllyesztőbe küldte a cég, nem fejlesztik tovább.

Az Internet Explorer Developer Toolbar jelentősen megváltozik. A Windows 8.1-ben megjelenő IE11-ben egy teljesen újraírt F12 DevToolst találunk, megújult dizájnnal és számos új funkcióval, azonban pont  a kompatibilitási tesztek terén van egy fájó pont. Korábban ugyanis – egészen az IE10-ig – volt egy remek funkció a Dev Toolbaron a korábbi böngészők emulálására:

IE10 Developer Toolbar: Browser Mode emulation

Ez egyszerűnek és jónak tűnik, csakhogy van vele pár gyakorlati probléma. Először is van mellette egy Document Mode választó is, nagyon hasonló opciókkal:

IE10 Developer Toolbar: Document Mode emulation

IQ-ból nem egyszerű rájönni, hogy melyik mire szolgál, de az IEBlog Testing Sites with Browser Mode vs. Doc Mode című cikkében értelmesen le van írva. Persze ez csak azoknak segít, akik elolvassák.

A másik probléma ezzel a megoldással, hogy sajnos nem teljesen tökéletes. A legtöbb kompatibilitási problémát valóban meg lehet találni vele, de mi is futottunk bele számtalan olyan esetbe, amikor a Dev Toolbaros verzió váltással nem találtunk meg egy hibát, ami viszont egy IE8-on előjött. Magyarul a módszer nem megbízható.

Mindezeket átgondolva az IE csapat úgy döntött, hogy az IE11-ben ezt a funkciót megszűntetik. Így néz ki az új Dev Toolbar Emulation füle:

IE11 Developer Toolbar Emulation tab

Látható, hogy számos új funkció megjelent, van például Desktop és Windows Phone Profile, már nem csak felbontást, hanem tájolást is lehet állítani, sőt van GPS szimuláció is. A böngésző verziókkal kapcsolatban van ugyan egy User Agent string kamuzó opció, sőt van egy Document mode is (ami lehet Edge vagy Default), de nem tudjuk átkapcsolni a böngésző motorját a korábbi verzió motorjára.

Mi a megoldás?

Az információ ikonra kattintva a modern.IE webhelyre juthatunk, azon belül is a Test Across Browsers oldalra, ahol két megoldás találhatunk:

1. A Microsoft a http://www.browserstack.com szolgáltatásait ajánlja, amihez 3 hónapos ingyenes hozzáférést biztosít. Ez az ajánlat 2014. január 10-ig érvényes!

2. Letölthetünk egy rakás előre konfigurált virtuális gépet. Csak a hoszt operációs rendszert és a virtualizációs platformot kell kiválasztanunk és máris tölthetjük lefelé az adott IE verzióval konfigurált Windowsos virtuális gépet:

modern-ie-vms

A Microsoft aktuális álláspontja szerint a virtuális gépek használata a legmegbízhatóbb megoldás a webes megoldások korábbi IE verziókban történő tesztelésére, és ehhez most minden eszközt meg is kapunk.

Ami pedig a jövőben megjelenő verziókat illeti, a javaslat természetesen a szabványok követése. Kezdetnek érdemes elolvasni Rey Bango és Dave Methvin 20 tippjét a modern weboldalak kontra régi IE verziók témában.

 

Technorati-címkék: ,,

Outlook Web App nem csak light verzióban IE 11 alatt

Aki frissített Windows 8.1-re és megpróbálta elérni az OWA-t Internet Explorer 11 alól, az valószínűleg szomorúan tapasztalta, hogy csak “light version”-ben hajlandó működni:

owa-light

Ez azért kínos, mert a light verziót pont a kőkorszaki böngészőkre találták ki, az IE11 viszont igen csak modern böngészőnek számít, még akkor is, ha csak preview állapotban van.

A megoldás, hogy az adott webhelyet compability mode-ban jelenítjük meg. Erre egyik lehetőség, hogy felvesszük a webhelyet a Compatibility List-re a Tools –> Compatibility View Settings ablakban:

compatibility-view-settings

Ez nálam annyira nem jött be, mert csak a top-level domain kerül be a listába. Így aztán kihasználtam, hogy az első jelölőnégyzet szerint az intranet oldalak alapértelmezés szerint kompatibilitási nézetben jelennek meg, és felvettem az OWA címét az Intranet zónába tartozó webhelyekhez a Tools –> Internet Options –> Security –> Local intranet –> Sites –> Advanced ablakban.

Fórum bejegyzések szerint hasonló probléma van az Office 365-tel és néhány népszerű weboldallal, például a GitHubbal is.

 

Technorati-címkék: ,,