Zur Zeit wird gefiltert nach: Konfiguration
Filter zurücksetzen

10.03.2011
16:40

Windows 7 Service Pack 1 und es hat Boom gemacht

Heute kam ich auf die Idee, den Firmenrechner mal wieder komplett herunterzufahren. Wenn ich vorher gewusst hätte, auf was ich mich da einlasse, wäre es bei einer Idee ohne Tatendrang geblieben.

Mit dem Herunterfahren wurde das Service Pack 1 über WSUS installiert. Die Folge davon war, dass mich die Fehlermeldung Fatal error C0000034 applying update operation begrüsste und das System nicht mehr startete. DISM führte auch nicht zum gewünschen Erfolg. Das was meine Kiste wieder zum laufen brachte, war eine Anleitung auf Administrator.de.

Die Moral von der Geschicht, Service Pack 1 über WSUS installiert man nicht.

Visual Studio 2010 – Wenn man von falschen Voraussetzungen ausgeht

Seit VS 2008, das ist jeden .NET-Entwickler bekannt, besteht die Möglichkeit das Zielframework der Solution anzugeben. So kann bspw. eine .NET 2.0 – Anwendung in VS 2008 entwickelt werden, zugegeben bei .NET 3.5 – Anwendungen ist es bedingt durch das SP1 wiederum speziell.

Dieses Feature ist VS 2010 - inkl. der Spezialität ;-) - erhalten geblieben. Gerade wenn man für Kunden mit unterschiedlichen Installationen entwickelt, bei der die Lehrbuchtheorie "Aktuelles Framework installieren" nicht mehr so ohne Weiteres funktioniert.

Leider fehlt hier der rote Faden. Im Glauben, dass ich mit dieser Eigenschaft auch VSTO-Anwendungen auf einer früheren .NET-Version mit den dazugehörigen Office-Tools entwickeln kann, habe ich ein Office-Projekt auf VS 2010 migriert. Hinterher ist man bekanntlich immer schlauer. Bei VSTO-Anwendungen funktioniert dieses praktische Feature nicht. In VS 2010 können diese Art der Anwendungen nur mit den VSTO 4.0 Tools entwickelt werden und in diesen gibt es, weil es gerade so schön ist, die allseits beliebten Breaking Changes, sodass auf den Zielsystemen die Anwendung nicht mehr funktionierte.

Ich kam also in die Verlegenheit, wieder auf die Version 2008 zu wechseln. Hinweise, wie das Ganze von Hand erledigt werden kann, habe ich hier gefunden, blieb mir aber zum Glück erspart, da ich auf das Backup zurückgreifen konnte.

Visual Studio 2010 Erweiterung für Item Templates (Vorlagen)

Mit Visual Studio kommt neu der Erweiterungsmanager hinzu. Mit diesen soll die Erweiterung der Entwicklungsumgebung noch einfacher gehen. Da ich eine angepasste Vorlage per Hand in den Zielordner platziert habe, hat es mich natürlich interessiert, wie dies mit dem Erweiterungsmanager realisiert werden kann. Zuerst wird die Visual Studio SDK benötigt. Diese steht hier zum Download bereit. Nach der Installation steht ein neuer Auswahlpunkt "Extensibility" in den installierten Vorlagen zur Verfügung.

Abbildung 1 Auswahl Projekt für eine Visual Studio Erweiterung
Abbildung 1

Wenn das Projekt angelegt ist, wird die Manifestdatei angezeigt. Hier sind die Angaben zum Produktnamen, dem Autor und der Version wichtige Informationen.

Abbildung 2 Manifestdatei der Visual Studio Extension
Abbildung 2

Im Content Bereich wird es interessant, wenn die Vorlagen mittels Erweiterungsmanager zur Verfügung gestellt werden sollen. Als Inhaltstyp kann Vorlage ausgewählt und die Quelle dieser Vorlage gewählt werden. Bei der Angabe von Unterordnern wird eine Struktur angelegt, die nach der Installation bei den installierten Vorlagen ersichtlich ist.

Abbildung 3 Vorlage dem Projekt hinzufügen
Abbildung 3

Was hierbei zu beachten ist, die Datei wird in das Projekt kopiert. Das kann sich als Fallstrick bei Änderungen erweisen. Die hinzugefügte Vorlage erscheint anschliessend im Inhaltsbereich der Manifestdatei.

Abbildung 4 Übersicht der Vorlagen im Content-Bereich
Abbildung 4

Nach diesen Angaben kann das Projekt erstellt werden und im Ausgabeverzeichnis steht eine *.vsix-Datei zur Verfügung. Bis hier ist eigentlich alles ohne grosse Probleme verlaufen. Nach der Installation der Erweiterung wird diese auch im Erweiterungsmanager angezeigt.

Abbildung 5 Erweiterung im Erweiterungsmanager
Abbildung 5

Also kommt jetzt die Überprüfung, ob die Vorlagen zur Verfügung stehen. Füge ich ein neues Element hinzu, dann gibt es einen neuen Punkt "databinding" und dort steht auch die Klassenvorlage zur Auswahl.

Abbildung 6 Neuer Auswahlpunkt databinding
Abbildung 6

Was aber nicht zur Verfügung steht, ist die angepasste Vorlage für die Selbstnachverfolgung von Entitäten. Also überprüfe ich, ob diese korrekt installiert wurde. Dazu suche ich den Installationsorder. Interessanterweise findet man diesem unter dem Pfad "C:\Users\Username\AppData\Local\Microsoft\VisualStudio\10.0\Extensions\rld\EntityFrameworkSelfTrackingEntitiesGerman\1.0\ItemTemplates\databinding" das Verzeichnis ef und die passende Vorlage. Es wurde also korrekt installiert.

Mein nächster Trick ist der alte Weg. Ich kopiere die Datei in das Vorlagenverzeichnis im Dokumentenbereich "C:\Users\Username\Documents\Visual Studio 2010\Templates\ItemTemplates\databinding" Hier lege ich die gleiche Struktur an, also "ef" und kopiere die Self Tracking-Vorlage hinein.

Abbildung 7 Kopiervorgang in die alte Vorlagenumgebung
Abbildung 7

Nach dieser Aktion steht im Punkt "databinding" der Punkt "ef" zur Verfügung und darin die T4-Vorlage für Entitäten mit Selbstnachverfolgung.

Abbildung 8 Sichtbare T4-Vorlage nach umkopieren in die alte Vorlagenumgebung
Abbildung 8

Was an der Sache einerseits interessant wirkt, ist das Zusammenfügen des Ordners "databinding" der 2 Verzeichnisse. Andererseits ist auch hier Murphy unterwegs, denn die T4-Vorlage wird über den Deploy-Vorgang der Erweiterung nicht dargestellt. Mal sehen, ob ich zu diesem Problem etwas finde.

T4 Templates - Der Nachteil einer Textdatei

Gerade wollte ich mir die Zeit nehmen und bei der deutschen Version von Visual Studio 2010 das Codegenerierungselement Self Tracking Entities testen. In der Englischen Umgebung habe ich bisher keine Probleme mit der Basisfunktionalität gehabt. Nun bei der deutschen Version hat wohl Murphy seine Finger im Spiel.

Abbildung 1 Auswahl Enititätsklassen mit Selbstnachverfolgung
Abbildung 1

Das erste was mich nach der Auswahl erwartet sind 4 Fehler im T4 - Templatecode.

Abbildung 2 Fehler nach Auswahl des Codegenerierungselement zur Selbstverfolgung
Abbildung 2

Wenn ich zu den Code in das Template springe, ist folgender Code-Block ersichtlich:

C# TT - CodeBlock-Ausschnitt
    // <#=String.Format(CultureInfo.CurrentCulture, "Zeichnet die ursprünglichen Werte für die komplexe Eigenschaft "{0}" auf.", edmProperty.Name)#>
    private void Handle<#=edmProperty.Name#>Changing(object sender, EventArgs args)
    {
        if (ChangeTracker.State != ObjectState.Added && ChangeTracker.State != ObjectState.Deleted)
        {
            ChangeTracker.State = ObjectState.Modified;
        }
<#
        if (originalValueMembers.IsOriginalValueMember(edmProperty))
        {
#>
        <#=code.Escape(edmProperty.TypeUsage)#>.RecordComplexOriginalValues("<#=edmProperty.Name#>", this.<#=code.Escape(edmProperty)#>, ChangeTracker);
<#
        }
#>
    }

Wer die erste Zeile (String.Format) sieht, erkennt bestimmt die Anführungsstriche, die nicht entwertet sind und den Fehler verursachen. Wenn ich "{0}" mit '{0}' ersetze oder alternativ die Anführungsstriche entwerte und die Solution neu kompiliere sind diese Fehler verschwunden und die Entitäten werden fehlerfrei generiert, der Kontext jedoch nicht (79 Fehler). Das liegt daran, dass im Context-T4 Template das gleiche Problem lauert.

Ein Vorteil dieser T4 - Templates, es ist wirklich schnell korrigiert.

Das eigentliche Problem sitzt jedoch in den lokalisierten Ressourcen wie zum Beispiel $Localized_STECtx_Comment_630$, in diesen werden die Anführungsstriche nicht entwertet.

ASP.NET 4.0 - Breaking Changes

In bestehenden Umgebungen mit .NET 2.0 bis .NET 3.5 – Anwendungen wird ein Update auf .NET 4.0 ohne ausreichende Vorbereitungen sicherlich interessante Feuerwehrübungen zur Folge haben. Denn mit .NET 4.0 gibt es sie wieder, die Breaking Changes. Ein Vorteil dieser Änderungen im .NET-Framework, es gibt Einstellungsoptionen, damit das Verhalten wieder an die vorherige .NET 2.0 – Umgebung angepasst werden kann. Eine habe ich bereits hier beschrieben. Zur Zeit sind 17 solcher Änderungen gelistet. Eine Änderung, die in bestehenden Umgebungen bei unzureichender Vorbereitung sicherlich amüsant werden kann, ist der neue Default Hashing Algorithmus HMACSHA256, bisher HMACSHA1.

Wer es nicht so weit kommen lassen will, der liest sich besser hier in die Breaking Changes von ASP.NET 4.0 ein.

Translate this page

Kategorien