Seit geraumer Zeit gibt es ja Windows 8 und Visual Studio als Preview-Version zum herunterladen. Dennoch sind viele Dinge, die auf die Entwickler zukommen, unklar. Wer nicht die Zeit hat, alles selbst auszuprobieren, sollte sich mal folgendes Video ansehen (1 h!). Es ist die bisher beste Präsentation, die ich gefunden habe: http://dnrtv.com/dnrtvplayer/player.aspx?ShowNum=0207

Inzwischen gibt es auch ein WIKI zum Thema, das fortlaufend erweitert wird: http://metroapps.wikispaces.com/ 

In diesem Wiki habe ich zum ersten Mal auch eine vernünftige Übersicht zum Thema Kompatibilität zwischen heutigen WPF/Silverlight-Anwendungen und WinRT-Anwendungen im Metro-Style gefunden!

Häufig hat man ja die Anforderung bei der Anlage von Klassen immer wieder gleiche Interfaces/Methoden zu implementieren. Hierdurch erhält man immer wieder sehr ähnlichen redundanten Code. In einigen Fällen kann man sich noch durch Ableitungen helfen aber auch das ist nicht immer die Lösung.

Wer sich noch nie mit dem Thema AOP beschäftigt hat, sollte sich vorab folgendes Whitepaper unbedingt durchlesen. Es gibt einen sehr guten Gesamtüberblick über die Möglichkeiten dieser Technologie.

Ein Ausweg aus dieser Problematik kann das Tool PostSharp und die aspektorientierte Programmierung sein. Aus den Beispielen von PostSharp kann man sich eine Menge Ideen holen. Hier gibt es auch eine ganze Menge Tutorials, die man sich ansehen sollte. Die ganze Serie findet man hier  – Nach der Installation des Tools kann diese Serie übrigens auch direkt vom Studio aus aufrufen.

Visual Studio selbst unterstützt die AOP noch nicht komplett selbst. In der Regel kann man hierfür eine ganze Reihe von Bibliotheken einsetzen, die diesen Mechanismus zur Verfügung stellen. PostSharp ist eines der bekanntesten Tools und kommt inklusive einer guten VS-Integration daher.

PostSharp kann man hier herunterladen: PostSharp Download

Ein wichtiges Tool in diesem Zusammenhang ist das Programm ILSpy, das man hier herunterladen kann: http://wiki.sharpdevelop.net/ILSpy.ashxHiermit lässt sich der IL-Code von DLLs direkt und komfortabel ansehen.

Im Zusammenhang mit dem EntityFramework verwendet auch Microsoft die AOP innerhalb von VS für die eigenen Klassen. Leider wird das generieren eigener Attributklassen von VS bisher nur begrenzt unterstützt sodaß der Einsatz von Tools wie PostSharp ein ziemlich spannendes Thema ist. In jedem Fall lohnt es sich, sich mit der Thematik einmal ausführlich zu beschäftigen.

Will man sich einen ersten Überblick über DevForce verschaffen, kann man jetzt auf unserer neuen Domain die ersten Infos auf Deutsch beschaffen. Neben einem deutschen Whitepaper gibt es (neu) auch ein deutsches Tutorial, wie man in der Praxis mit DevForce umgeht – samt Quellcode und Schritt für Schritt Anleitung. Das ganze findet man unter www.devforce.de

Ich möchte nur nochmals darauf hinweisen, dass wir als Partner von Ideablade dieses Jahr auf der BASTA in Mainz ausstellen werden.

Außerdem werden wir im Rahmen einer Projektfallstudie ein Silverlight-Projekt von uns vorstellen.

Wer näheres wissen will findet die Infos hier: www.basta.net

Ich würde mich freuen, den ein oder anderen in Mainz begrüßen zu können. Bis kommende Woche.

Micha

Nachdem es zu diesem Thema zahllose Diskussionen gibt, habe ich hier mal einige Links zu aktuellen Informationen gesammelt. Das spart dem ein oder anderen sicher die mühsame Suche nach verwertbaren Informationen.

http://www.zdnet.com/blog/microsoft/microsoft-needs-to-tell-windows-8-developers-now-about-jupiter-and-silverlight/9608?tag=rbxccnbzd1

http://arstechnica.com/microsoft/news/2011/06/windows-8-for-software-developers-the-longhorn-dream-reborn.ars

http://www.heise.de/developer/artikel/Windows-8-HTML5-und-die-Folgen-fuer-NET-1267153.html

Nachtrag vom 11.8. Informationen von Telerik zum Thema: http://networkedblogs.com/lvZm1 

Die Reihenfolge der Links ist willkürlich und ohne Wertung! Sollte jemand noch was sinnvolles finden bin ich sehr daran interessiert.

Viele FoxPro-Entwickler stehen vor dem Problem große Anwendungen in die schöne neue Welt <G> zu migrieren. Häufig steht schon fest, daß die neue Entwicklungsumgebung .NET und damit Silverlight oder WPF oder ASP.NET sein wird. Aber auch für jede andere Web-Technologie ist der hier beschriebene Weg verwendbar.

Soweit so gut. In den meisten Fällen steht man aber vor der fast unlösbaren Aufgabe eine große Anwendung umzustellen. Meist hat man dafür weder die Entwicklungs- noch die Testkapazität geschweige denn das notwendige Budget. Somit bleibt nur, diese Umstellung Schritt für Schritt vorzunehmen. Da sich die Umstellungsphase auch über einen sehr langen Zeitraum hinziehen kann, sind Ideen für eine nahtlose Integration zwischen alten und neuen Systemteilen dringend gefragt.

Vor etwa zwei Jahren habe ich hierzu schon einmal das Windows Messaging im Rahmen eines Vortrags gezeigt. Dabei “kommunizieren” eine FoxPro-Anwendung und eine .NET-WPF-Anwendung über das Windows-Messaging miteinander. Der Anwender springt dabei - kaum merklich – zwischen alter und neuer Welt hin und her.

Heute stelle ich hier eine noch reibungslosere Integrationsmöglichkeit zwischen FoxPro-Anwendungen und Silverlight vor.

Die FoxPro-Beispielmaske:

Den Kern der Idee bildet das Internet-Explorer-Control (Active-X-Control!). Dieses Steuerelement bietet uns alle entscheidenden Funktionen um Silverlight-Masken anzuzeigen. Ein Beispielaufruf ist hinter dem Click-Event der Buttons implementiert:

this.olecontrol1.navigate2(“http://localhost:58226/slFoxIntegrationTestPage.aspx#/home”)

Die Silverlight Anwendung

Der Trick für eine nahtlose Integration von Silverlight in eine FoxPro-Anwendung liegt im sogenannten “Deep-Linking”, das Silverlight seit der Version 3.5. bietet. Hierbei kann man eine Silverlightanwendung direkt mit einem Aufruf einer bestimmten Maske starten. Am einfachsten kann man sich eine solche Anwendung über das “Silverlight Navigation Application”-Projekttemplate im Visual-Studio anlegen.

Ich habe die Optik der Startseite etwas angepasst sodaß man hier die Kopfzeile nicht mehr sieht. Diese brauchen wir für unser Beispiel einfach nicht mehr, da FoxPro für die Navigation in der Anwendung verantwortlich sein soll. Die Mainpage der Silverlight-Anwendung sieht dann so aus:

Nicht gerade spannend aber für unsere Zwecke völlig ausreichend. Kern dieser Seite ist jetzt nur noch das Frame-Control, das unsere Masken “hostet”, die wir von FoxPro aus direkt starten wollen. Hier der Auszug aus dem XAML der MainPage.xaml-Datei:

Damit sind die wesentlichsten Komponenten fertig gestellt. Wenn man jetzt die Silverlight-Anwendung startet bekommt man im Internetexplorer auch die korrekte Adresse der Silverlight-Anwendung auf seinem eigenen Rechner angezeigt. Diese kann man für den ersten Test einfach kopieren und nach FoxPro übertragen.

Wie kann man nun von FoxPro aus bestimmte Seiten direkt starten? Nun das geht direkt über die Startseite, die man mit entsprechenden Parametern aufrufen kann:

http://localhost:58226/slFoxIntegrationTestPage.aspx#/about?CustNo=1

Hierbei wird der Parameter “/about” über den URI-Mapper der MainPage in die Silverlightseite “/Views/About.xaml” umgemappt und dieses Control wird dann in dem obigen Frame-Control angezeigt.

Wie kann man dieser Maske nun von FoxPro aus Parameter übergeben? Auch das sieht man in der oben angebenen Adresse. Das “?” ist der Marker an dem Parameter intern unterschieden werden. In dem angezeigten Beispiel wird die CustNo mit dem Wert 1 übergeben. Auslesen kann man diesen Parameter dann auf der Silverlightseite z.B. im Codebehind der Maske über folgenden Aufruf:

Der Zugriff auf den Parameterwert ist sehr einfach, da VisualStudio uns hier ganz bequem zugreifen lässt:

Stellt sich natürlich noch die Frage, wie man Ergebniswerte von Silverlight nach FoxPro zurückgeben kann. Auch das ist eigentlich recht einfach solange es sich um wenige einzelne Informationen handelt. Der Trick ist hierbei eine Dummy-URl zu der man von Silverlight aus navigiert, um zurück zur FoxPro-Anwendung zu kommen. In folgendem Beispiel werden gefundene Daten zu einer URL zusammengesetzt und dann dorthin navigiert:

  Natürlich gibt es diese Webseite nicht wirklich. Hier sollte jetzt eigentlich auch ein entsprechender Fehler im Explorer-Control erscheinen. Damit das nicht passiert “fangen” wir diese Dummy-URL im Inernet-Explorer-Control in der FoxPro-Maske ab.

Hierzu habe ich am OCX-Control die Methode BeforeNavigate2 überschrieben. In diese wird die Dummy-URL als Parameter hereingegeben. Dadurch, daß ich den Parameter Cancel auf .t. gesetzt habe, wird die Navigation abgebrochen und der Aufruf der Seite quasi beendet.

Was aber tun, wenn man eine ganze Ergebnisliste von Silverlight nach FoxPro übergeben will? Die Übergabe per URL ist dafür sicher nicht geeignet. In diesem Fall muss man etwas mehr Aufwand betreiben. Der einfachste Weg hierfür geht sicherlich über XML-Dateien, die man im Isolated-Storage ablegt und deren Dateiname man als Parameter an Foxpro zurückgibt.

Der hier beschriebene Weg ermöglicht es - auch große Anwendungen - Stück für Stück umzustellen ohne dass der Anwender davon etwas merkt. Wenn Farben und Schriftarten sowie die Maskengestaltung angepasst wird, ist es für den Benutzer kaum auseinander zu halten, ob er sich in FoxPro oder in Silverlight bewegt. Wenn man sich die Implementierung der Serviceschnittstelle sparen will, kann man sicherlich auch WPF-Anwendungen auf die gleiche Art integrieren. Hierzu muss lediglich WPF als Browseranwendung laufen. Auch ASP.NET oder andere WEB-Anwendungen kann man auf diesem Weg nahtlos integrieren.

Vielleicht hilft das hier beschriebene Beispiel dem ein oder anderen auf dem Weg seine Anwendung auf eine neue Version zu migrieren.

XML-Dateien sind ja sehr praktisch um kleinere Datenmengen dynamisch irgendwoher zu laden.  In Folgendem Besipielcode sind die notwendigen Funktionen zusammengefasst mit denen an das recht einfach unter Silverlight tun kann. Im Beispiel liegt die XML-Datei dort, wo auch die XAP-Datei liegt.

Damit sowas problemlos passiert, muss ein Zugriff auf den Webserver möglich sein. Neben den reinen Zugriffsrechten sollte auch eine Cross-Domain-Policydatei vorhanden sein:

Dateiname im Rootverzeichnis des Servers: crossdomain.xml mit folgendem Inhalt:

<cross-domain-policy>
  <allow-access-from domain="*" />
</cross-domain-policy>

Die XML-Datei sieht so aus:

<?xml version = "1.0" encoding="Windows-1252" standalone="yes"?>
<filmliste>
    <Film title="Testfilm1" filename="Film1.wmv" comment="kein Kommentar"/>
  </filmliste>

Die Lade- und Auslesefunktion sehen bei mir so aus:

void getFilmListFromHomepage()
{
 try
   {
    Uri xmlFilmListFile = new Uri(this.SourceDirectory + 
                                       "FilmListe.xml", UriKind.Absolute);
 
    WebClient cl = new WebClient();
    cl.DownloadStringCompleted += 
      new DownloadStringCompletedEventHandler(cl_DownloadStringCompleted);
  

    cl.DownloadStringAsync(xmlFilmListFile);
    return;
    }
 catch (Exception xx)
    {
    MessageBox.Show("Problem beim lesen der FilmListe: " +
  xx.Message.ToString());
    return;
    }
 }
 
 void cl_DownloadStringCompleted(object sender, 
                                       DownloadStringCompletedEventArgs e)
 {
  // achtung crossdomain policy datei muss da sein!
 string xmlFilmListe = e.Result;
 XDocument xdoc = XDocument.Parse(xmlFilmListe);
 
 _FilmListe = from ex in xdoc.Descendants("Film")
  select new Film
                   {
                   Title = ex.Attribute(XName.Get("title")).Value,
                   FileName = ex.Attribute(XName.Get("filename")).Value,
                   Comment = ex.Attribute(XName.Get("comment")).Value
                   };
 
 PLBFilmTitles.ItemsSource = _FilmListe; 
 }

Übrigens an das Startverzeichnis der Silverlightanwendung 
kommt man so heran:

public void GetConfigInfosFromServer()
{
string cp =
System.IO.Path.GetDirectoryName(Application.Current.Host.Source.ToString())
 + @"\MovieViewer.xml";
cp = cp.Replace("\\", "//");
 
try
  {
   Uri xmlFilmListFile = new Uri(cp, UriKind.Absolute);
 
   WebClient cl = new WebClient();
   cl.DownloadStringCompleted += new DownloadStringCompletedEventHandler(
                                        cl_DownloadConfigInfosCompleted);
   cl.DownloadStringAsync(xmlFilmListFile);
   return;
   }
catch (Exception xx)
   {
   MessageBox.Show("Problem beim lesen der Konfiguration: " + 
                    xx.Message.ToString());
   return;
   }
}

Vielleicht hilft der Quellcode ja doch dem Einen oder Anderen schneller 
zum Ziel zu kommen.

Auf der DevCon in Frankfurt (www.devcon.dfpug.de)  habe ich wieder mal zahlreiche Vorträge gehalten. Mein Dank geht an alle, die so lange durchgehalten haben und sich teilweise sogar abends noch unsere Fallstudie bis 22:30 Uhr angetan haben!

Wer es nochmals braucht bzw. die Unterlagen noch nicht hat, kann die Vortragsunterlagen hier  herunterladen. Fragen und Ideen sind natürlich jederzeit gerne willkommen.

auf der Devcon in Frankfurt (www.devcon.dfpug.de)  wurde ich auf das Thema Lokalisierung von Silverlight Anwendungen angesprochen. Hierzu gibt es eine recht gute Quelle von Bard Adams hier:

In seinem Blog beschreibt er die vorhandenen Standardmechanismen, die auf Ressourcen basieren.

Eine aus meiner Sicht erheblich handlichere und flexiblere Lösung wird im .NET Framework von Oakleaf verwendet. Die Beschreibung dazu kann man sich inklusive Videos auf der Homepage www.oakleafsd.com ansehen. Dort kann man sich auch den Developers Guide zum Framework herunterladen, in dem die Technik genauer beschrieben ist. Der Download ist auch möglich ohne das Framework zu kaufen.

Die Basta ist vorbei, meine Session auch. Ich danke allen Teilnehmern, die so kurz vor Schluß noch so zahlreich zu meiner Session gekommen sind und dann auch noch an der Diskussion teilgenommen haben. Offensichtlich ist das doch ein Thema, was nicht nur mich interessiert.

Wie versprochen kommt hier der Link zu meinen Beispielen und den Folien, die  ich gezeigt habe.

Für Fragen habe ich immer ein offenes Ohr und würde mich über Rückmeldungen freuen. Vielleicht sieht man sich ja auf der Webtech oder der Frühjahrs-Basta wieder..

In den vergangenen Tagen gab es immer wieder Hinweise auf ein neues Produkt von MS das sich Lightswitch nennt. Hierbei handelt es sich um einige Projekttemplates und Designer mit denen man ganz einfach komplette Datenbankanwendungen erstellen kann. Ich halte das Produkt für viele kleine Projekte für enorm interessant. Auch wenn es sich um einen Anwendungsgenerator handelt, verbaut man sich durch die Benutzung nichts! Insbesondere für Einsteiger bietet sich ein äußerst komfortabler Weg in die MVVM- Anwendungsarchitektur. Generiert werden dabei Silverlight Anwendungen, die mit beliebigen Datenquellen arbeiten können. Derzeit sind Projektvorlagen für C# und VB verfügbar.

Inzwischen ist auch die Beta zum Download bereit gestellt worden. Wer sich einen tiefergehenden Überblick verschaffen will - insbesondere was die Erweiterbarkeit angeht - sollte sich folgendes Video mal ansehen:

http://bit.ly/csqb3P

Übrigens wurde auch auf Universalthread eine separate Rubrik eröffnet. Hier laufen bereits die ertsen Diskussionen zu diesem Thema: www.universalthread.com.

Viele kennen Resharper als Refactoring Tool seit langem. Von DevExpress gibt es ein deutlich eingeschränktes Tool mit ähnlicher Funktionalität - dafür ist es Freeware:

http://www.devexpress.com/Products/Visual_Studio_Add-in/CodeRushX/

von Universalthread.com:

From SSWare: "VS Explorer adds a Windows Explorer-Like file and folder browsing window to Visual Studio. It provides complete access to file andfolder context menus (including 3rd party extensions such as TortoiseSVN) and drag-drop functionality which allows directly adding files/folders to your projects. It can quickly browse to the current solution folder, project folder
or the selected item. It can add selected dll/exe files as references and open command prompt window on selected folder. VS Explorer eliminates switching back and forth between Visual Studio  and Windows Explorer and other external programs and allows you to focus on your work slow and preserve concentration, save time, reduce stress and work efficiently."

http://www.ssware.com/vsexplorer/vsexplorer.htm

LINQ to SQL ist ja bisher nicht in der Lage gewesen in einer richtigen mehrschichtigen Architektur zu laufen. Seit kurzem sind die sogenannten DataServices von Microsoft released worden. Damit ist es dann möglich die Datenabfragen per http-Request an einen entfernten DataService Endpoint "auszulagern".

Nähere Informationen findet man hier:

http://msdn.microsoft.com/en-us/library/cc956153.aspx

http://msdn.microsoft.com/en-us/library/cc907912.aspx

http://msdn.microsoft.com/en-us/library/cc907912.aspx

ShellObjects.Net 2008 is a set of components which allow your applications to create quick-launch like appbars with drag-docking and autohide functionality [ShellAppBar], display MSN/Office2003 style popups [ShellPopupNotification], create back-forward navigating wizards [Wizard], display Explorer-like progress dialogs [ShellProgressDialog], monitor system idle time [SystemIdleTimer], perform multiple file/folder operations with Explorer-like progress dialog support [ShellFileOperation], add automatic resizing and resolution-independence to your forms [Resizer], define and listen to system-wide hotkeys [ SystemHotkey], create system tray icons with support for animations, multiple icons and balloon styles [ShellNotiyIcon], display Vista-style task-dialogs [TaskDialog], SingleInstanceComponent, TaskScheduler library, shortcut/internet shortcut library and more. ShellObjects.Net is written in 100% C# managed code; it fully supports Visual Studio 2008 with Net 3.5/3.0 and Vista; it has a royalty-free redistribution license; it has no external dependencies and it comes with comprehensive documentation and numerous samples.

http://www.ssware.com/shlobj/shlobj.htm

Fiddler ist ein HTTP Debugging Proxy. Damit kann der HTTP-Traffic mitsamt allem was dazugehört (Request- / Response-Headers, Bilder, CSS, …) analysiert werden.

Fiddler is freeware and can debug traffic from virtually any application, including Internet Explorer, Mozilla Firefox, Opera, and thousands more.

Fiddler ist eine Standalone-Software, alle Microsoft Programme d.h. Internet Explorer, Outlook Express, etc... sind automatisch so konfiguriert, dass der Verkehr analysiert werden kann.

Um auch den Verkehr mit Firefox analysieren zu können, muss dieser konfiguriert werden.

Erste Möglichkeit (Für Firefox):

1. Fiddler installieren
   
2. Zu "Eigene Dateien/Dokumente" navigieren, dort in den Ordner "Fiddler\Scripts" wechseln
   
3. In diesem Verzeichnis gibt es eine Datei Namens "BrowserPAC.js"
   
4. Den kompletten Pfad mit der genannten Datei in die Zwischenablage kopieren
   
5. Im Firefox auf Extras -> Einstellungen -> Erweitert
   
6. Dort das Tab "Netzwerk" auswählen und im Verbindungsbereich auf "Einstellungen" klicken
   
7. Im nächsten Fenster die Option "Automatische Proxy-Konfigurations-URL auswählen, den vorher kopierten Pfad (inkl. Dateinamen) einfügen und auf "Neu laden" klicken.
   

Ein solcher Pfad kann bspw. so lauten: C:/Users/<Benutzername>/Documents/Fiddler2/Scripts/BrowserPAC.js

Ab sofort wird auch der Verkehr mit Firefox im Fiddler analysiert.

Zweite Möglichkeit (Auch für alle andere Programme):

1. Im Firefox ins selbe Menü wie oben wechseln
   
2. "Manuelle Proxy-Konfiguration" auswählen und dort die IP "127.0.0.1" und den Port "8888" festlegen
   

Hierbei sollte die Einstellung nach der "Fiddler-Session" wieder rausgenommen werden.
Wichtig: Auch die automatische Konfiguration muss wieder herausgenommen werden, da Firefox ansonsten keine Verbindung herstellen kann (Wenn Fiddler nicht läuft).

Siehe auch:

• http://www.fiddlertool.com/Fiddler/help/hookup.asp#Q-NonIE
  

WPF Anwendunggen sind ja derzeit nur recht umständlich zu debuggen. Inzwischen gibt's ein Zusatztool namens Mole: Mole for WPF

Eine ausführliche Dokumentation, Link zu Videos und natürlich der Download selbst, ist auf CodeProject.com zu finden.

Das Tool ist dabei eine große Hilfe da man die aktuellen Werte sehen und verändern kann.

Mit LINQ kann man ja nun alle möglichen Datenquellen abfragen. Ein Beispiel dafür ist eine Abfrage auf ein Verzeichnis und dessen Inhalt:

var files = from file in new DirectoryInfo(@"C:\").GetFiles()

            where file.Name.StartsWith("_")

            select file;

Mein Assembly bekommt einen starken Namen - Erstellen und Signieren einer Assembly mit strong name
Was ist ein ?Strong Name??

Ein Assembly, das mit dem Anwendungsverzeichnis ausgeliefert wird, benötigt in der Regel keinen besonderen Namen. Ein Assembly aber, das von mehreren Anwendungen gleichzeitig benutzt werden soll, braucht einen absolut eindeutigen Namen ? den sogenannten ?strong name? (starken Namen).
Dieser strong name ist ein einfacher Textstring, der sich aus dem Namen der Assembly, einem öffentlichen Schlüssel und einer digitalen Signatur zusammensetzt.
Ein strong name erfüllt folgende Anforderungen:
? Namenseindeutigkeit durch die Verwendung eindeutiger Schlüsselpaare
? Schutz der Versionsherkunft ? nur der Entwickler des Codes kann eine Folge-Version des Assemblies erstellen
? garantiert Integrität der Assembly
? Installation im Global Assembly Cache (GAC) möglich

Um die Vorteile eines Assemblies mit starkem Namen zu behalten und Dll-Konflikte zu vermeiden, können Assemblies mit strong name nur auf Assemblies mit strong name verweisen.

Wie erstelle ich eine Assembly mit einem starken Namen?
Um ein Assembly mit einem starken Namen zu erstellen, muß man zuerst ein Schlüsselpaar aus einem öffentlichen und einem privaten Schlüssel generieren.
Dafür gibt es das Kommandozeilen-Tool sn.exe im Verzeichnis %FrameworkSDK%\bin.
In der Eingabe aufforderung geben Sie folgenden Befehl ein:
Sn -k meinKey.snk
Es wird dabei ein Schlüsselpaar in der Datei meinKey.snk angelegt.
Dieses Schlüsselpaar muß dann der Assembly zugewiesen, d.h. signiert werden. Dafür haben Sie zwei verschiedene Möglichkeiten.

1. Signieren über Attribute unter Verwendung der Datei AssemblyInfo.vb bzw .cs:
[C#]
[assembly: AssemblyKeyFileAttribute(@"..\..\meinKey.snk")]

Falls Sie eine IDE, z. B. Visual Studio .NET, verwenden, müssen Sie wissen, wo diese nach der Schlüsseldatei sucht. Visual Basic .NET sucht die Schlüsseldatei beispielsweise in dem Verzeichnis, in dem die Visual Studio-Projektmappe enthalten ist, wohingegen der C#-Compiler die Schlüsseldatei in dem Verzeichnis sucht, in dem die Binärdatei enthalten ist.

2. Signieren über die Nutzung des Kommandozeilen-Tools Assembly-Linker al.exe:
al /out:meinAssembly.dll meinModul.netmodule /keyfile:meinKey.snk

Bei beiden Möglichkeiten wird der öffentliche Schlüssel als sogenannter Token im Manifest der Assembly abgelegt. Ein Token ist ein Teilabschnitt des vollständigen öffentlichen Schlüssels und wird aus Platzgründen oft an Stelle des eigentlichen Schlüssels verwendet. Zusätzlich wird die Assembly mit dem privaten Schlüssel signiert. Diese Signatur ist wiederum Teil des Manifests.

Durch die Umkehrung der Signatur mit Hilfe des öffentlichen Schlüssels kann man nun sicher feststellen, ob eine Assembly auf dem Weg vom Autor zum Empfänger verändert wurde.
Somit kann kein Unbefugter den Code ändern, wenn er nicht im Besitz des vollständigen Schlüsselpaares ist.

Es ist zu empfehlen, ein Schlüsselpaar nur einmal für eine Firma bzw. für ein Projekt zu generieren und diese Datei, vor allem den privaten Schlüssel, gut unter Verschluß zu halten.

Da Sie eine Assembly nach dem Erstellen nicht mehr mit einem strong name signieren können, stellt sich die Frage, was ich als Entwickler tun kann, wenn ich gerade nur über den öffentlichen, nicht aber den privaten Schlüssel verfüge. Darauf gibt es eine einfache Antwort: das verzögerte Signieren.

Wie funktioniert das verzögerte Signieren?
Beim verzögerten Signieren (delayed signing) wird die Assembly vorerst nur teilweise signiert. Dabei wird nur der öffentliche Schlüssel verwendet. Für den privaten Schlüssel und die vollständige Signierung wir Platz reserviert.

Zuerst müssen Sie über den öffentlichen Schlüssel verfügen.

Sollten Sie über das vollständige Schlüsselpaar verfügen und das verzögerte Signieren aus einem anderen Grund anwenden wollen, können Sie den öffentlichen Schlüssel so aus der Schlüssel-Datei herausfiltern:
Sn -p meinKey.snk meinPublicKey.snk
meinPublicKey.snk enthält nun nur den öffentlichen Schlüssel der Datei meinKey.snk.

Nun fügen Sie der AssemblyInfo-Datei zwei benutzerdefinierte Attribute aus dem System.Reflection Namespace hinzu:

[C#]
[assembly:AssemblyKeyFileAttribute("meinPublicKey.snk")]
[assembly:AssemblyDelaySignAttribute(true)]

Dabei wird der Name der Datei mit dem öffentlichen Schlüssel angegeben und das verzögerte Signieren durch den Wert ?true? aktiviert.
Wird das Assembly dann kompiliert, ist es zwar nur teilweise signiert, besitzt aber einen starken Namen und kann im GAC installiert und dort verwendet werden.
Zuvor muß allerdings noch die Überprüfung der Signatur deaktiviert werden, da die Assembly ja über keine gültige starke Namenssignatur verfügt. Diese Deaktivierung können Sie wieder mit dem Strong Name-Tool vornehmen:

Sn -Vr meinAssembly.dll

Zu einem späteren Zeitpunkt, üblicherweise unmittelbar vor der Weitergabe, signieren Sie dann die Assembly mit dem kompletten Schlüsselpaar:

Sn -R meinAssembly.dll

Danach schalten Sie die Verifizierung für die Assembly wieder ein:

Sn -Vu meinAssembly.dll

Hinweis: Bei allen Optionen für Sn.exe wird die Groß- und Kleinschreibung beachtet. Eine vollständige Liste aller Optionen finden Sie in der .NET Framework SDK-Dokumentation unter dem Stichwort 'sn.exe'.

Viele von uns haben ja bereits ihre Anwendung auch mit SQL-Server-Datenbanken am laufen. In diesem Fall hat man aber das Problem bei der Verteilung der Anwendung vor Ort die Datenbankstrukturen aktuell zu halten. Unter FoxPro konnte man dafür ja Stonefield Data Dictionary einsetzen was aber mit SQL-Server nicht mehr funktionert.

Ein Ersatz hierfür gibt es aber, welcher einem auch die Bereitstellung von entsprechenden Installationsscripts massiv erleichtert:

SQL Packager^™

Latest version: 5.5

Packages a database or a database update

• Script your entire database accurately and quickly
  
• Move your database from A to B
  
• Compress your database as a .exe, or launch as a Visual Studio project
  
• Simplify database deployments and installations – SQL Server 2000, 2005 and 2008
  
• Easy roll-out of database application updates across your client base
  

"SQL Packager is one of the most useful tools I have ever seen. The ability to package the database schema and data of preconfigured lookup tables is great. I have tested it using one of our customer databases and it works fine. The new database has been installed correctly on the new server" Thomas Stensitzki, iComCept GmbH

Walk-through

View our short screen-by-screen introductory walk-through

Demo video

Step-by-step demo of SQL Packager in action

Standard Edition €245

Packages a database or a database update.

• Download trial
  
• Purchase
  
• Get a quote
  

Pro Edition €395

SQL Packager Pro offers access to the command line interface.

• Download trial
  
• Purchase
  
• Get a quote
  

With SQL Packager Pro, you can package a database or a database update, as well as automate tasks, thanks to the incorporated command-line interface.

SQL Packager works by scripting and compressing the entire database – schema and data together – and packaging it up as a deliverable .exe file. It does this by scripting separate transactions for schema and data respectively.

When migrating databases, all schema objects, all new tables and their data as well as data with unique indexes or constraints are also scripted.

Installing, updating, or distributing your database now becomes a simple point-and-click procedure. Deploy SQL Server 2005 databases, and applications that depend on them, with no manual scripting!

By letting you compress your packaged database, you can reduce storage overhead and distribute it faster and more easily. SQL Packager also makes it easy to archive your database, and is an excellent solution for making a backup of your database where you don't have SQL Server administration rights.

You can read how iCOMcept in Aachen, Germany, minimized their application deployment window using SQL Packager.

Der Debugger im Studio ermöglicht uns erheblich mehr als bei vielen Kollegen bekannt ist. Über die Verwendung von sogenannten "Attributen" kann man im Quellcode das verhalten des Debuggers steuern. Nähere Informationen dazu gibt's in zahlreichen Foren.

Hier aber mal ganz kurz ein Paar Anregungen:

Attribute

Außerdem kann man die Diagnosefunktionen vom Studio noch erheblich erweitern. Dies hilft z.B. bei der Suche nach Problemen mit der Datenbindung insbesondere innerhalb von WPF-Masken erheblich. So geht's:

Im config-file der Anwendung fügt man folgende Zeilen ein, um sogenannte Listeners zu definieren:

<system.diagnostics>

<sources>

<source name="System.Windows.Data" switchName="SourceSwitch" >

<listeners>

<add name="textListener" />

</listeners>

</source>

<source name="System.Windows.DependencyProperty" switchName="SourceSwitch" >

<listeners>

<add name="textListener" />

</listeners>

</source>

<source name="System.Windows.Freezable" switchName="SourceSwitch" >

<listeners>

<add name="textListener" />

</listeners>

</source>

<source name="System.Windows.RoutedEvent" switchName="SourceSwitch" >

<listeners>

<add name="textListener" />

</listeners>

</source>

<!--

<source name="System.Windows.Media.Animation" switchName="SourceSwitch" >

<listeners>

<add name="textListener" />

</listeners>

</source>

-->

<source name="System.Windows.NameScope" switchName="SourceSwitch" >

<listeners>

<add name="textListener" />

</listeners>

</source>

<source name="System.Windows.ResourceDictionary" switchName="SourceSwitch" >

<listeners>

<add name="textListener" />

</listeners>

</source>

<source name="System.Windows.Markup" switchName="SourceSwitch" >

<listeners>

<add name="textListener" />

</listeners>

</source>

<!--

<source name="System.Windows.Documents" switchName="SourceSwitch" >

<listeners>

<add name="textListener" />

</listeners>

</source>

-->

</sources>

<switches>

<add name="SourceSwitch" value="All" />

<!--add name="SourceSwitch" value="Off" -->

<!--add name="SourceSwitch" value="Verbose" -->

<!--add name="SourceSwitch" value="Warning" -->

<!--add name="SourceSwitch" value="Activity" -->

</switches>

<sharedListeners>

<!-- This listener sends output to the console -->

<add name="console"

type="System.Diagnostics.ConsoleTraceListener"

initializeData="false"/>

<!-- This listener sends output to an Xml file named AvTrace.xml -->

<add name="xmlListener"

type="System.Diagnostics.XmlWriterTraceListener"

traceOutputOptions="None"

initializeData="AvTrace.xml" />

<!-- This listener sends output to a file named AvTrace.txt -->

<add name="textListener"

type="System.Diagnostics.TextWriterTraceListener"

initializeData="AvTrace.txt" />

</sharedListeners>

<trace autoflush="true" indentsize="4"></trace>

</system.diagnostics>

Über den Block <switches> kann man sehr genau entscheiden in welchen Bereichen die Listeners aktiviert werden sollen. Im Quellcode kann man dann die erweiterten Diagnosen über folgenden Code aktivieren:

// tracing fürs binding aktivieren

PresentationTraceSources.Refresh();

PresentationTraceSources.RoutedEventSource.Listeners.Add(new DefaultTraceListener());

PresentationTraceSources.RoutedEventSource.Switch.Level = SourceLevels.All;

WICHTIG: Ausgabe erfolgt im Verzeichnis der EXE in dem Textfile <AvTrace.txt> - kann man im Config File natürlich ändern!