So geht Facebook vor

Der klassische Weg ist der viel gescholtene “Gefällt mir” Button. Zahlreiche Seiten binden ihn ein. Besucht nun ein Facebook-Nutzer eine solche Seite, lädt diese die Button-Grafik inkl. eines JavaScripts vom Facebook Server herunter. Ist der Besucher parallel in Facebook eingeloggt, erkennt der Server ihn wieder und kann somit protokollieren, dass Facebook-User X auf Seite Y war. Man bedenke dabei, dass es dazu absolut nicht nötig ist, aktiv auf den “Gefällt mir” Button zu klicken!

Prinzipiell ist es gar nicht notwendig, dass der Benutzer zum Zeitpunkt des Seitenbesuchs bei Facebook eingeloggt ist. Es genügt bereits, dass er irgendwann früher auf diesem Rechner mindestens einmal eingeloggt war und das dabei angelegte Cookie noch vorhanden ist. Das reicht zur Identifizierung des Nutzers völlig aus.

Seiten haben theoretisch sogar noch mehr Möglichkeiten zu evtl. ungewollten Datenlieferungen, z.B. das Mitteilen von gerade abgespielten Songs oder gar getätigte Käufe in Online-Shops. Das von Facebook dazu bereitgestellte Open Graph API wird immer weiter ausgebaut.

Was kann man tun?

Der radikalste, aber wohl sicherste Weg ist natürlich der Verzicht auf einen Facebook-Account. Es ist klar, dass das für viele nicht in Frage kommt. Auch ich möchte Facebook weiterhin nutzen, will aber dessen Sammelaktivitäten v.a. außerhalb dessen Seite behindern. Als Firefox-Nutzer hat man mit dem Add-On NoScript ein hilfreiches Werkzeug.

Allgemein dient NoScript dazu, den Anwender gegen Angriffe durch schädliche JavaScripts auf Webseiten zu schützen. Besonders interessant ist dabei dessen Funktion ABE (Application Boundaries Enforcer). Sie ermöglicht die Definition von beliebigen benutzerdefinierten Regeln, um ungewollte Webseitenaktivitäten einzuschränken. Die Konfiguration verbirgt sich in den NoScript-Einstellungen unter Erweitert und ABE.

Im Textfeld können mit Hilfe einer definierten Syntax die Regeln eingegeben werden. Eine Regel für Facebook liefert bereits die oben verlinkte Dokumentation zu ABE. Leicht abgewandelt ist sie auf meinen Rechnern folgendermaßen im Einsatz:

# Zugriffe auf Facebook-Server von Nicht-Facebook-Seiten blockieren
Site .facebook.com .fbcdn.net .facebook.net
Accept from .facebook.com .fbcdn.net .facebook.net
Deny INCLUSION

Die Regel besagt:

• Zugriffe auf Inhalte von Facebook Servern dürfen nur von Seiten erfolgen, die selbst auf einem Facebook Server liegen. Damit ist die Nutzung von Facebook selbst weiterhin unbeschränkt möglich.
• Zugriffe auf jegliche Facebook Inhalte von fremden Seiten aus werden nicht gestattet bzw. ausgefiltert. Auf diese Weise können also weder die “Gefällt mir” Buttons, noch die dazugehörigen JavaScripts vom Facebook Server nachgeladen werden. Es findet keine Kommunikation dorthin statt.

Und weiter?

Selbst wenn Facebook durchaus mit Vorsicht zu genießen ist, viel spannender ist der Fall mit Google. Eine ähnliche ABE-Regel für Google zu definieren, hilft zwar gegen die ebenbürtigen “+1″ Buttons auf anderen Seiten, doch leider nicht gegen die Datenspuren auf Google-Seiten selbst. Denn leider nutzt man z.B. nicht nur Google Plus als Social Network, sondern auch die alltägliche Suchmaschine, Google Maps, evtl. auch Docs oder Google Mail. Auch hier findet mit großer Sicherheit im Hintergrund eine Verknüpfung der Benutzeraktivitäten zu einem großen Benutzerprofil statt.

Aber diesem Thema würde ich beizeiten einen eigenen Beitrag widmen.

Es zog sich über alle Versionssprünge von 3.5, 4, 5… bis 8. Auch ein komplettes Überspielen mit einem manuell heruntergeladenen Setup änderte nichts. Ein Artikel der MozillaZine brachte schließlich die Idee:

http://kb.mozillazine.org/Software_update#Software_Update_not_working_properly

Einer der früheren Updates muss irgendeine Form von Schaden in den Update-Infos hinterlassen haben. Was half, war das Löschen folgender Verzeichnisse (gilt ab Windows Vista):

C:\Users\<Benutzername>\AppData\Local\Mozilla\Firefox\Mozilla Firefox
C:\Users\<Benutzername>\AppData\Local\Thunderbird\Mozilla Thunderbird

Danach konnten beide wieder nach Updates suchen, ohne sie extra mit Admin-Rechten starten zu müssen.

Grundlagen

NQ Core bietet zentral Methoden zum Absetzen von Log-Nachrichten aus Services heraus. Eine Nachricht besteht aus folgenden Informationen:

• Timestamp der Nachricht
• Level
• Service-Instanz, der die Nachricht generiert
• Text der Nachricht

Nachrichten sind klassisch in mehrere Levels kategorisiert, je nachdem, wie kritisch die Information ist. Per Konfiguration kann nach einzelnen Levels gefiltert werden, um das Aufkommen an Log-Nachricht auf ein sinnvolles Maß einzuschränken.

Die Nachrichten werden auf 2 verschiedenen Wegen verteilt:

• Füllen einer Log-Datei im Benutzerverzeichnis.
• Melden von Log-Meldungen über das MessageLogged Event des Service Manager (siehe weiter unten).

Konfiguration

Die erste Möglichkeit der Konfiguration sind Kommandozeilenparameter, die an die EXE-Datei des NQ Host (nq.exe) übergeben werden können:

Standardmäßig ist im NQ Core immer das Logging von Error- und Warning-Nachrichten aktiviert, sodass mit den o.g. Parametern lediglich zusätzliche Levels hinzugenommen werden können.

Die Konfiguration der Levels kann auch programmatisch erfolgen, indem die Eigenschaften LogEventFilter bzw. LogFileFilter belegt werden:

// Events für alle Levels feuern
NQServiceManager.Instance.LogEventFilter = NQLogType.All;

// Nur Error- und Warning-Messages in die Log-Datei schreiben
NQServiceManager.Instance.LogFileFilter = NQLogType.Error | NQLogType.Warning;

Mittels Fluent Interface ist sogar eine noch bequemere Konfiguration möglich. Im folgenden Code werden alle Levels außer dem Debug-Level in die Log-Datei geschrieben:

ServiceCore.Log.FileLevels = NQLogType.All;
ServiceCore.Log.FileLevels -= NQLogType.Debug;

Wenn das Logging in die Textdatei aktiviert wurde, wird Pfad und Name im Normalfall vom NQ Core bestimmt. Der Ablageort ist das Windows-Einstellungsverzeichnis des jeweiligen Benutzers, unter Windows 7 beispielsweise

C:\Users\<Benutzername>\AppData\Roaming\NQ.<HashDesApplikationsverzeichnisses>.log

Der Dateiname enthält einen Hashwert, der aus dem Ausführungspfad der Anwendung berechnet wird. Dies dient der Unterscheidung von Log-Dateien von NQ-basieren Anwendungen, die in verschiedenen Verzeichnissen installiert sind.

Name und Ablageort der Datei können über den Kommandozeilenparameter -lf geändert werden:

nq.exe -lf C:\EinVerzeichnis\Datei.log

Abschließend seien noch Kommandozeilenparameter zeigt, mit denen Logging grundsätzlich deaktiviert werden kann:

Ausgabe von Meldungen

Services können jederzeit Log-Nachrichten ausgeben, indem sie entsprechende Methoden des Service Managers verwenden:

// Log-Nachricht mit Info-Level
NQServiceManager.Instance.LogMessage(NQLogType.Info, "Das ist eine Info-Nachricht");

// Log-Nachricht mit Angabe der loggenden Klasse
NQServiceManager.Instance.LogMessage(this, NQLogType.Info, "Das ist eine Info-Nachricht");

Es ist auch möglich, bei Auftreten einer Exception diese direkt zum Generieren einer Log-Nachricht zu übergeben:

try
{
    // Some code throwing an exception
}
catch (Exception ex)
{
    NQServiceManager.Instance.LogMessage(this, NQLogType.Error, ex);
}

Das gleiche ist auch mit dem Fluent Interface möglich:

// Log-Nachricht mit Info-Level
ServiceCore.Log.Info("Das ist eine Info-Nachricht");

// Log-Nachricht mit Angabe der loggenden Klasse
ServiceCore.Log.From<object>(this).Info("Das ist eine Info-Nachricht");

try
{
    // Some code throwing an exception
}
catch (Exception ex)
{
    ServiceCore.Log.From<object>(this).Error(ex);
}

Benutzerdefinierte Behandlung von Log-Messages

Wie bereits erwähnt, ermöglicht der NQ Core Services auch eine eigene Behandlung von Log-Nachrichten. Dazu dient das Event MessageLogged:

NQServiceManager.Instance.MessageLogged += ServiceManager_MessageLogged;

…

void ServiceManager_MessageLogged(object sender, NQLogEventArgs e)
{
    // Anzeige einer MessageBox bei Error-Logs
    if (e.LogType == NQLogType.Error)
    {
        MessageBox.Show(e.LogMessage, Application.ProductName,
            MessageBoxButtons.OK, MessageBoxIcon.Exclamation);
    }
}

Eine besondere Eigenschaft betrifft die Log-Nachrichten, die vom Service Manager selbst erzeugt werden. Viele dieser Nachrichten werden nämlich schon erzeugt, bevor überhaupt ein Service aktiv wird. Damit Services auch diese Nachrichten mitbekommen, werden sie während der Startup-Phase vorübergehend gecached. Erst wenn alle Single-Instance-Services geladen und aktiv sind, werden diese zwischengespeicherten Nachrichten “auf einen Schlag” per MessageLogged Event verteilt.

• Der NQ GUI Host (nq.exe) basiert nun endlich auch auf WPF. Bisher war es immer noch eine Windows Forms Applikation, was zu Schwierigkeiten mit WPF-Oberflächen führen konnte.
• Das inzwischen überflüssige INQService Interface wurde entfernt. Auch der Service Manager enthält keine Sonderbehandlung mehr für dieses Interface.
• Verbesserungen an der Fehlertoleranz in den Initialisierungsroutinen des Service Managers.
• Der Service Manager füllt nun die Log-Messages, die er während des Startup erzeugt, in einen Cache. Grund: Sie können von Services nicht mit dem MessageLogged Event abgefangen werden, weil die Services zu dem Zeitpunkt noch nicht aktiv sind. Sobald alle Single-Instance-Services initialisiert sind, werden die MessageLogged Events aus dem Cache “nachgefeuert”.
• Neues Log-Level “Warning”.

Versionierung

Grundsätzlich wertet NQ die gewöhnliche Assembly-Version der Hauptkomponente aus, die wie gewohnt in einer AssemblyInfo.cs definiert wird:

[assembly: AssemblyVersion("1.0.0.0")]
[assembly: NQComponentDefinition("TestComponent", DisplayName = "Test Component")]

Wenn die Komponente nun veröffentlicht wird und später Nachfolgeversionen erscheinen, bietet NQ die Möglichkeit, Zusammenhänge zwischen den Versionen herzustellen, indem deren Kompatibilität zueinander dargestellt wird. Nehmen wir also an, die Version 1.0.0.0 unserer fiktiven “TestComponent” ist bereits veröffentlicht und es wird eine dazu kompatible Nachfolgeversion 2.0.0.0 definiert:

[assembly: AssemblyVersion("2.0.0.0")]
[assembly: NQComponentDefinition("TestComponent", DisplayName = "Test Component")]
[assembly: NQComponentCompatibility("1.0.0.0", NQCondition.Equal)]

Mit NQComponentCompatibilityAttribute wird festgelegt, dass Version 2.0.0.0 zu Version 1.0.0.0 kompatibel ist. Mit der Konstante NQConditon.Equal wird der Vergleichsoperator bestimmt, in diesem Fall ist nur 1.0.0.0 kompatibel. Mit folgender Definition macht man dagegen alle Versionen ab (einschließlich) 1.0.0.0 kompatibel zur aktuellen:

[assembly: NQComponentCompatibility("1.0.0.0", NQCondition.Greater | NQCondition.Equal)]

NQComponentCompatibilityAttribute kann auch mehrfach angewandt werden, um z.B. einen Bereich festzulegen:

[assembly: NQComponentCompatibility("1.0.0.0", NQCondition.Greater | NQCondition.Equal)]
[assembly: NQComponentCompatibility("2.0.0.0", NQCondition.Lower)]

Der Code definiert nun die Kompatibiltät mit allen Versionen x mit 1.0.0.0 <= x < 2.0.0.0.

Nun bleibt noch die wichtigste Frage: Wozu sollte die Kompatibilität überhaupt definiert werden? Sinnvoll wird es erst, wenn wir nun die Abhängigkeiten zwischen verschiedenen Komponenten betrachten.

Abhängigkeiten zwischen Komponenten

Wenn eine Komponente die Anwesenheit einer anderen (evtl. Fremd-)Komponente erfordert, sollte man als Entwickler Vorkehrungen für den Fall treffen, dass diese auf dem System des Benutzers nicht oder nicht in der passenden Version verfügbar ist. In NQ ist hier eine Angabe der Art “Komponente1 benötigt Komponente2″ möglich:

[assembly: NQComponentDefinition("OtherTestComponent", DisplayName = "Other Test Component")]
[assembly: NQComponentRequirement("TestComponent")]

Es wird die Komponente “OtherTestComponent” definiert, die zwingend “TestComponent” erfordert. Ist diese nicht vorhanden, wird auch “OtherTestComponent” von NQ Core ignoriert. Die darin enthaltenen Services werden nicht im System registriert und stattdessen ein Eintrag im Log abgesetzt.

Wir sprachen anfangs von Versionierung. So ist z.B. der Fall möglich, dass die Komponente in einer bestimmten Version vorliegen muss. NQComponentRequirementAttribute lässt auch diese Angabe zu, optional mit einem Vergleichsoperator:

[assembly: NQComponentDefinition("OtherTestComponent", DisplayName = "Other Test Component")]
[assembly: NQComponentRequirement("TestComponent", Version = "1.0.0.0", Condition = NQCondition.Equal)]

So muss “TestComponent” in Version 1.0.0.0 vorliegen, damit “OtherTestComponent” geladen werden kann.

Wenn “TestComponent” jetzt allerdings in einer Nachfolgeversion 2.0.0.0 installiert wird, haben wir ein Problem. Zwar können wir natürlich definieren, dass jede “TestComponent”-Version >= 1.0.0.0 akzeptiert wird, doch birgt dies die Gefahr, dass irgendwann eine inkompatible Version von “TestComponent” erscheint, die so nicht im Voraus ausgeschlossen werden kann.

Hier kommt die am Anfang dieses Beitrags vorgestellte Definition von Kompatibilitäten zum Tragen. Erinnern wir uns daran, dass wir festgelegt hatten, dass Version 2.0.0.0 zu Version 1.0.0.0 von “TestComponent” kompatibel ist:

[assembly: AssemblyVersion("2.0.0.0")]
[assembly: NQComponentDefinition("TestComponent", DisplayName = "Test Component")]
[assembly: NQComponentCompatibility("1.0.0.0", NQCondition.Equal)]

Liegt also jetzt Version 2.0.0.0 vor, “OtherTestComponent” verlangt aber 1.0.0.0, wird der NQ Core die abhängige Komponente trotzdem laden, da die Kompatibilität zur eigentlich verlangten Version (durch deren Entwickler) gewährleistet wurde.

Abhängigkeiten von Services zu Komponenten

Bisher haben wir nur Abhängigkeiten von Komponenten zu anderen Komponenten betrachtet. Am Rande sei noch erwähnt, dass auch für einzelne Services Abhängigkeiten zu Komponenten bzw. deren einzelnen Versionen festgelegt werden können:

[NQExportedService]
[NQComponentRequirement("TestComponent", Version = "1.0.0.0", Condition = NQCondition.Equal)]
public class SomeServiceClass
{
    public SomeServiceClass()
    {
    }
}

Wenn die vom Service verlangte Komponente nicht gefunden wird, wird der Service nicht registriert – er ist dann für andere Services nicht verfügbar. Alles was bisher zu Komponentenabhängigkeiten gesagt wurde, gilt gleichermaßen auch für Services.

Das Nebenprojekt NQ Common Services (NQCS) zu meinem kleinen Microkernel NQ bietet die Grundlage zum Aufbau einer an Visual Studio angelehnten Oberfläche. Da es sich bei NQCS um ein Open Source Projekt handelt, hatte ich mich ursprünglich für das freie AvalonDock entschieden, um dies zu realisieren. Diese Komponente ahmt das Visual Studio-GUI recht gut nach (es wird u.a. von SharpDevelop 4 verwendet), hat allerdings immer wieder einzelne Fehler, ist relativ schlecht dokumentiert und hat ein an manchen Stellen recht umständliches Interface, das die Verwendung mit der NQCS-Architektur immer wieder erschwerte.

Was macht also der Entwickler bei einem Hobbyprojekt? Er erfindet das Rad einfach neu, aber so dass es auch wirklich seinen Wünschen entspricht! So entstand die kleine WPF-Komponente awzBoxes, die ich in diesem Artikel erstmals vorstellen möchte.

Box ist Programm

Wie der Name des Projekts schon andeutet, ist die Box hier die Grundidee des GUI-Aufbaus. Hier ein Screenshot eines mit awzBoxes realisierten Hauptfensters:

Wie üblich werden Tabs zur Untergliederung des Hauptfensters in mehrere Unterfenster verwendet. Im Bild sieht man einen Hauptbereich, in dem Unterfenster neben- und untereinander angeordnet sind. Zudem ist ein weiteres Unterfenster (“Window 1″) auf der linken Seite angedockt. Zur Abbildung der Fensteranordnung verwendet awzBoxes eine Hierarchie von Unterobjekten, die im folgenden Screenshot grafisch dargestellt sind:

• BoxWindowContainer: Der BoxWindowContainer ist das Hauptcontrol von awzBoxes. Dieses wird im Hauptfenster der Anwendung platziert und übernimmt das Hosting der verschiedenen Bereiche des Fensters, Speicherung und Wiederherstellung des Layouts usw.
• BoxArea: Das Hauptfenster ist zunächst in BoxArea Controls untergliedert. Neben dem Hauptbereich sind auch die Seitenleisten, in denen Fenster angedockt werden können, eigene BoxAreas. Der Entwickler kann zur Entwicklungszeit selbst festlegen, auf welchen Seiten des Anwendungsfensters BoxAreas zur Verfügung stehen sollen.
• BoxLine: Zur vertikalen Anordnung ist eine BoxArea in einzelne BoxLine Controls unterteilt. Im oberen Screenshot befindet sich daher “Window 2″ in einer eigenen BoxLine, die anderen Tabs sind in der oberen BoxLine angeordnet. Da die linke Seitenleiste mit dem einzelnen “Window 1″ nicht weiter untergliedert ist, befindet sich implizit ebenfalls eine (einzige) BoxLine in diesem Bereich.
• Box: Eine BoxLine enthält nun wiederum mindestens eine Box. Visuell ist die Box vergleichbar mit einem TabControl, das einzelne Tabs verwaltet. Im Screenshot enthält die obere BoxLine entsprechend zwei Boxes. Bei Seitenleisten haben Box Controls zudem die Besonderheit, eine Titelleiste zu tragen (zu sehen am “Window 1″).
• BoxItem: Ein BoxItem Objekt ist die kleinste Untergliederungsstufe. Diese repräsentiert ein einzelnes Unterfenster bzw. ein Tab. BoxItem ist selbst kein Control, ihm kann jedoch ein Control zugewiesen werden, welches dann im Innenbereich des Unterfensters dargestellt wird. Die BoxItem Klasse bietet Properties zum Festlegen des Fenstertitels, eines optionalen Icons und weitere Anpassungsmöglichkeiten.

Die oben dargestellte Struktur lässt sich initiell komplett in XAML vorbelegen, hier folgt ein entsprechendes Beispiel zu den Screenshots:

<Window x:Class="AWZhome.awzBoxes.TestApp.MainWindow"
		  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
		  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
		  xmlns:box="clr-namespace:AWZhome.awzBoxes;assembly=awzBoxes"
		  Title="MainWindow" Height="622" Width="961">
	<Grid>
		<box:BoxWindowContainer x:Name="BoxWindowContainer">
			<!-- Setzen der Seitenbereiche -->
			<box:BoxWindowContainer.TopBoxArea>
				<box:BoxArea />
			</box:BoxWindowContainer.TopBoxArea>
			<box:BoxWindowContainer.BottomBoxArea>
				<box:BoxArea />
			</box:BoxWindowContainer.BottomBoxArea>
			<box:BoxWindowContainer.LeftBoxArea>
				<box:BoxArea>
					<box:BoxLine>
						<box:Box>
							<!-- "Window 1" -->
							<box:BoxItem Name="Window 1"
										 IsHighlighted="True"
										 Title="Window 1"
										 IsChanged="True"
										 Progress="50"
										 Icon="/NewDocumentHS.png">
								<TextBox></TextBox>
							</box:BoxItem>
						</box:Box>
					</box:BoxLine>
				</box:BoxArea>
			</box:BoxWindowContainer.LeftBoxArea>
			<box:BoxWindowContainer.RightBoxArea>
				<box:BoxArea />
			</box:BoxWindowContainer.RightBoxArea>

			<!-- Hauptbereich des Fensters -->
			<box:BoxArea>
				<box:BoxLine>
					<box:Box>
						<!-- "Fixed Window" -->
						<box:BoxItem Name="Fixed Window" Title="Fixed Window" IsClosable="False">
							<UniformGrid>
								<Button Click="Button_Click">Save layout</Button>
								<Button Click="Button_Click_1">Restore layout</Button>
							</UniformGrid>
						</box:BoxItem>

						<!-- "Window 3" -->
						<box:BoxItem Name="Window 3" Title="Window 3">

						</box:BoxItem>
					</box:Box>
					<box:Box>
						<!-- "Other Window" -->
						<box:BoxItem Name="Other Window" Title="Other Window">

						</box:BoxItem>
					</box:Box>
				</box:BoxLine>
				<box:BoxLine>
					<box:Box>
						<!-- "Window 2" -->
						<box:BoxItem Name="Window 2" Title="Window 2" Closing="BoxItem_Closing">

						</box:BoxItem>
					</box:Box>
				</box:BoxLine>
			</box:BoxArea>
		</box:BoxWindowContainer>
	</Grid>
</Window>

Ein neues Unterfenster in einer eigenen Zeile hinzuzufügen, ist per Code sehr einfach:

BoxLine newBoxLine = new BoxLine();
Box newBox = new Box();
BoxItem newBoxItem = new BoxItem()
{
	Name = "Window 4",
	Title = "Window 4 Title"
};

((BoxArea) this.BoxWindowContainer.InnerAreaControl).BoxLines.Add(newBoxLine);
newBoxLine.Boxes.Add(newBox);
newBox.Items.Add(newBoxItem);

Die Maus macht mobil

Eine Oberfläche wäre nicht flexibel, wenn der Benutzer sie nicht z.B. per Maus vielfältig anpassen könnte. Die von awzBoxes dargestellten Unterfenster lassen sich daher schnell und einfach umordnen:

Nicht nur das Umordnen funktioniert, auch das Verschieben der Tabs zwischen den Boxes oder das Andocken an die Seiten funktioniert ähnlich zu Visual Studio und anderen Anwendungen:

Durch Setzen der Eigenschaften eines BoxItem Objekts kann bestimmt werden, wo ein Unterfenster angedockt werden darf und wo nicht. Hier nur ein kurzes Beispiel:

newBoxItem.AllowedDockAreas =
	BoxItemDockDirection.DockInnerArea | BoxItemDockDirection.DockLeft | BoxItemDockDirection.DockRight;

Das Beispiel legt fest, dass das Unterfenster nur an der linken oder rechten Seitenleiste bzw. im Innenbereich des Fenster eingehängt werden darf.

Abschluss

awzBoxes ist zwar speziell für NQCS entstanden, ist aber davon völlig entkoppelt und kann problemlos direkt in eigenen Anwendungen eingesetzt werden. Allerdings befindet sich die Library momentan in Entwicklung und ist daher nicht als separates Downloadpaket erhältlich. Sie muss vielmehr mit dem gesamten NQ/NQCS Projekt aus dem Sourcecode Repository auf CodePlex heruntergeladen und selbst kompiliert werden. Im heruntergeladenen ZIP-Archiv ist dabei das Unterverzeichnis /awzBoxes von Bedeutung. Darin befindet sich die eigenständige Visual Studio-Solution.