2012. szeptember havi bejegyzések

Ingyenes e-book: Programming Windows 8 Apps with HTML, CSS, and JavaScript

windows8-js-ebook-coverKorábban említettem, hogy a Microsoft Press júniusban kiadott egy ingyenesen letölthető előzetest Kraig Brockschmidt Programming Windows 8 Apps with HTML, CSS, and JavaScript című könyvéből, ami a maga mindössze 4 fejezetével is elég jó forrásnak számított azok számára, akik JavaScriptben akartak Metro stílusú Windows 8 alkalmazást készíteni. Nemrég megérkezett a folytatás, a második előzetesben már 12 fejezetet kapunk. Íme az újdonságok:

  • Chapter 5: Collections and Collection Controls
  • Chapter 6: Layout
  • Chapter 7: Commanding UI
  • Chapter 8: State, Settings, Files and Documents
  • Chapter 9: Input and Sensors
  • Chapter 10: Media
  • Chapter 11: Purposeful Animations
  • Chapter 12: Contracts

Az első előzetes 158 oldalas volt, a második már 537, és mire az október végi Buildre elkészül mind a 17 fejezet, súlyos mű válik belőle.

A második előzetes ingyenesen letölthető:

Akit nem érdekel ilyen mélyen a téma, vagy csak most vág bele a Windows 8 programozásba, annak a Beginning Windows 8 Application Development könyvet tudom ajánlani a Wrox kiadótól. Ebben körülbelül 70 oldal foglalkozik a JavaScriptes Windows 8 programozással, hasonló témákat érintve, mint az MS Press könyve, természetesen kevésbé mélyen tárgyalva. fog Bár ez a könyv hivatalosan csak jövő héten jelenik meg, már előrendelhető az Amazonnál.

 

Technorati-címkék: ,,

WCF szolgáltatás publikálása IIS 8-on

Egy alapbeállításokkal telepített IIS 8-on nem működnek a WCF szolgáltatások, mégpedig azért, mert a webszerver nem tudja, hogyan kell kezelnie az .svc kiterjesztésre érkező kéréseket. Két lépésben taníthatjuk meg neki:

 

1. Vegyünk fel egy új MIME type-ot:

Extension: .svc
MIME type: application/octet-stream

iis8-svc-mime-type

 

2. Vegyünk fel egy Managed HTTP Handlert:

Request path: *.svc
Type: System.ServiceModel.Activation.HttpHandler
Name: svc-Integrated

iis8-svc-handler

És már működik is!

 

Technorati-címkék: ,,

.NET Framework 3.5 telepítése Windows 8-ra és Windows Server 2012-re

SQL Server 2012-t telepítettem Windows Server 2012-re, és látszólag minden a szokásos módon zajlott. Az előkövetelmények ellenőrzése simán megtörtént, ám a telepítés közepén jött egy figyelmeztetés, hogy szükség van .NET Framework 3.5-re. Mivel a dialógus ablakon mindössze egy OK gomb volt, csak bízhattam benne, hogy az operációs rendszerrel települő .NET 4.5 is megfelelő lesz. Hát nem lett, az SQL telepítés nem sikerült. Aztán kiderült, hogy a .NET Framework 3.5 telepítése nem is olyan egyszerű…

Windows 8-ban és Windows Server 2012-ben a .NET Framework 3.5 ún. Feature on Demand. Ez azt jelenti, hogy az operációs rendszerrel csak a telepítéshez szükséges metaadatok települnek, a szükséges binárisok nem. Azokat máshonnan kell beszereznünk.

 

Windows 8

Windows 8 esetén nyissuk meg a Programs and Features ablakot, amit szerintem legegyszerűbben a Windows+X-es rendszergazdai menüből tehetünk meg:

net35-windows8-1

Pipáljuk be a .NET Framework 3.5 (includes .NET 2.0 and 3.0) sort, majd kattintsunk az OK-ra. Jön egy kis keresgélés:

net35-windows8-2

Majd a kérdés, hogy indulhat-e a letöltés a Windows Update-ről:

net35-windows8-3

Biztos én vagyok túl igényes, de nekem innen nagyon hiányzik, hogy mégis mennyit akarna letölteni és hogy meg lehessen adni másik útvonalat. Ha valóban akarunk .NET 3.5-öt, akkor kattintsunk a Download files from Windows Update gombra. Jön egy kis töltögetés:

net35-windows8-4

Majd ha pechünk van, akkor ez a képernyő:

net35-windows8-5

A Tell me how to solve this problem link kivételesen egészen hasznos, ugyanis a KB2734782 cikkre (Error codes when you try to install the .NET Framework 3.5 in Windows 8 or in Windows Server 2012) visz, ami valóban tud segíteni. Nálam az volt a gond, hogy a gép tartományban van, csoportházirend tolja le rá a WSUS beállításokat.

Mivel nem volt lehetőségem ezen módosítani, maradt a másik megoldás, parancssorból telepíteni a Frameworköt. Szerencsére a .NET 3.5 megtalálható a Windows 8 telepítő médián, parancssorból így kell telepíteni:

dism /online /enable-feature /featurename:NetFx3 /All /Source:D:\sources\sxs /LimitAccess

Pillanatok alatt megtörténik, biztosan gyorsabb, mint Windows Update-ről:

net35-windows8-6

 

Windows Server 2012

A dism-es, parancssoros telepítés tökéletesen működik Windows Server 2012 esetén is, a szükséges fájlok ott is megtalálhatók a telepítő lemezen. Szerencsére itt GUI-n is meg tudjuk oldani a telepítést. Ehhez indítsuk el az Add Roles and Features Wizard-ot és jelöljük be a .NET Framework 3.5 Features opciót (katt a teljes képért):

net35-ws2012-1

A Next után a következő oldalon találunk egy végigolvashatatlan sárga hibaüzenetet:

net35-ws2012-2

A hibaüzenet azt akarja mondani, hogy ha kicsivel több esélyt akarunk magunknak a sikeres telepítésre, akkor alul kattintsunk a Specify an alternate source path linkre:

net35-ws2012-3

A sok szöveg lényege, hogy adjuk meg a telepítő fájlok helyét, például D:\Sources\SxS:

net35-ws2012-4

Innen már simán végigmegy a varázsló és az SQL Server is gond nélkül települ.

 

Napi .NET kvíz

Mit ír ki:

using System;
using System.Collections.Generic;

public class Program
{
  static void Main()
  {
    var funcs = new List<Func<string>>();
    var urls = new List<Uri>
    {
      new Uri( "http://google.com" ), 
      new Uri( "http://bing.com" )
    };

    foreach( var u in urls )
    {
      funcs.Add( () => u.ToString() );
    }

    foreach( var f in funcs )
    {
      Console.WriteLine( f() );
    }
  }
}

Kis segítség a ReSharpertől:

resharper-warning

Ahogy a figyelmeztetés mondja, ez a kód bizony másként viselkedik C# 4.0 és C# 5.0 fordítóval! Valójában ez az egyetlen breaking change C# 5-ben.

Bár a probléma nem új (Eric Lippert már 3 éve írt róla), a fenti kódrészletet nem én találtam ki. Martin Doms blogjából kölcsönöztem, aki napi kvíz sorozatot indított .NET témában és ez az egyik feladvány (#006). A sorozat már harmadik hete tart és Martinnak sikerül igen jó kérdéseket összeszedni, amiket akár egy haladóbb .NET állásinterjú kérdéssorban is el tudnék képzelni.

A sorozat epizódjai legegyszerűbben talán a http://blog.martindoms.com/tag/quiz/ oldalon keresztül érhetők el.

Nektek melyik tetszik legjobban?

 

Technorati-címkék: ,

SQL Server publikálása más porton

Ha félünk attól, hogy a 1433-as port túlságosan is közkedvelt célpontja a támadóknak és kártevőknek, publikálhatjuk az SQL Serverünket más porton is. Ehhez nyissuk meg az SQL Server Configuration Managert, majd navigáljunk el az SQL Server Network Configuration –> Protocols for [instance neve]> TCP/IP ágig, majd nyissuk meg a Properties ablakot (katt a teljes képért):

sql-port-configuration-manager

Itt a második, IP Addresses fülön tudjuk beállítani, hogy az SQL példányunk milyen IP címeken és milyen portokon legyen elérhető, például áttehetjük akár a 8765-ös portra is:

sql-port-tcp-properties

Természetesen ezt a portot ki kell nyitnunk a tűzfalon. Megtehetjük azt, hogy a tűzfal szabályok közé is bevéssük a port számot, de akár az SQL Server processznek is engedélyezhetjük a kommunikációt, így egyszerűbb lesz az életünk. A Windows Firewall with Advanced Security mmc-ben az Inbound Rule-ok közé vegyünk fel egy új szabályt a New Rule… gomb megnyomásával. Itt jön a trükk: ne portot nyissuk, hanem a Program-ot:

sql-port-firewall-1

És adjuk meg az adott SQL példányhoz tartozó sqlservr.exe elérési útját:

sql-port-firewall-2

A varázsló többi lépése a szokásos, üssük ki a téglát a tűzfalon.

Ha nem az alapértelmezett porton fülel a szerver, honnan fogják tudni a klienseink, hogy hova kell kapcsolódniuk? Épp erre szolgál az SQL Browser Service, ami nevesített SQL példányok esetén elárulja a kliensnek a példány portját. Viszont nem sokat érnénk a port változtatással, ha az SQL Browser Service-t elérhetővé tennénk és így bárki automatikusan lekérdezhetné a példányhoz tartozó port számát. Nincs más hátra, mint a kapcsolat tulajdonságai között kézzel megadni a portot. Vigyázat, szokatlan a szintaktika, nem kettőspont kell, hanem vessző a példány neve után:

sql-port-connection

A port megadása persze kényelmetlennek tűnhet, de szerencsére ezt csak távolról kell megtennünk, hiszen a tűzfal mögött bátran futtathatjuk az SQL Browser Service-t, így az SQL Serveren futó alkalmazások a port megadása nélkül meg fogják találni az adatbázis kiszolgálót.

 

Technorati-címkék: ,

SSL TDS alá, avagy az SQL kapcsolat titkosítása

Ha az SQL klienseink (például a fejlesztők Management Studioi) és az SQL szervereink nem egymás közelében helyezkednek el, akkor praktikus, ha az SQL Server által használt tabular data stream (TDS) protokoll alá SSL-t teszünk.

Első lépésként természetesen egy érvényes tanúsítványra lesz szükségünk. Fontos, hogy a tanúsítványon szereplő névnek pontosan meg kell egyeznie a szerver nevével. Az egyezést az SQL Server DNS lekérdezéssel ellenőrzi, ezért lehetőleg ne bonyolítsuk az életünket DNS aliasokkal vagy DNS utótag bűvészkedéssel. A másik fontos dolog, hogy a tanúsítvány megbízható kiadótól származzon, amiben a szerver és a kliens is megbízik.

A kész tanúsítványt importáljuk be a Local Computer account Personal Certificates tárába. Ezt legegyszerűbben úgy tehetjük meg, ha elindítjuk az MMC-t, hozzáadjuk a Certificates snap-int és a hozzáadáskor kapott kérdésre azt választjuk, hogy a Computer account érdekel minket. Ezek után a Personal\Certificates ágon a helyi menüben találjuk az Import menüpontot (katt a teljes képért):

sql-ssl-import

A következő lépés, hogy az SQL Servert futtató felhasználói fióknak jogot adunk a tanúsítvány elérésére. Ehhez a jobb oldali panelen jelöljük ki a tanúsítványt, majd a helyi menüben válasszuk a All Tasks –> Manage Private Keys… menüpontot:

sql-ssl-acl

Eredményül egy szokásos ACL konfiguráló ablakot kapunk. Kattintsunk az Add gombra és válasszuk ki azt a fiókot, akinek a nevében az SQL Server instance-ünk fut. Az SQL Server 2012 már alapértelmezés szerint saját service account nevében fut, ezt NT Service\MSSQL$instanceneve formában adhatjuk meg, majd adjunk neki Read jogot (nem kell Full control!):

sql-ssl-ace

Indítsuk el az SQL Server Configuration Managert és navigáljunk el az SQL Server Network Configuration –> Protocols for [instance neve] ágig, majd nyissuk meg a hozzá tartozó Properties ablakot:

sql-ssl-properties

Kattintsunk át a második, Certificate fülre és válasszuk ki a használni kívánt tanúsítványt:

sql-ssl-properties-certificate

Ha nem jelenik meg a tanúsítvány a listában, akkor gond van, ellenőrizzük a tanúsítványt, a névfeloldást és a jogosultságokat.

Visszalépve az első, Flags fülre, a Force Enryption kapcsoló Yes-re állításával kikényszeríthetjük a titkosítást:

sql-ssl-properties-force-encryption

Ebben az esetben csak azok a kliensek tudnak majd a szerverhez kapcsolódni, akiknél a connection stringben szerepel az Encrypt=True; beállítás. Amennyiben a kliens SQL Server Management Studio, a titkosítást a Connection Properties fülön az Encrypt connection kapcsoló bejelölésével engedélyezhetjük:

sql-ssl-ssms-encrypt

A titkosítás működését ellenőrizhetjük Wiresharkkal, de akár az SQL Servertől is megkérdezhetjük, hogy melyik kapcsolat van titkosítva. Ehhez a sys.dm_exec_connections view encrypt_option oszlopa a hiteles forrás. Ezzel a lekérdezéssel a kapcsolat legfontosabb paramétereit tekinthetjük át:

SELECT session_id, net_transport, client_net_address, local_net_address, 
       local_tcp_port, auth_scheme, encrypt_option 
FROM sys.dm_exec_connections

Ha az encrypt_option oszlopban TRUE-t látunk, megnyugodhatunk.

 

Technorati-címkék: ,,,

HTML5 MIME típusok IIS 8-on

Ha IIS 7/7.5 alatt olyan alkalmazást futtattunk, amely intenzíven használt HTML5-közeli fájl típusokat, akkor bizony a hozzájuk tartozó kiterjesztéseket fel kellett vennünk az IIS MIME Types listájába, különben a webkiszolgáló nem volt hajlandó kiszolgálni az ilyen fájlokra érkező kéréseket. Például így:

<staticContent>
  <mimeMap fileExtension=".mp4" mimeType="video/mp4" />
  <mimeMap fileExtension=".m4v" mimeType="video/m4v" />
  <mimeMap fileExtension=".ogg" mimeType="video/ogg" />
  <mimeMap fileExtension=".ogv" mimeType="video/ogg" />
  <mimeMap fileExtension=".webm" mimeType="video/webm" />
  <mimeMap fileExtension=".oga" mimeType="audio/ogg" />
  <mimeMap fileExtension=".spx" mimeType="audio/ogg" />
  <mimeMap fileExtension=".svg" mimeType="image/svg+xml" />
  <mimeMap fileExtension=".svgz" mimeType="image/svg+xml" />
  <remove fileExtension=".eot" />
  <mimeMap fileExtension=".eot" mimeType="application/vnd.ms-fontobject" />
  <mimeMap fileExtension=".otf" mimeType="font/otf" />
  <mimeMap fileExtension=".woff" mimeType="font/x-woff" />
</staticContent>

Ez szép és jó, de sajnos amikor frissítjük a szervert IIS 8-ra, akkor az IIS egy gyönyörű 500.19 Internal Server Error hibával fog megörvendeztetni minket.

iis8-duplicate-mime-type

Ha bekapcsoljuk a részletes hibaüzenet megjelenítését, akkor láthatjuk, hogy a hiba:

Cannot add duplicate collection entry of type ‘mimeMap’ with unique key attribute ‘fileExtension’ set to ‘.4v’

Mindez annak köszönhető, hogy az IIS 8 már több MIME típust ismer, ráadásul ezek szerver szinten vannak beállítva, így minden website örökli őket.

A megoldás természetesen az, hogy a saját web.configunkból töröljük a problémás sorokat. Nálam ezek váltak feleslegessé:

mp4, m4v, m4a, ogv, oga, ogg, webm, spx, svg, svgz, otf, woff

Ne felejtsétek el frissíteni a telepítőket!

 

Technorati-címkék: ,,