Autor: Martin Richter

Was mit Visual Studio 2005 SP1 unter Vista zu beachten ist

Ganz Allgemein hier eine kleine Sammlung wertvoller Links für die Nutzung von Visual Studio 2005 unter Vista. Besonders der zweite Link ist wichtig nach meiner Meinung.

Installationshinweise:
http://support.microsoft.com/kb/929470/en-us

Visual Studio 2005 on Windows Vista Issue List – Running with normal user permissions http://msdn2.microsoft.com/en-us/vstudio/aa972193.aspx

Visual Studio 2005 on Windows Vista Issue List – Running with elevated administrator permissions http://msdn2.microsoft.com/en-us/vstudio/aa964140.aspx

Visual Assist X unter Vista mit VS2005 und SP1

Meine ersten Gehversuche und Test mit VS2005 unter Vista waren gut. Aber da ich mich ohne Visual Assist X gleich fühle als man man mir drei Finger an jeder Hand amputiert hat war ich sehr frustriert als ich merkte, dass VA-X nicht ganz so funktionierte wie es das sonst auf XP tat.

Ein ALT+G, also ein GotoDefinition lies nur einen lästigen Beep hören. Ich befürchtete ohne eine der Hauptfunktionen von VA-X auskommen zu müssen.

Nach einigen Tests merkte ich auch, dass VisualStudio 2005 auch nicht korrekt beendet wurde. Es war zwar nicht mehr sichtbar auf dem Monitor, aber im Taskmanager blieb die Applikation immer noch aktiv und lies sich nur durch den Taskmanager beenden.

Nun das ganze war kein Problem mehr, wenn man VisualStudio mit erweiterten Rechten (also mit Run as Administrator) startet. Aber genau das wollte ich nicht. Zudem mag ich keine überflüssigen Fragen beim Programmstart.

Nach kurzem Nachdenken war mir klar, dass VA-X seine Daten im Programm-Verzeichnis ablegt. Nun und das ist in Vista nun mal nicht gerne gesehen, denn auch als Administator hat man auf diese Verzeichnisse nur mit angehobenen Rechten Schreibzugriff.

Also habe ich die Rechte für das Verzeichnis C:\Programme\Visual Assist X einfach auch für den normalen Benutzer erweitert und auch Änderungsrechte vergeben. Und siehe da, alles funktioniert jetzt ohne Probleme.

BTW: Wer Visual Assist X nicht kennt, der sollte ganz schnell http://www.wholetomato.com besuchen und sich eine Demo besorgen.
Kein Tool mit dem ich arbeite ist so sehr sein Geld wert wie dieses!

Microsoft SQL Server Management Studio Express auf Vista schlägt fehl. Fehler 29506

Fehlermeldung 29506Ich wollte mir das Microsoft SQL Server Management Studio Express auf Vista installieren. Aber während der Installation erhielt ich die folgende Fehlermeldung:

Bei der Installation dieses Pakets ist ein unerwarteter Fehler aufgetreten. Es liegt eventuell ein das Paket betreffendes Problem vor. Der Fehlercode ist 29506.

Und nun? Man sollte doch annehmen, dass eine MSI-Datei sich installieren lässt und auch im Admin-Modus installiert wird. Pustekuchen.

Es geht doch, mit einem Trick:

Man starte eine Console im Admin-Modus: Rechtsklick auf die Verknüpfung und Als Administrator ausführen wählen. Dann von dort die entsprechende SQLServer2005_SSMSEE.msi aufrufen. Dann läuft das Setup ohne Fehler durch.

Langsam habe ich das Gefühl, dass dieses Verfahren zur Installation unter Vista grundsätzlich zu empfehlen ist. Leider kann man MSI-Pakete nicht direkt über ein Kontextmenü im Admin-Modus installieren.
Das wäre was für Vista SP1 😉

Nachtrag 22.08.2009:
Das Problem betrifft auch die Installation unter Windows Server 2008 als auch Windows 7, sofern UAC eingeschaltet ist. Das MSI Paket muss in jedem Fall als Admin (elevated) gestartet werden.

Der # operator im RC-Compiler arbeitet inkonsistent

Heute ist mir ein übler Fehler des Ressourcen Compilers untergekommen.

Beabsichtigt war es einen #define in einen Text umzuwandeln, der als Ressourcen-String abgelegt wird.

Das ganze wurde so implementiert:

#define _MYSTRING(x)   #x
#define MYSTRING(x)    _MYSTRING(x)
STRINGTABLE
BEGIN
4713 MYSTRING(0409)
4714 MYSTRING(040E)
END

Alles kein Geheimnis, nur macht der Ressource-Compiler was er will. Der erste String wird korrekt angelegt. Beim zweiten wird wie durch Zauberhand noch eine 0 angehängt.

Das ganze Problem konnte ich auf allen VS-Systemen (VS2003, VS2003SP1, VS2005 und VS2005 SP1) nachvollziehen.

Gemeldet für Microsoff-Feedback unter:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=252616

Voraussetzungen für Remote debugging mit MSVCMON (unmanaged)

Ich bin ein Fan von Remote Debugging!
Aber was benötigt man minimal für Remote Debugging auf dem Target auf dem man debuggen möchte (unmanaged Code)?
Das gesamte Remote Debugging Paket zu installieren ist aufwendig und verändert das Zielsystem. Wenn man auch noch bei einem Kunden vor Ort ist auch natürlich ein Eingriff, den man einem Admin erst mal erklären muss.
Geht es also auch mit weniger? JA…

Für VS.NET 2003 braucht man nicht viel, genau genommen 4 Dateien mit einem Datenvolumen von nicht mal 600kb (passt auf jede Diskette, sofern die noch einer benutzt ;-)) :

  • msvcmon.exe
  • msvcr71.dll
  • NatDbgDM.dll
  • NatDbgTLNet.dll

Wenn man nun auf Firewall Probleme verzichtet und Named Pipes als Transportschicht verwendet dann war es das schon. Dann muss man nur noch MSVCMON auf dem Target starten und es kann losgehen. Seit VS.NET 2003 startet MSVCMON ohne Angabe von Parametern mit named Pipes als Transportschicht. Unter Vista muss man nach meinen Erfahrungen immer den -u Parameter mit angeben wenn man Named Pipes verwendet (siehe hier).

Das einfachste ist es nun sich mit VS.NET 2003 remote auf einen laufenden Prozess zu attachen, den man debuggen möchte. Man öffnet dazu aus dem Menü Debug den Punkt Processes, wählt als Transportschicht Named Pipes und den Target PC. Die Liste der Prozesse füllt sich automatisch.
Nun nur noch den Prozess auswählen und auf Attach klicken. Sofern die PDB-Dateien übereinstimmen kann man sofort seine Breakpoints setzen und loslegen.
Das geht teilweise sogar noch, wenn eine UAE Meldung auf dem Monitor sichtbar ist.

Wer unbedingt TCP/IP als Transportschicht wählen will, der muss seit XP-SP2 einiges an der Firewall einstellen. Die zwei nachfolgenden Links geben entsprechende Hinweise:
http://support.microsoft.com/kb/833977/de
http://support.microsoft.com/kb/841177/en-us

Remote debugging mit MSVCMON im Pipe-Mode auf Vista

Man sollte meinen, dass MSVCMON (aus VS.NET 2003) im Pipe Modus unter dem selben User Account sofort funktionieren sollte. Aber dem ist nicht so.

Normalerweise melde ich mich an der Entwicklungsmaschine und dem Remote-PC auf dem gedebuggt werden soll mit dem selben Benutzernamen an. Wird MSVCMON nun ohne Parameter auf dem Remote Computer gestartet kann man normalerweise sofort eine Verbindung herstellen.
Nicht so unter Vista. Dort bekommt man beim Versuch eine Verbindung herzustellen sofort die Meldung: „Unable to connect to ‚DEV-VISTA‘. Zugriff verweigert“, oder auf einem englischen OS „access denied“.

Nach vielem hin und herspielen und dem Versuch MSVCMON im Administrator-Modus zu starten bin ich auf die Lösung gekommen.

Gibt man direkt noch einmal mit dem -u Parameter den gewünschten Usernamen an, dann erlaubt Vista auch den entsprechenden Zugriff.
Also so gestartet MSVCMON -u MeineDomain\MeinUserName hat man keine Probleme und man kann in gewohnter Weise eine Remote Debug-Session starten und auch unter Vista elementar einfach die Programme debuggen.

PS: Es geht in diesem Artikel natürlich um das Debuggen von nativen Programme, sprich unmanaged Code.

SIGNCODE -i setzt leider nicht den Email-Eintrag

Man könnte meinen, dass SIGNCODE mit dem -i „url“ Parameter , die Email-Adresse in dem Dialog für die digitale Signatur setzt. Zertifikatsanzeige Jeder kennt wahrscheinlich den entsprechenden Dialog:

Nun leider ist dem nicht so. Es wird hier nur eine Zusatzinfo eingetragen.

Die Email- oder URL-Adresse hier müsste im Zertifikat selbst verewigt werden. Nur wird dieses Feld bei Verisign-Zertifikaten nicht mehr ausgefüllt bzw. man kann es nicht mehr bekommen. Angeblich weil es zu viel Spam auf diese entsprechenden Adressen gab. Eine etwas fadenscheinige Ausrede.

Die Info landet in der Struktur SIGNER_ATTR_AUTHCODE in dem Feld pwszInfo und dort ist sie leider nicht sonderlich gut für einen normalen Anwender zu finden.

Schade! Nett wäre es gewesen. Aber nun ist es mal nicht so…

UPDATE Statement für die Tabelle Upgrade eines MSI-Projektes

Ich habe gerade Stunden verbracht ein VBS-Skript zu schreiben, dass ein Microsoft Installer Projekt anpasst. Aufgabe war einige bestehende Einträge in der Tabelle Upgrade zu ändern. Es sollten nur die Wert in den Spalten VersionMin und VersionMax angepasst werden.

Ein schönes UPDATE-Statement war schnell erzeugt. Aber es schlug immer fehl mit:
PostBuild.vbs(28, 1) Msi API Error: OpenView,Sql  😕

Nach längerem Nachdenken, Suchen und Analyse mit Orca, stellte ich fest, dass die Spalten UpgradeCode, VersionMin, VersionMax, Language, Attributes alle den Primary-Key bilden.

Nun wird sich mancher Fragen: Na und?!?!

Nun die MSI Dokumentation sagt zu UPDATE-Statements in MSI Dateien:
❗ UPDATE queries only work on nonprimary key columns!

Also doch alle Records einlesen, löschen und neu schreiben…

SIGNCODE ausführen ohne Kennworteingabe

Da unsere Programm demnächst auch für Vista zertifiziert werden sollen, müssen alle unsere Executables nun digital signiert werden.

Soweit OK. Nur bei normaler Verwendung von SIGNCODE wird immer ein Kennwort für das Zertifikat abgefragt. Etwas lästig, wenn man automatische Build Prozesse hat, die hunderte von Dateien signieren müssen. Da es keinen Befehlszeilenschalter für das Kennwort gibt dachte ich schon ein spezielles Programm schreiben zu müssen, was den Dialog entsprechend ausfüllt. Aber Google sei Dank!

Eine erste mühsame Suche brachte mich auf diesen Beitrag von Rob MacFadyen. Zusammengefasst steht dort: Zertifikat importieren und aus dem eigenen Zertifikats Speicher signieren ohne lästige Kennwortabfrage.

Zum Importieren wird dort das Tool KEYIMPRT.EXE angegeben, und das ist nun beim Besten Willen auf den MS Seiten (auch unter dem entsprechenden Link) nicht mehr zu finden.

Nach einigen Suchen bin ich darauf gestoßen, dass dieses Tool durch PVKIMPRT.EXE ersetzt wurde, und dieses bei MS hier heruntergeladen werden kann.

Nun der Rest geht wie gehabt, einfach
signcode.exe -s my -cn „Dein_Zertifikat_CN“ -t http://timestamp.verisign.com/scripts/timstamp.dll „Deine_zu_signierende.EXE“
ausführen und das war es schon!

Keine lästige Kennwortabfrage mehr und schon steht dem automatischen signieren nichts mehr im Wege.

Achtung: Das Importieren in den internen Zertifikats-Speicher schützt nicht vor Zertifikats-Diebstahl! Der Zugang zu diesen Zertifikaten sollte also schon so geschützt und eingeschränkt wie möglich erfolgen. 

1,4km bis zum Mittelpunkt der Welt…

Ähhhh… sorry ich habe mich vertan. Ich meinte natürlich den Mittelpunkt der europäischen Union. Ich wohne laut offiziellen Koordinaten und den Berechnungen von Google jetzt nur noch 1,4km vom Mittelpunkt der EU entfernt. Amtlich seit dem 03.01.2007, die EU Ost-Erweiterung machte es möglich.

Wikipedia ist schon up-to-date  und der Hessische Rundfunk (ARD) hat natürlich auch berichtet. Oder glaubt Ihr dem ZDF mehr?

Und hier ist der Mittelpunkt der EU zu sehen!

Endlich ist offizell was wir Meerhölzer schon immer wussten:
Meerholz ist der Mittelpunkt der Welt!
Auch wenn uns bis jetzt nur die EU zugestanden wird ;-)!