Sonstiges – Seite 3 – Martins Blog

Sicherheitsupdate für Microsoft Visual Studio 2005 Service Pack 1 (KB937061) wird immer wieder installiert

Vielleicht geht es einigen von Euch genauso und bekommt von Windows Update das „Sicherheitsupdate für Microsoft Visual Studio 2005 Service Pack 1 (KB937061)“ immer wieder installiert.

Scheinbar trifft es alle diejenigen, die sich Crystal Reports nicht angetan haben, wie z.B. mich. Alle meine 4 Rechner (Vista+XP x86) sind davon betroffen. Dies entnahm ich den Infos eines Microsoft MSFT’s aus diesem Thread. Zitat:

Eric Brodish [MSFT]
If you have VS 2005 SP1 present but the Crystal Reports feature is not present, MS07-052 is re-offered. Customers are protected and are not at risk to this vulnerability We will be updating the detection on Microsoft Update, customers that have already installed this update need to take no action. We are working to resolve this issue and it should be fixed shortly Thank you Eric

Gleiches scheinen andere auch herausgefunden haben in den MS-Foren.

Wie stellt man es ab?

Einfach über den IE die Microsoft Update Seite aufrufen.
Benutzerdefinierte Suche starten
Die Updates anzeigen lassen
Den Haken entfernen und zusätzlich den Haken bei „Dieses Update nichtmehr anzeigen“ setzen.

Beschreibung dieses Security Updates:
http://support.microsoft.com/kb/937061

Eigentümliche Quotes beim Erzeugen einer Excel Datei mit ODBC

Eigentümlicher Effekt:
Ich erzeuge eine Excel Tabelle mit ODBC. Dann füge ich einige Zeilen in die Tabelle ein.

Wenn ich diese Tabelle mit Excel öffne sieht alles gut aus.
Betrachte ich die einzelnen Zellen jedoch näher, dann erscheint in der Bearbeitungsleiste für den Wert der Zelle immer ein zusätzliches einzelnes Anführungszeichen ‚ vor jeder Zelle. Die Zellen werden jedoch in der Ansicht korrekt angezeigt und auch in Formeln korrekt verwendet.

Ich binde die Daten ganz normal mit RFX_Text. Und der nColumnType wurde als Default-Wert mit SQL_VARCHAR angegeben.

Nach dem Lesen von einigen Artikeln bin ich letzten Endes darauf gekommen, dass dieses führende Quote ein internes Zeichen für Excel ist, dass es sich um eine Textzelle handelt.
Die Spaltenwerte werden ganz normal und korrekt weiterhin angezeigt.
Es scheint so, dass man das Ganze ignorieren kann. 😕

Siehe auch diesen guten Beitrag, der viele nützliche Excel Links bzgl. Automation und ADO enthält: http://groups.google.de/group/microsoft.public.vb.database.ado/browse_frm/thread/c3504ad88cc713ce

Code Monkeys auch überall bei uns…

Über den Code Project newsletter habe ich diesen Blog-Eintrag gefunden:
http://geekswithblogs.net/sdorman/archive/2007/06/29/Programming-for-the-masses.aspx

Ich sehe auch in den Deutschen Foren, in denen ich mich tummle genau die gleichen Tendenzen. Die Szene in den Online Foren und in den NNTP Gruppen hat sich ziemlich verändert.
Man trifft überall Massen an Code Monkeys!

Netiquette unbekannt
F1-Taste drücken und die Basics der MSDN lesen wird nicht gemacht
FAQ ansehen ist umständlich
Nichtmal die entsprechenden bekannten Suchbegriffe in Google einzugeben gelingt
Basiswissen über die entsprechenden Programmiersprachen wird per Try&Error erprobt
Es zählt nur der schnelle Erfolg, auch wenn die Art und Weise wie die Lösung gefunden ist zweifelhaft ist
Grundsätzlich ist immer der Compiler und die verwendeten Libraries (CRT/MFC) buggy. Nie der eigene Code!

Irgendwie bin ich aus meiner Vergangenheit verwöhnt.
In meiner Anfangszeit als MVP habe ich weniger gepostet. Dafür waren die Antworten länger und ausführlicher, und meistens handelte es sich um wirkliche Probleme, die es zu lösen galt. Heute sind die Antworten weitaus kürzer und bestehen oft nur auf einen Verweis auf die Doku. Schade eigentlich. Man muss sich wirklich fragen warum man das eigentlich macht!

Im Großen und Ganzen hat sich das Niveau in der Newsgroup nntp://microsoft.public.de.vc gehalten. Allerdings ist die Gruppe der Poster und Regulars ziemlich geschrumpft. Es scheinen NNTP Gruppen irgendwie aus der Mode gekommen zu sein.

Foren wie http://www.c-plusplus.de/forum/index-var-.html und http://forums.microsoft.com/MSDN/default.aspx?SiteID=1 scheinen zu boomen, allerdings ist das Niveau hier nach unten offen…

Tja: Scheinbar war früher wirklich alles besser… 😉

Was man beim Umstieg von VSS auf TFS bedenken muss!

Ich plane in der nächsten Zeit Visual Source Safe (VSS) abzulösen. Da wir alle Hauptprojekte (bis auf einigen legacy Kram) auf VC++ 2005 bearbeiten und die entsprechenden Visual Studio Team System Lizenzen haben beabsichtigen wir auch den Team Foundation Server (TFS) einzusetzen.
Einen Team Foundation Server kaufen müssen wir auch nicht, denn wir haben nicht mehr als 5 Clients.

Vorteile:

Integration auch in ältere Systeme ist kein Problem! Für VC6, VB6, VS.NET 2003 gibt es entsprechende Plug-Ins! Das ist schon mal genial. Also können wir theoretisch sogar alle legacy Projekte konvertieren und mit den alten Tools weiterarbeiten.
Alles wird in einem SQL-Server gehalten. Endlich!
Die Projekt Dokumente sind gleich in dem entsprechenden Share Point mit gehalten (leider noch WSS 2.0)
Einchecken mehrere Dateien werden direkt zu einem Vorgang zusammengefasst.
Direktes Bug-Tracking und einfache Projektierung ist möglich ohne externe Hilfsmittel.

Beim evaluieren der Features habe ich mir schon die Hände gerieben. Allerdings gibt es da eine wirkliche fette Kröte die ich schlucken muss. Mein geliebtes „Sharing“ unter VSS gibt es unter dem Source Control System von TFS nicht ❗

Wir haben einiges an gemeinsamen Code, den wir nicht in Libraries oder DLLs zusammengefasst haben. Da sind einige nette Template Klassen etc., spezielle Header und andere nette Code-Snipplets. Alle diese Code Teile waren in einem kleinen Projekt zusammengefasst und jeder Entwickler konnte diese wahlfrei in sein Projekt sharen. Das ist und war extrem bequem. Mit dem Drawback, dass eine zentrale Code Änderung alle Projekte beeinflusst und evtl. bricht kann man leben.
Man muss einfach regelmäßig Ohrfeigen verteilen für Entwickler die nicht testen und Kerker bei Brot und Wasser androhen… 😉

Unter TFS ist es damit vorbei. Einziger Ausweg wie ich ihn aktuell sehe ist es, die entsprechenden Codeteile einzubranchen in die anderen Projkete. D.h. aber das man die aktuelle Version (und den evtl. gewünschten Fix) nur mit einem Merge bekommt, was wieder nicht unbedingt automatisch geht, man muss also Hand anlegen was man evtl. eben auch vergisst.

Mal sehen vielleicht fällt mir da noch was anderes ein. Anonsten sieht das ganze sehr vielversprechend aus.

Für was ist eigentlich https://connect.microsoft.com/VisualStudio/feedback noch gut?

Aktuell packt mich so richtig die Wut. 👿 (und ich habe ziemlich viel Geduld)

Ich habe in den letzten Wochen zig-Fehler in den Compilern und Libraries von VC gefunden. Das fängt mit VC-2003 an und den hier geschilderten Fehlern in der MFC (siehe CPropertyPage Bug).
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=270493

Dann habe ich schon mehrere Bugs in VC-2005 gefunden. Unter andrem einige Probleme mit Attributed ATL.
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=98753
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=275256

Oder auch Fehler im Resource Compiler in allen VC-Versionen.
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=252616

Ganz zu Schweigen von so netten Sachen wie nicht funktionierende MT.EXE etc.
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=258108

Diese Liste ist bei weitem nicht vollständig, sondern zeigt nur die Erfahrungen der letzten beiden Monate. Ganz schweigen möchte ich von den Bugs, bei denen ich mich eingemischt habe, weil ich sie bestätigen konnte.

Meine Erfahrungen der letzten Zeit machen mich absolut frustig:

Extrem viele Bugs werden einfach so geschlossen als „Nicht reproduzierbar“
Bugs werden geschlossen ohne auch nur einen Kommentar!
Bugs aus VC-2003 werden grundsätzlich abgewiesen, wenn sie in VC-2005 gelöst sind. Meistens werden sie als „nicht reproduzierbar“ gekenzeichnet.
Bugs aus VC-2005 werden auch nicht mehr angenommen, wenn diese in Orcas gefixt sind. Meistens werden auch sie als „nicht reproduzierbar“ gekenzeichnet.
Ideen, werden oft sofort abgetan, erst wenn man etwas mehr Druck als MVP dahinter legt (was ein normaler User nicht kann), wird etwas mehr darüber nachgedacht.
Liefert man einen Workarround zum Bug eines anderen, wird der Bug oft sofort als gelöst geschlossen.

Stellt sich die Frage: Was gehört denn nach Connect?
Na es gibt ja eine Beschreibung. Auf der Seite: https://connect.microsoft.com/availableconnections.aspx
lesen wir zumindest noch folgenden Text:

Visual Studio and .NET Framework

Bleibt aber die Frage warum VC-2003 und VC-2005 nicht mehr in diese Kategorie zu fallen scheinen. Ist also nur noch das neueste VC (also Orcas) das eigentliche VC, selbst wenn sich das noch in der Beta befindet?

Für was ist also http://connect.microsoft.com noch gut?

Scheinbar weiß bei Microsoft selbst auch niemand so genau, welche Bugs bei Connect eigentlich eingereicht und wie bearbeitet werden dürfen. Aktuell habe ich eine Anfrage laufen, die klären soll, welche Policy eigentlich hinter Connect steht.

❗ Mein Rat: Verwendet den direkten Weg über den Support. Als MSDN-Abonnement hat man einige Support-Anfragen frei. Als Certfied Partner 5. Nutzt diese, alles andere scheint aktuell eher Zeitverschwendung und bringt einen nur zur Weißglut.

Es ist frustig, frustig, frustig…

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!

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

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.