Code selbst signieren - Teil 1 (Beispiel: Gadgets verpacken) Monday, August 27, 2007 11:25 PM Toni Pohl Programm-Code kann selbst mit einem Zertifikat versehen werden um den Herausgeber zu verifizieren. Im ersten Teil dieses Beitrags erfahren Sie anhand eines Sidebar Gadgets, wie dieses vorbereitet werden kann und Sie erfahren Wissenswertes über die Gadget-Technologie. Viele von uns verwenden sie bereits täglich und wollen sie nicht mehr missen: die Windows Vista Sidebar Gadgets. Nützliche kleine Tools, um rasch Informationen in den verschiedensten Bereichen zu erhalten, sei es den Wetterbericht, Aktienkurse, die Rechnerauslastung, Outlook-Infos oder RSS-Feeds. Sidebare Gadgets können relativ einfach erstellt werden und sind in Wahrheit nichts anderes als gezippte Dateien mit der Endung .gadget. (Probieren Sie es aus: Benennen Sie eine heruntergeladene Datei von .gadget in .zip um und entpacken Sie das Zip - voila.)Beim Ausführen einer *.gadget-Datei wird diese in das eigene Application Directory entpackt: C:\Users\<username>\AppData\Local\Microsoft\Windows Sidebar\Gadgets\<gadgetname> Eine Manifest-Datei gadget.xml beschreibt das Gadget, die Funktionalität besteht im Wesentlichen meist aus HTML-Seiten, Javascript und einigen Images. Soweit so gut. Die meisten Gadgets besitzen allerdings keinen Hinweis über den Herausgeber der Software - smybolisiert mit dem roten Schild. Ist ein zu installierendes Gadget wirklich vertrauenswürdig? Wer hat es programmiert und wie können wir sicherstellen, dass es sich um nicht um schädlichen Code handelt? Nun, zu schädlichem Code muss gesagt werden, dass Gadgets in einem eigenen geschützten Bereich laufen und nur zu bestimmten Teilen des Rechners Zugriff erhalten - hier besteht im Regelfall keine Sorge, dass ein Gadget wirklich "Böses" ausführen kann - dennoch sollten Entwickler einige Richtlinien beachten. Wir gehen davon aus, dass Sie den Code, welchen Sie verteilen wollen, sicher ist. :-) Aber wie kann nun die Installationsquelle "sicher" gemacht werden, damit die Anwender auf die Identität des Herausgebers vertrauen können? Wenn Sie Entwickler eines Gadgets oder IT-Pro mit dem Ziel einer sicheren Verteilung sind, benötigen Sie ein Zertifikat. Keine Sorge, wenn Sie kein "offizielles" Zertifikat besitzen, das können Sie sich auch einfach selbst erstellen. Gadgets werden im Regelfall als einfache Zip-Dateien geliefert. Schritt eins ist, statt eines Zip-Files ein .CAB-File (=Microsoft Cabinet File, ein gepacktes Archiv zur Software-Verteilung) zu erstellen. Warum? Weil .CAB-Dateien signiert werden können! Dazu benötigen wir das Microsoft Cabinet Software Development Kit. Ein Hinweis, worüber auch ich anfangs gestolpert bin: CAB-Dateien können nicht mit Visual Studio erzeugt werden, weil Visual Studio in CAB-Projekten keine Verzeichnisstruktur speichern kann - diese wird für Gadgets aber benötigt. Daher empfiehlt sich der Einsatz des Microsoft Cabinet SDK! Laden Sie Cabsdk.exe herunter und entpacken diese Datei in ein temporäres Verzeichnis. Die extrahierten Dateien werden in einen allgemeinen Folder kopiert, damit die Tools im PATH gefunden werden können (wenn Sie Visual Studio 2005 installiert haben, empfiehlt sich das Verzeichnis C:\Program Files\Microsoft Visual Studio 8\VC\bin). Nun das Visual Studio 2005 Command Prompt starten und in das Verzeichnis des Gadgets navigieren. Nun wird das Gadget in eine neue .CAB-Datei gepackt: cabarc -p -r N pwdgen.gadget * Ersetzen Sie "pwdgen.gadget" durch den gewünschten Gadget-Namen.-p behält die Verzeichnis-Struktur, -r steht für rekursiv und N für ein neues Archiv. Als Ergebnis erhalten Sie eine neue Datei pwdgen.gadget. Es handelt sich hierbei um eine gepackte Datei vom Typ CAB, welche signiert werden kann - aber nicht muss. Das Gadget kann nun (genauso wie auch .gadgets vom Typ Zip) verteilt werden. Damit wäre der erste Schritt - das Packen des Gadgets - erfüllt. In Teil Zwei sehen wir uns an, wie wir das CAB-Gadget (oder beliebigen anderen Code) mit einem eigenen Zertifikat versehen können! Beitrag von Toni Pohl Developer | Security | Tools Mediumlink | Permalink | Comments (0) | Post RSS mehr
HowTo Script in PowerShell Wednesday, August 8, 2007 1:40 AM Toni Pohl Langsam wird die neue PowerShell immer populärer. Im Windows Server 2008 ist die PowerShell bereits in der Evaluation Version inkludiert. Für alle anderen Windows Betriebssysteme muss die PowerShell 1.0 heruntergeladen und installiert werden (Voraussetzung ist nur das Vorhandensein des .NET Framework 2.0). Seit Ende Jänner ist die finale Version verfügbar, nun gibt es seit dem 31. Juli für die Benutzer der MUI Versionen von Windows XP und Windows Server 2003 eine PowerShell Version für x86, x64 und Server IA64 hier zu laden. (Hinweis: Die MUI Language Packs laufen nur unter den MUI Versionen von Windows. Zuerst muss die englische Version der PowerShell 1.0 installiert werden und danach das Language Pack for Windows PowerShell 1.0.) Die PowerShell arbeitet vollständig objektorientiert. Wie bei anderen Shells gibt es eine Pipeline, in der Ergebnisse von Befehlen an andere Kommandos weitergegeben und weiterverarbeitet werden können. Für alle jene, die sich die PowerShell noch nicht angesehen haben und einmal selbst drauflosprobieren wollen hier eine Quick-Start-Anleitung für das schnelle Erfolgserlebnis. Nach dem Download erfolgt die Installation zügig: Der Aufruf der PowerShell erfolgt einfach über den Pearl-Button und Aufruf der PowerShell (C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.exe): Und schon geht´s los mit einfachen Kommandos: get-process Die PowerShell besitzt vielleicht den Charme der Eingabeaufforderung, bietet unter der Haube aber ein völlig neues Konzept der Administration von Windows-Rechnern und eine neue, zusätzliche Plattform der Automation. Beim Aufruf von Scripts lauert ein Stolperstein: Das gewohnte Ausführen von Scripts mit der Erweiterung .ps1 öffnet bei Ausführung das Script im Notepad und startet nicht (wie vielleicht von Windows Scripting Host gewohnt) das Script! Als Abhilfe hier nun die Schnellanleitung zum Handling und Testen eines einfachen Scripts in der PowerShell: Zuerst wird (außerhalb der PowerShell) ein neues Textfile mit Notepad mit einer Zeile (zur Anzeige der Betriebssystem-Version mit gwmi win32_operatingsystem) erstellt: Das File wird in C:\Script\test1.ps1 gespeichert. Nun, wie wechselt man (in der PowerShell) das Verzeichnis? cd C:\Scriptdir Microsoft hat übrigens auch Altbewährtes - Flashback! ;-) - aus einer anderen Welt übernommen: pwd, chdir, ls, ... Logisch erscheint, nun einfach das Script test1.ps1 aufzurufen... Das klappt aber so noch nicht. Warum? Die PowerShell verwendet eine "excution policy", welche verhindert, dass nicht signierte Scripts aufgerufen werden (versuchen Sie mal Get-ExecutionPolicy um anzusehen welche Policy eingestellt ist oder Get-Help About_Signing). Das bedeutet, wir stellen mal die Policy auf "RemoteSigned" ein: Set-ExecutionPolicy RemoteSigned Neuerlicher Aufruf von test1.ps1... es klappt noch immer nicht. Durch das Ändern der Policy ist es möglich, Scripts aufzurufen. Allerdings - obwohl wir uns im richtigen Verzeichnis befinden - behandelt die PowerShell Pfade anders als gewohnt. Das bedeutet, es muss immer der Pfad zum Script mit angegeben werden: C:\Script\test1.ps1 (oder kürzer mit ".\":) .\test1.ps1 Nun funktioniert der Aufruf! Wenn C:\Script im PATH vorhanden ist, kann die Pfadangabe entfallen. Um den aktuellen PATH auszugeben, verwenden Sie beispielsweise $env:path und zerlegen diesen mit Split(";") nach dem Trennzeichen ";" in einzelne Elemente:$a = $env:path; $a.Split(";") Hinweis: $-Zeichen definieren übrigens Variablen. D.h. $a wird der Environment-Variable zugewiesen und gibt im zweiten Teil die Variable aus. Nachdem es sich um .net Objekte handelt, sind deren Eigenschaften und Methoden (wie hier .Split verwendbar). Dies ist auch die Stärke der PowerShell, dass fast alle .net-Objekte verwendbar und "pipe-able" (weiterverwendbar) sind. Um dem PATH eigene Verzeichnisse hinzuzufügen verwenden Sie:$env:path = $env:path + ";c:\scripts" Achja noch ein Tipp: Bei Script-Aufrufen in Pfaden mit Leerzeichen muss der Pfad - wie gewohnt - in "C:\Mein Script\test1.ps1" eingefasst werden UND dieser "String" mit dem & - Zeichen als Call-Operator aufgerufen werden: & "C:\Mein Script\test1.ps1" Und wie kann man nun ein PowerShell-Script außerhalb der PowerShell aufrufen? Die Lösung ist einfach: Aufrufen der PowerShell mit dem Script (und der optionalen Anweisung -noexit, damit die PowerShell geöffnet bleibt): powershell.exe -noexit c:\script\test1.ps1 Das wars! Mit diesem Handwerkszeug steht die Basis zum Experimentieren mit PowerShell Scripts bereit und die Fülle an bereits verfügbaren Scripts kann getestet und angepasst werden. Das Windows PowerShell Owner's Manual liefert die ersten Informationen zur Verwendung der PowerShell, das Windows PowerShell 1.0 Documentation Pack eine Getting Started-Dokumentation. Zum Einstieg empfehle ich u.a. die Links Scripting with Windows PowerShell im Microsoft Script Center und das Blog des PowerShell Teams sowie den Download des Windows PowerShell Graphical Help File (PowerShell.chm). Es gibt auch bereits eine deutschsprachige community mit einem Angebot an News, Informationen, Blogs und Tutorials. In diesem Sinne wünsche ich viel Spaß beim Entdecken der Fähigkeiten der PowerShell und beim Scripten! Beitrag von Toni Pohl Developer | Microsoft | Tools Mediumlink | Permalink | Comments (0) | Post RSS mehr
Visual Studio 2008 Beta 2 und .NET 3.5 Beta 2 verfügbar Saturday, July 28, 2007 10:37 AM Toni Pohl Brandaktuell hat Microsofts .NET Visionär Scott Guthrie, General Manager der Microsoft Developer Division, am 26. Juli in seinem Blog die Verfügbarkeit von Visual Studio 2008 Beta 2 und von .NET 3.5 Beta 2 angekündigt. Unter anderem beschreibt Scott in seinen "Installation Notes" auch einige Fallstricke und Neuerungen von VS 2008. Mehr Infos sind auch in Scott´s Präsentationen zu finden. Hier gehts zum Download des VS 2008, alternativ finden Sie hier die Express Editions Visual Basic, Visual C#, Visual C++ und Visual Web Developer 2008. Es gibt auch bereits weitere Erfahrungsberichte zur Installation des VS 2008 Beta 2. Die Beta 2 soll nahezu "feature complete" sein, ein Whitepaper gibt Überblick über die neuen Funktionen von VS 2008 (Orcas). Beitrag von Toni Pohl Developer | Microsoft Mediumlink | Permalink | Comments (0) | Post RSS mehr
Neues im SQL Server 2008 - your data any place, any time Thursday, July 26, 2007 8:59 AM Toni Pohl Der SQL Server 2005 war bereits ein Meilenstein in der Geschichte der Datenbanksysteme. Microsoft hat nun seine Vision der Application Server wieder stark erweitert und die neue Version SQL Server 2008 angekündigt. Die aktuelle Version SQL Server 2008 June CTP sowie Dokumentationen, Infos und Webcasts finden Sie hier. Es gibt mittlerweile schon einige Webseiten mit Informationen über die neuen Funktionen und Erweiterungen des SQL Server 2008. Dort liest man von den vier Hauptthemen "Mission Critical", "Pervasive Insight", "Dynamic Development" und "Beyond Relational". Nur, was bedeuten diese Begriffe? Microsoft sieht in der Version 2008 die neue Basis als Datenplattform für die nächste Generation von Datengesteuerten Applikationen - eine "große" Sicht der Dinge und "simple as that". ;-) Hier eine kurze Zusammenfassung der neuen Funktionen des SQL Server 2008: Mission Critical: Sicherheit durch Verschlüsselung, Skalierbarkeit und hohe Verfügbarkeit, Systemadministration, hohe Stabilität und Ressourcen-Planung (Transparent data encryption, Extensible key management, Hot Add CPU, Policy-based Management, Declarative Management Framework, Streamlined installation, Optimized and Predictable System Performance, Resource Governor für Workload-Management) Pervasive Insight: Business-Intelligence (BI) Optimierungen und Erweiterungen, schnellere Berechnungen bei höherem Datenvolumen (Data compression, Partitioned table parallelism, MERGE SQL, Scaleable SSIS, Scalable Analysis Platform, Scalable Reporting, Rich Information Experiences) Dynamic Development: Rasche Entwicklung, flexible neue Datentypen, Offline-Szenarien durch neue Synchronization Services in ADO.NET und Offline Designers in Visual Studio (ADO.NET, CLR, LINQ, Occasionally Connected Systems) Beyond Relational: Verwalten von unstrukturierten Daten, neue Datentypen (z.B. das langersehnte "nur" DATE und TIME, kein 8KB Limit für user-defined types), Fulltext über mehr Datentypen (Store Any Type of Data, Location Intelligence für geographische Informationen) Zum Thema BI: Der SQL Server 2008 soll besonders gut mit Analyse-Werkzeugen wie Excel 2007, ProClarity, SharePoint Server 2007 und dem Office PerformancePoint Server 2007 zusammenarbeiten. Eine Beschreibung der neuen Funktionen finden Sie im White Paper Product Overview SQL Server 2008 (englisch). Beitrag von Toni Pohl Developer | Microsoft Mediumlink | Permalink | Comments (0) | Post RSS mehr
SQL Server Builds und Versionen identifizieren Saturday, July 21, 2007 6:20 AM Toni Pohl Wissen Sie, welche Version von Microsoft SQL Server auf einer Maschine läuft? Im SQL Management Studio sehen Sie neben der verbundenen Instanz die Versionsnummer, zum Beispiel 9.00.3042 wenn Sie SP2 installiert haben. Die Version Developer, Standard, Enterprise, etc. sowie die Build-Nummer finden Sie im SQL Server 2005 in den Eigenschaften der SQL Instanz und im Menü Hilfe/Info. Die TSQL-Abfrage select @@VERSION liefert ebenfalls die aktuelle Version der SQL Server-Instanz, beispielsweise Microsoft SQL Server 2005 - 9.00.3054.00 (Intel X86) Mar 23 2007 16:28:52 Copyright (c) 1988-2005 Microsoft Corporation Developer Edition on Windows NT 6.0 (Build 6000: ) oder etwas besser lesbar mit SELECT SERVERPROPERTY('productversion'), SERVERPROPERTY ('productlevel'), SERVERPROPERTY ('edition') zeigt beispielsweise 9.00.3054.00, SP2, Developer Edition. Hier die zusammengefassten SQL Server Versionen im Überblick: RTM/No SP SP1 SP2 SP3 SP4 SQL Server 2005 9.00.1399 9.00.2047 9.00.3042 SQL Server 2000 8.00.194 8.00.384 8.00.532 8.00.760 8.00.2039 SQL Server 7.0 7.00.623 7.00.699 7.00.842 7.00.961 7.00.10 Quelle: KB-Artikel 312185 - Ermitteln der SQL Server-Version und -Edition (englische Version hier) Der KB-Artikel 937137 von Ende Juni 2007 (englische Version hier) gibt Auskunft über alle Builds, welche nach SP2 veröffentlicht wurden! Alle SQL Service Packs sind kumulativ, das bedeutet, dass alle Updates und Fixes bis zum Zeitpunkt des Service Packs im Service Pack enthalten sind. Damit kann zum Beispiel eine frisch installierter SQL Sever 2005 sofort auf Stand SP2 gebracht werden. Beim Update eines Service Packs für SQL Server 2005 gilt dies im Gegensatz zu SQL Server 7 und 2000 für alle SQL Dienste auf der Maschine und die Offline-Dauer ist sehr gering. Einige weitere brauchbare Links und eine komplette Liste der SQL Server Builds mit einer kurzen Beschreibung der Fixes und Link zur ausführlichen KB-Beschreibung finden Sie u.a. in den Blogs hier (englisch): http://ianblythmanagement.wordpress.com/2006/12/11/sql-versions/ http://www.aspfaq.com/sql2005/show.asp?id=20 http://sqlserverbuilds.blogspot.com/ (Liste der Fixes mit KB-Links) Beitrag von Toni Pohl Developer | Microsoft Mediumlink | Permalink | Comments (0) | Post RSS mehr
Orcas und Katmai Saturday, June 23, 2007 10:00 AM Toni Pohl ...heißen seit der TechEd 2007 Anfang Juni in Orlando nun offiziell Visual Studio 2008 (Codename Orcas) und SQL Server 2008 (Codename Katmai). Microsoft hat damit die bewährte Namensgebung für die neuen Produkte verwendet.Visual Studio 2008 soll schon gegen Ende dieses Jahres verfügbar sein, SQL Server 2008 wird voraussichtlich Mitte des kommenden Jahres erscheinen. Zum Testen sind bereits Beta-Versionen und Community Technology Previews (CTP) verfügbar. Zur aktuellen Version Visual Studio 2008 Beta 1 passend gibt´s auch schon das VS SDK Orcas June 2007 CTP. Weitere Informationen, Whitepapers, Webcasts und Highlights zum SQL Server 2008 und den Download-Link des SQL Server 2008 June 2007 CTP finden Sie in den "Future Version" Seiten. Die Installation der CTP wird derzeit unter Windows Server 2003 (x86, 32 und 64bit) und Windows XP empfohlen. Hier ist ein "SQL Server Katmai Book Online" (BOL) zu dieser Version verfügbar. Beitrag von Toni Pohl General | Developer | Microsoft Mediumlink | Permalink | Comments (0) | Post RSS mehr
Kill Task per Script Monday, June 18, 2007 10:00 AM Toni Pohl Für administrative Zwecke, zum Beispiel für automatisierte Backups, Scheduled Tasks o.ä. ist es manchmal erforderlich, bestimmte Applikationen per Script zu beenden. Letztlich hatte ich genau so eine Anforderung: Outlook sollte für das Backupen der OST-Datendatei geschlossen werden. Als Lösung wird ein simpler Aufruf von Windows Management Instrumentation (WMI) verwendet, welcher abfragt, ob ein Prozess mit einem bestimmten Namen läuft und diesen terminiert: ' killtask.vbs by TP' simple script for killing a proccess task.pgm = "Outlook.exe" set wmi = getobject("winmgmts:") sQuery = "select * from win32_process " &_ "where name='" & pgm & "'" set processes = wmi.execquery(sQuery) for each process in processes process.terminate next ' decomment for user info:' msgbox pgm & " closed.", vbinformation Öffnen Sie Notepad oder einen ähnlichen Texteditor, kopieren Sie das obige Script hinein, passen Sie den Applikationsnamen an (z.B. Outlook.exe) und speichern Sie das Script "killtask.vbs" ab. Dann einfach Outlook starten und mit Doppelklick ausprobieren! Hinweis: Wenn in der zu schließenden Applikation ungesicherte Dokumente geöffnet sind, sind diese durch das Beenden verloren! D.h. wenn Sie beispielsweise "Winword.exe" mit dem Script beenden und es ist ein neues oder geändertes Dokument offen, wird dieses ohne Sicherheitsabfrage geschlossen und der Inhalt ist verloren. Das war aber auch nicht Zweck dieses Scripts ;-). Interessierte finden in WMI als Bestandteil des Windows Betriebssystems eine riesige Spielwiese für allerlei brauchbare Automatisierungen. Viele interessante Scripts und Informationen finden sich u.a. im Script Center. PS: Ein ganz heißes Nachfolge-Thema für Scripting und Automatismen ist die Microsoft Powershell! Viel Spaß beim Scripten! Beitrag von Toni Pohl Developer | Tools Mediumlink | Permalink | Comments (0) | Post RSS mehr
TFS offline Thursday, June 14, 2007 10:00 AM Toni Pohl Ein kleiner Ausflug in den Praxisalltag eines Developers mit Visual Studio Team System: Wer - so wie ich - viel mit Visual Studio 2005 arbeitet, lernt schnell die Vorzüge von Team Foundation Server (TFS) schätzen. TFS integriert sich nahtlos in Visual Studio und bietet automatische Quellcode-Verwaltung, Versionierung, Dokumentation und vor allem gemeinsames Arbeiten in einem Entwicklungsteam - fast ein "Must Have" für Projektteams, die mit Visual Studio 2005 arbeiten. Sobald man jedoch beispielsweise mit seinem Notebook die gewohnte Netzwerkumgebung verlässt und an einer Solution weiterentwickelt, hat der Anwender die Möglichkeit, unter TFS verwaltete Projekte temporär oder dauerhaft zu entfernen. Üblicherweise wählt man hier "temporary uncontrolled" und überschreibt die lokalen Dateien durch die geänderten Version(en). Bislang hatte ich allerdings Probleme, die offline veränderten Dateien bei der Rückkehr ins Netzwerk wieder in TFS einzuchecken und sie somit wieder für das Projektteam verfügbar zu machen. TFS markiert alle Dateien, welche unter TFS-Kontrolle stehen, mit dem ReadOnly-Attribut. Geänderte Dateien haben allerdings das ReadOnly-Attribut ausgeschalten und TFS erkennt diese nicht als geändert an. Abhilfe für diese Situation schaffen die "Microsoft Visual Studio 2005 Team Foundation Server Power Tools" von http://msdn2.microsoft.com/en-us/vstudio/aa718351.aspx. Hier ist unter anderem ein Command Line Tool tfpt.exe enthalten, welches Dateien für TFS modifizieren kann. Nach der simplen Installation empfiehlt es sich, den Programmpfad zum Umgebungspfad hinzuzufügen: Öffnen Sie die Datei C:\Program Files\Microsoft Visual Studio 8\Common7\Tools\vsvars32.bat (unter Vista als Administrator) im Notepad und fügen Sie den Pfad der TFS Power Tools beim Eintrag "@set PATH= ..." den Pfad zum TFPT hinzu, sodass der Eintrag in etwa so aussieht: set PATH=C:\Program Files\Microsoft Team Foundation Server Power Tools;...[Restpfad]... Nun wird vsvars32.bat einmal (als Administrator) ausgeführt. Danach das Command Prompt aufrufen, in das Visual Studio Projektverzeichnis wechseln und tfpt online aufrufen. Sämtliche geänderten oder hinzugefügten Dateien werden damit in TFS ausgecheckt. Ein Windows Form Dialog folgt und markiert jene Dateien des aktuellen Verzeichnisses. Diese Auswahl kann im Regelfall einfach mit "Pend Changes" bestätigt werden und - voila die geänderten Dateien sind in der Sourcecode-Verwaltung ausgecheckt und können nun einfach in TFS (in Visual Studio wie gewohnt) neu eingecheckt werden. Der oben beschriebene Vorgang des Aufrufs lässt sich natürlich auch einfach scripten. Für Developer, die viel auswärts arbeiten ist dieser Weg eine einfache und praktische Lösung, um unter TFS verwalteten Code und offline veränderte Dateien wieder in TFS einzuchecken und weiter zu verwenden - Team Foundation Server Power Tools sei Dank. Mehr Informationen zum spannenden Thema TFS gibt's u.a. hier: http://msdn2.microsoft.com/en-us/teamsystem/aa718825.aspx die "Home"-Seite von TFS. http://www.microsoft.com/germany/msdn/vstudio/products/teamsystem/team/default.mspx die deutsche Produkinformationsseite des TFS. http://channel9.msdn.com/tags/Team+Foundation+Server bietet eine Reihe von Videos, auch zu den Power Tools sowie zum Thema TFS und Orcas. Beitrag von Toni Pohl Developer | Microsoft Mediumlink | Permalink | Comments (0) | Post RSS mehr