Code Splitting von GWT ist eine tolle Sache. Da ich kein Guru bin werde ich mal versuchen das in meinen laienhaften Worten zu erklären. GWT liefert alles was man programmiert an den Client aus, da das teilweise sehr viel sein kann wurde Code Splitting eingeführt. Presenter, deren Proxies mit der ProxyCodeSplit Annotation versehen sind werden erst vom Server nachgeladen, sobald diese das erste mal mit Inject verwendet werden. Dadurch kann der Client den GWT Code schneller laden, da dort nur die notwendigen Sachen hinterlegt werden. Der Code von Presentern die nicht von Anfang an benötigt werden, wird also erst bei deren erster Verwendung vom Server zum Client übertragen.

Diese Möglichkeit lässt es sinnvoll erscheinen, im gesamten Anwendungscode bzw. soviel wie möglich, Code Splitting zu verwenden. Ein zusätzlicher Vorteil ist, die Funktionalität der einzelnen Klassen kann schön klein gehalten werden, da der Presenter notwendige Klassen injiziert bekommen kann. Die Sache hat nur einen Haken: Das Nachladen benötigt erstens etwas Zeit und zweitens muss für jeden gesplitteten Code eine Anfrage an den Server gestellt werden. Jede Anfrage benötigt durch den Overhead noch zusätzlich Zeit, außerdem bearbeiten Browser i.d.R. nur zwei Anfragen an eine Domain gleichzeitig. Wird also ein Presenter angezeigt, der selber mehrere gesplittete Teile enthält, kann dies den Benutzereindruck trüben.

Die Lösung hierfür haben die Entwickler von GWT mit Provider Bundles geschaffen. In einem ProviderBundle legt man alle zusammenhängende Teile fest, die gemeinsam nachgeladen werden sollen. In der Anwendung an der ich gerade arbeite verwenden wir das, um bestimmte Aktionen auszulagern, die von mehreren Presentern verwendet werden können. Dadurch kann jede Aktion in einem übersichtlichen Class File programmiert werden das zudem noch in einer entsprechenden Package Hirarchie für eine leichtere Wartbarkeit abgelegt werden kann. Für jeden Presenter gibt es dann ein ProviderBundle das festlegt, welche Actions mit dem Presenter geladen werden sollen. Code Splitting und Provier Bundles können aber auch anders verwendet werden.

Die GWT bzw. GWTP Dokumentation erklärt das Vorgehen leider (noch) nicht. Für viele mag sich die Verwendung auch aus den Kommentaren der ProviderBundle Klasse erschließen, ich hatte hierbei jedoch einige Anlaufschwierigkeiten. Daher möchte ich hier mal kurz die Vorgehensweise skizzieren:

public class ShowGalleriesA extends UiAction {
	...
}

Das ist die Action Klasse. Die Implementierung ist für den Mechanismus nicht wichtig, daher hab ich sie weg gelassen. Man muss hier eigentlich nur beachten, das es nichts zu beachten gibt ;)
Es ist eine ganz gewöhnliche Java Klasse, es sind keine Annotations oder ähnliches notwendig (außer natürlich das was für die Funktion der Klasse benötigt wird). Auch UiAction, die Basisklasse, enthält nichts was mit dem Code Splitting zu tun hat.

public class DashboardPr extends PlacePresenter {

	@ProxyCodeSplitBundle(bundleClass = DashboardBundle.class, id = DashboardBundle.ID_DashboardPresenter)
	@NameToken(NameTokens.dashboard)
	public interface MyProxy extends ProxyPlace {
	}

	@Inject
	public DashboardPr(
            DashboardIf view,
            MyProxy proxy,
            final ShowGalleriesA aShowGalleries) {
		super(view, proxy);

		setActions(aShowGalleries);
	}
	...
}

Der Presenter hingegen ist schon interessanter. Die normalerweise verwendete @ProxyCodeSplit Annotation wird durch @ProxyCodeSplitBundle ersetzt. In den Parametern der Annotation muss angegeben werden welche Klasse das Bundle definiert und welche ID daraus der des annotierten Proxies entspricht. Siehe Definition des Provider Bundles:

public class DashboardBundle extends ProviderBundle {
	public final static int ID_DashboardPresenter = 0;
	public final static int ID_ActionShowGalleries = 1;
	public final static int BUNDLE_SIZE = 2;

	@Inject
	public DashboardBundle(
			final Provider dashboardPresenter,
			final Provider actionShowGalleries) {
		super(BUNDLE_SIZE);

		providers[ID_DashboardPresenter] = dashboardPresenter;
		providers[ID_ActionShowGalleries] = actionShowGalleries;
	}
}

Sollte eigentlich relativ selbsterklärend sein ;)
Alle Teile des Bundles (die also zusammen geladen werden sollen) werden mit @Inject dem Konstruktor übergeben und in einem Feld providers der Basisklasse ProviderBundle hinterlegt. Wichtig ist hierbei, dass die Größe des providers Array dem Superklassen Konstruktor richtig mitgegeben wird. Am einfachsten macht man das über die gezeigten (und auch von Google empfohlenen) statischen Konstanten mit denen man dann auch auf die jeweiligen IDs der einzelnen Teile des Bundles verweisen kann (siehe Parameter der @ProxyCodeSplitBundle Annotation in der Presenter Klasse).

Nun müssen im Ginjector die AsyncProvider für die Einzelteile definiert werden, damit das Injizieren funktioniert:

public interface MyGinjector extends Ginjector {
	...
	AsyncProvider getCustomerDetailPresenter();
	AsyncProvider getShowGalleriesAction();
	AsyncProvider getDashboardBundle();
	...
}

Und schon wird die Aktion automatisch mit dem Presenter geladen. Einfach oder? ^^

Aber nun zum eigentlichen Problem: das alle Klassen die serialisiert werden sollen das Attribut Serializable benötigen sollte allen klar sein. Was ich jedoch schmerzhaft feststellen musste ist, dass auch jede Klasse die sich für ein Event einer zu serialisierenden Klasse registriert serialisierbar sein muss. Denn die Events werden mit serialisiert, sodass sie nach der Deserialisierung weiter verknüpft bleiben. Bei den Kollegen von Sanity Free Coding wird das ganze auch noch ausführlicher erläutert und auch ein Lösungsvorschlag gegeben.

Der dort beschriebene Ansatz birgt allerdings auch ein paar Stolper-fallen: in dem Beispiel wird das Event nämlich nie mitserialisiert, also auch nicht, wenn die auf das Event lauschende Klasse serialisierbar ist. In meinem Projekt ist es so, dass der Objektbaum über Listen mit Parent Child Funktion verfügt. Darüber kann im Baum hoch und runter navigiert werden. Außerdem bieten die Listen Events, die bei Änderung daran gefeuert werden z.B. wenn ein neues Objekt hinzugefügt oder gelöscht wird. Manche Objekte im Baum müssen wissen, wenn sich was im Baum an anderer Stelle geändert hat, um sich selbst zu aktualisieren und den Baum somit konsistent zu halten. Daher registrieren sie sich für die Changed Events. Diese Events sollten also auch nach der Deserialisierung wieder hergestellt sein. Andererseits registrieren sich auch Oberflächensteuerelemente für die Changed Events, damit die Oberfläche dementsprechend aktualisiert werden kann. Diese Events werden beim Aufbau der Oberfläche aber ohnehin jedesmal neu verdrahtet, müssen also nicht serialisiert werden.

Eine Möglichkeit wäre nun, für jedes Objekt im Modell ISerializable und einen Deserialisierungskonstruktor zu implementieren und die komplette De-/Serialisierung selber zu machen. Dabei könnte man im Deserialisierungskonstruktor die Eventzuordnung ebenfalls jedesmal neu verdrahten. Was aber bei komplexen Objekten wenig Spass macht und bei Änderungen am Objekt jedesmal mit angepasst werden muss. Mein Ansatz ist eine Erweiterung der von Sanity Free Coding vorgeschlagenen Methode. Beim Registrieren der Events in der add sowie beim Deregistrieren in der remove Methode wird das Event Target per Reflection überprüft. Ist das Target serialisierbar, wird das Event einem privaten event zugeordnet, das serialisiert wird. Ist das Target nicht serialisierbar, wie z.B. unsere Oberflächensteuerelemente, wird das event Feld mit vorangestelltem [NonSerializable] verwendet. Genial einfach und einfach genial. Hier noch etwas Code um sich das besser vorstellen zu können:

[NonSerialized]
private EventHandler<ParentChildListChangedEventArgs<C>> changedNonSerializable;
private EventHandler<ParentChildListChangedEventArgs<C>> changedSerializable;

public event EventHandler<ParentChildListChangedEventArgs<C>> Changed
{
    [MethodImpl(MethodImplOptions.Synchronized)]
    add
    {
        if (value.Target.GetType().IsSerializable)
            changedSerializable += value;
        else
            changedNonSerializable += value;
    }
    [MethodImpl(MethodImplOptions.Synchronized)]
    remove
    {
        if (value.Target.GetType().IsSerializable)
            changedSerializable -= value;
        else
            changedNonSerializable -= value;
    }
}

gefeuert wird das ganze dann wie folgt:

protected virtual void OnChanged(ParentChildListChangedEventArgs<C> e)
{
    if (changedNonSerializable != null) changedNonSerializable(this, e);
    if (changedSerializable != null) changedSerializable(this, e);
}

Entweder werden die Entitäten in den partiellen Klassen um die Enum Eigenschaften erweitert. Dieser Ansatz bringt allerdings auch einige Fallstricke mit sich. Eine gute Umsetzung und genauere Erläuterungen findet ihr bei Davy Landman.

Eine andere Möglichkeit ist die Verwendung des “Parse” und des “Format” Events der Datenbindung. Da ich einige ComboBoxen habe und die Events nicht jedesmal komplett neu registrieren möchte, hab ich mir ne kleine Helperklasse geschrieben:

public static class EnumHelper
{
    public static void BindToComboBox(ComboBox comboBox, string propertyName)
    {
        if (typeof(E).IsEnum)
        {
            comboBox.DataBindings[propertyName].Format += (sender, e) => { e.Value = (E)e.Value; };
            comboBox.DataBindings[propertyName].Parse += (sender, e) => { e.Value = (int)e.Value; };

            comboBox.DataSource = Enum.GetValues(typeof(E));
        }
    }
}

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Windows.Forms;
using System.Collections;
using System.Reflection;

namespace com.boobe.salesman.ui.Controls
{
    public class NullableComboBox : ComboBox
    {
        public string NullLabel { get; set; }
        public object NullValue { get; set; }

        private string _displayMember;
        public new string DisplayMember
        {
            get { return _displayMember; }
            set { _displayMember = value; }
        }

        public NullableComboBox()
        {
            NullLabel = "";
            NullValue = null;

            base.ValueMember = "Entity";
            base.DisplayMember = "Title";
        }

        private object _dataSource;
        private IList _items;
        new public object DataSource
        {
            get { return _dataSource; }
            set
            {
                if (value.GetType().IsAssignableFrom(typeof(IEnumerable)))
                    throw new ArgumentException("Nur von IEnumerable abgeleitete Typen sind erlaubt.");

                if (_dataSource != null && _dataSource == value)
                    return;

                _dataSource = value;

                IEnumerable<object> list = (IEnumerable<object>)value;

                _items = new List();
                foreach (object current in list)
                {
                    PropertyInfo propertyInfo = current.GetType().GetProperty(DisplayMember);
                    string title = propertyInfo != null ? propertyInfo.GetValue(current, null).ToString() : current.ToString();
                    _items.Add(new NullableComboBoxItem { Title = title, Entity = current });
                }
                _items.Insert(0, new NullableComboBoxItem { Title = NullLabel, Entity = NullValue });

                base.DataSource = _items;
            }
        }

        new public object SelectedItem
        {
            get
            {
                NullableComboBoxItem selectedItem = (NullableComboBoxItem)base.SelectedItem;
                return selectedItem == null ? null : selectedItem.Entity;
            }
            set
            {
                foreach (NullableComboBoxItem cur in _items)
                {
                    if (cur.Entity == value)
                        base.SelectedItem = cur;
                }
            }
        }

        private class NullableComboBoxItem
        {
            public string Title { get; set; }
            public object Entity { get; set; }
        }
    }
}

Verwendet wird die ComboBox wie folgt:

colorComboBox.NullLabel = "";
colorComboBox.NullValue = null;
colorComboBox.DisplayMember = "ColorName";
colorComboBox.DataSource = context.ProductColors.Where(x => x.Discontinued == false);

Wie der Titel schon sagt verwende ich NetBeans 6.8 mit Glassfish v3 und Maven für meine Java EE 6 Anwendung. Wie es sich gehört wird fleißig Einsatz von JPA gemacht. Hier wird  mal vorausgesetzt, dass die Anwendung schon brav Kontakt zur Datenbank aufgenommen hat, in meinem Fall MySQL, sprich alle JDBC Pools und Connections wurden erfolgreich angelegt. Somit können wir später direkt die Konfiguration der Domains des richtigen Glassfish Application Servers in unserem Embedded Container verwenden um mittels JPA auf die Datenbank zu zu greifen. Wer lieber zum Testen eine seperate Datenbank nehmen möchte kann hier nachlesen wie er da vorgehen muss.

Als erstes muss die embedded Version des Glassfishes in Maven eingebunden werden. Hier ergab sich bereits mein erstes Problem, da sich die Repositories und der notwendige Dependency Eintrag nicht so einfach im Internet finden lassen. Deshalb hier die Abhängigkeit:

<dependency>
  <groupId>org.glassfish.extras</groupId>
  <artifactId>glassfish-embedded-all</artifactId>
  <version>3.0</version>
  <scope>test</scope>
</dependency>

<dependency>
  <groupId>javax</groupId>
  <artifactId>javaee-api</artifactId>
  <version>6.0</version>
  <scope>provided</scope>
</dependency>

Der untere Eintrag wird für den Container zwar nicht benötigt, wird hier aber dennoch erwähnt, da es wichtig ist, das der embedded Glassfish Eintrag vor diesem in der pom.xml erscheint, da es sonst zu Fehlermeldungen beim Testen und Deployen kommen kann.
Der zugehörige Repository Eintrag lautet wie folgt:

<repository>
  <id>embedded-glassfish</id>
  <name>Embedded Glassfish Maven Repository</name>
  <url>http://download.java.net/maven/glassfish</url>
</repository>

Nun sollten diese Abhängigkeiten erstmal durch ein Build besorgt werden um zu sehen ob hier alles geklappt hat. Achtung! die embedded Version des Glassfish hat knapp 45MB, das Herunterladen kann also etwas dauern (wenn man wie ich nur ne 768kBit/s Leitung hat).

Nun kümmern wir uns um die Unit Tests. Dazu poste ich euch hier einen komplett funktionsfähigen Test den ich im Anschluss versuche zu erläutern. Da ich nämlich keinen kompletten Test in anderen Blogs finden konnte, sondern nur Codeschnipsel, hatte ich am Anfang noch mit einigen Exceptions zu kämpfen (naja, ich programmiere erst seit ein paar Wochen in Java, was will man erwarten).

package sample.test.controller;

import sample.controller.UserEntityFacade;
import sample.model.UserEntity;
import java.io.File;
import java.util.HashMap;
import java.util.Map;
import javax.ejb.embeddable.EJBContainer;
import javax.naming.Context;
import org.junit.After;
import org.junit.AfterClass;
import org.junit.Before;
import org.junit.BeforeClass;
import org.junit.Test;
import org.junit.Assert;

public class UserEntityFacadeFixture {

    public UserEntityFacadeFixture() {
    }

    public static EJBContainer container;
    public static Context context;
    public static UserEntityFacade facade;

    @BeforeClass
    public static void setUpClass() throws Exception {
        Map properties = new HashMap();
        properties.put(EJBContainer.MODULES, new File("target/classes"));
        properties.put("org.glassfish.ejb.embedded.glassfish.installation.root", "/Applications/NetBeans/sges-v3/glassfish");
        container = EJBContainer.createEJBContainer(properties);
        context = container.getContext();
        facade = (UserEntityFacade)context.lookup("java:global/classes/UserEntityFacade");
    }

    @AfterClass
    public static void tearDownClass() throws Exception {
        context.close();
        container.close();
    }

    @Before
    public void setUp() {
    }

    @After
    public void tearDown() {
    }

    @Test
    public void CreateUserEntity() {
        UserEntity user = new UserEntity();
        user.setUsername("jack");
        user.setPassword("jack");

        int count = facade.count();
        facade.create(user);
        Assert.assertEquals(count + 1, facade.count());
    }
}

Hauptaugenmerk muss hier natürlich auf die Initialisierung des Containers gelegt werden. Dazu werden statische Variablen angelegt um den Container beim Start des Tests zu Starten und für alle Tests zur Verfügung zu haben. Am Ende der Tests wird der Container und der Context wieder geschlossen. Man beachte auch den import Bereich, da ich bei simpler Angabe von “public static Context context;” in einigen Codeschnipseln nämlich nicht rauslesen konnte das es sich dabei um den “javax.naming.Context” handeln soll. Aber wahrscheinlich ist das allen Java Experten klar.

Beim Erstellen des Containers wird der createEJBContainer Mehtode hier eine Hashmap mit Einstellungen übergeben. Dies ist an dieser Stelle wichtig, da wir JPA verwenden und daher das Verzeichnis vom Glassfish mit angeben müssen, damit der EJB Container die Konfiguration der JDBC Resourcen aus dessen Konfiguration lesen kann. Wird kein JPA verwendet, können die Einstellungen ganz entfallen, sprich es wird kein Parameter übergeben.

Anschließend holt man sich den Context und frägt daraus seine EJBs an. An dieser Stelle hatte ich auch wieder zu kämpfen. Mir war nicht ganz klar wie sich der JNDI Name aufbaut. Beim JBOSS hätte ich jetzt immerhin gewusst wo ich diesen nachschauen kann. Bei TheServerSide werden die mit EJB 3.1 eingeführten globalen JNDI Namen zwar erläutert, doch damit ließen sich meine Beans dennoch nicht auffinden. Nach langem Suchen bin ich dann auf die einfache und funktionierende Version oben gestoßen. Dabei ist der vordere Teil fest und nur der Name der Bean angehängt. Wenn mir jemand diesen Sachverhalt genauer erklären kann darf er sich in den Kommentaren dazu gerne auslassen ;-)

Der Rest des Listings dürfte hoffentlich keine Schwierigkeiten bereiten. Der Vollständigkeit halber hier noch die Blog Posts, die mir hierbei sehr hilfreich waren:

[1] Using the EJBContainer API with or without Maven (but with GlassFish v3)
[2] Unit Testing EJBs and JPA with Embeddable GlassFish
[3] EMBEDDING EJB 3.1 CONTAINER INTO YOUR UNIT TESTS – BOOT TIME: 5 SECONDS
[4] HOW TO UNIT-TEST EJB 3 …IN 0.8 SECONDS [SOURCE CODE INCLUDED]
[5] EJB Lite testing with JUnit and embeddable container

Doch das eigentliche Problem trat bei mir ganz am Anfang der Anleitung auf. Man muss den MySQL Connector für Java im CLASSPATH hinterlegen. Nun reicht es dabei unter Windows schon aus den Connector im Glassfish Verzeichnis in lib zu positionieren, was auf dem Mac unseren geliebten Application Server aber noch lange nicht zufrieden stellt. Nach langem Stöbern bei Onkel Google bin ich über den Beitrag Mac OS X for Java Geeks gestolpert, der mir die CLASSPATH Geschichte des Betriebssystems näher zu bringen versuchte. Allerdings hat auch das Ablegen der Connector JAR Datei im Extension Ordner des Java Verzeichnisses nur wenig Erfolg gezeigt.

Erst in einem Forum Post hab ich die für mich funktionierende Lösung tatsächlich gefunden. Innerhalb von NetBeans kann man die CLASSPATH Variablen verwalten. Dazu geht man im Menü auf “Tools” und anschließend auf “Libraries”. Links findet man eine Liste die in Class- und Server Libraries aufgeteilt ist. Unter Server ist schließlich ein Eintrag “Java-EE-GlassFish-v3″. Nach anwählen kann man sich im Fenster rechts die enthaltenen Bibliotheken ansehen. Nach kurzem durchforsten fällt auf das diese alle unter “/Applications/NetBeans/sges-v3/glassfish/modules/” liegen. Also habe ich kurzerhand den MySQL Connector da rein geschmissen und hier als Library mittels “Add JAR/Folder…” hinzugefügt. Im Anschluss noch kurz Glassfish neugestartet und schon funktioniert der Ping auf den MySQL Connection Pool wie gewünscht. Nun kann mit den oben genannten Tutorials weiter verfahren werden um MySQL zum Connection Pool hinzu zu fügen.

http://social.msdn.microsoft.com/forums/en-US/wcf/thread/8c897f8e-2143-450e-a9f4-97d1f8702da7/

http://nimtug.org/blogs/damien-mcgivern/archive/2008/01/30/wcf-required-precompiled-asp-net-site-to-be-updatable.aspx

Der charmante und gleichzeitig nichts aussagende Fehler “Der Wert darf nicht NULL sein. Parametername: key” hat mich fast in den Wahnsinn getrieben. Gleichzeitig ist es in einer deutschen Entwicklungsumgebung gar nicht mal so einfach auf die richtige Lösung im Internet zu stoßen wenn man erstmal die Fehlermeldung richtig übersetzen muss ;-)

Meine Umgebung läuft auf Windows XP. Entwickelt wird mit Visual Studio 2008 und dem .Net Framework 3.5 SP1. Als IIS kommt die 5.1 Version die bei XP mitgeliefert wurde zum Einsatz. Nur um das mal erwähnt zu haben.

Einfach beim Veröffentlichen den Haken bei “Aktualisierbarkeit dieser vorkompilierten Site zulassen” (zumindest im deutschen Visual Studio) und schon laufen die Webservices ohne Fehlermeldung. Ob sich diese Variante für Anwendungen eignet, die ausgeliefert werden sollen, sei mal dahin gestellt. Für Intranetanwendungen aber ein interessanter Workaround.

Der andere Ansatz ist das Bearbeiten der .compiled Dateien die sich in der Webanwendung im bin Verzeichnis befinden sollten. In meinem Fall lautet der Name der Website in Visual Studio “Website”. Daher werden alle Service Dateien so kompiliert das sie auf “Website\Servicename.svc” verweisen. In den .compiled Dateien sieht das in etwa so aus:

<?xml version="1.0" encoding="utf-8"?>
<preserve resultType="5" virtualPath="/Website/ContentService.svc" [...] customString="/Website/ContentService.svc||ContentService|App_Web_c4jmapxp, [...]">
<filedeps>
<filedep name="/Website/ContentService.svc" />
</filedeps>
</preserve>

Anstatt “Website” sollte man hier nun den Namen des virtuellen Verzeichnisses, das man im IIS verwendet, wählen. Einfach wird es aber wenn man diesen einfach durch eine Tilde ~ ersetzt:

<?xml version="1.0" encoding="utf-8"?>
<preserve resultType="5" virtualPath="~/ContentService.svc" [...] customString="~/ContentService.svc||ContentService|App_Web_c4jmapxp, [...]">
<filedeps>
<filedep name="~/ContentService.svc" />
</filedeps>
</preserve>

Und schon funktioniert die Seite mit WCF Services auch ohne Updatefähigkeit in anderen IIS Umgebungen. Allerdings muss diese Ersetzung jedes mal von Hand in allen .compiled Dateien durchgeführt werden.

Update

Mein Script zum Suchen und Ersetzen ist fertig. Es besteht aus zwei Dateien. Zuerst die LoopThroughCompiledFiles.bat:

for /f %%a IN ('dir /b *.compiled') do call :Replace "%%a"
exit /b

:Replace
cscript //nologo ..\..\replace.vbs /Website ~ %~1
exit /b

Dieses Script macht folgendes: die for-Schleife geht durch den Schalter /f alle Dateien der folgenden dir Abfrage durch. Diese wiederum liefert nur Dateien mit der Endung .compiled. Der Schalter /b sorgt dafür das nur die Dateinamen mit Erweiterungen durchlaufen werden. Anschließend wird mit jedem Dateinamen der Replace Teil aufgerufen. Hier wird ein VB Script zum Suchen und Ersetzen aufgerufen. Wobei die Strings hier mit “/Website” und “~” hartcodiert sind. Mein Dank an dieser Stelle gilt James Welch für seinen hervorragenden Blog Eintrag “How to write a DOS batch file to loop through files“.

Nun hier natürlich auch noch der Code des VB Scripts replace.vbs, den ich von ghostmachine4 aus diesem Forumpost übernommen und angepasst habe (Danke auch dafür):

strOld = WScript.Arguments.Item(0)
strNew = WScript.Arguments.Item(1)
strF1 = WScript.Arguments.Item(2)
strF2 = strF1 & ".replaced"
Const ForWriting = 2

Set fso=CreateObject("Scripting.FileSystemObject")

Set f1 = fso.OpenTextFile(strF1)
Set f2 = fso.OpenTextFile(strF2, ForWriting, True)

Do Until f1.AtEndOfStream
   strLine = f1.ReadLine
   f2.WriteLine(Replace(strLine,strOld,strNew))
Loop

f1.Close
f2.Close

Set f1 = fso.GetFile(strF1)
f1.Delete()

Set f2 = fso.GetFile(strF2)
f2.Move(strF1)

Hier werden zuerst die Übergabeparameter ausgelesen und die entsprechenden Dateien angelegt und geöffnet. Dabei wird in eine temporäre Datei geschrieben. Die Originaldatei wird im Anschluss gelöscht und die temporäre Datei mit deren Dateiname versehen.

C:\delivery\Dev\wix35_public\src\ext\IIsExtension\wixlib\IIsExtension.wxs(65,0): error LGHT0102: The localization variable !(loc.ConfigureIIs) is unknown.  Please ensure the variable is defined.

Um nur einen zu nennen. Um dieses Problem zu umgehen müssen nur die entsprechenden Lokalisierungsvariablen in das eigene Lokalisierungsfile übernommen werden. Damit nicht jeder selber übersetzen muss biete ich euch hier meine Übersetzung an: WiX IIsExtension Lokalisierungsdatei de-DE

Diese Datei entweder in das Verzeichnis /src/ext/IIsExtension/wixlib der WiX Sourcen kopieren und diese neu kompilieren oder die Variablen rauskopieren und in einer eigenen Lokalisierungsdatei hinterlegen und manuell beim Kompilieren und Linken mit WiX angeben.

public static class ThreadSafeInvoker
{
 public static void Invoke(Delegate method, object[] args)
 {
  if (method != null)
  {
   foreach (Delegate handler in method.GetInvocationList())
   {
    if (handler.Target is Control)
    {
     Control target = handler.Target as Control;

     if (target.IsHandleCreated)
     {
      target.BeginInvoke(handler, args);
     }
    }
    else if (handler.Target is ISynchronizeInvoke)
    {
     ISynchronizeInvoke target = handler.Target as ISynchronizeInvoke;
     target.BeginInvoke(handler, args);
    }
    else
    {
     handler.DynamicInvoke(args);
    }
   }
  }
 }
}

Natürlich sind dabei Anpassungen beim Empfänger notwendig. Entweder man leitet seine Klasse von Control ab oder man  erstellt eine eigene Implementierung von ISynchronizeInvoke. Da diese Implementierung aber wohl nicht so einfach von statten geht, gehen viele dazu über einfach von Control abzuleiten auch wenn ihre Klasse nichts mit einem Steuerelement zu tun haben. IDesign bietet hier eine Beispielhafte Implementierung für ISynchronizeInvoke an. Da in meinem Projekt das aktualisieren der Resource ohnehin automatisch im Mainthread statt findet, war keine spezielle Implementierung notwendig.

Weiter ist es aber noch wichtig das An- und Abmelden zu bzw. von einem Event threadsicher zu machen.

private CacheItemChangedEventHandler changedEvent;
readonly object changedEventLock = new object();

public event CacheItemChangedEventHandler Changed
{
 add
 {
  lock (changedEventLock)
  {
   changedEvent += value;
  }
 }
 remove
 {
  lock (changedEventLock)
  {
   changedEvent -= value;
  }
 }
}

Weiter muss beim Auslösen des Events ebenfalls gelockt werden. Da es aber hierdurch ebenfalls zu Deadlocks kommen kann werden die Eventlistener nur im Lockbereich kopiert und anschließend außerhalb des Locks mit der oben erwähnten statischen Klasse informiert:

private void OnChanged()
{
 CacheItemChangedEventHandler copy;

 lock (changedEventLock)
 {
  copy = changedEvent;
 }

 if (copy != null)
 {
  foreach (Delegate cur in copy.GetInvocationList())
  {
   ThreadSafeInvoker.Invoke(cur, new object[] { this, new CacheItemChangedEventArgs(this) });
  }
 }
}

Weiter gab es bei dem Projekt das Problem das es nicht möglich war festzustellen ob sich ein Listener der über das Event informiert werden will bereits bei der Resource registriert hat oder nicht. Eine Möglichkeit wäre gewesen, jedes Resourcenobjekt in eine Liste zu schmeißen und beim registrieren zum Event vorher zu testen ob für die Resource bereits ein Eintrag in der Liste vorhanden ist und wenn ja muss keine erneute Registrierung erfolgen. Da diese Praktik mir als unschön erschien und sich jede Klasse merken müsste ob sie sich schon registriert hat, wurde die add Methode des Events etwas erweitert:

public event CacheItemChangedEventHandler Changed
{
 add
 {
  lock (changedEventLock)
  {
   if (changedEvent != null)
    foreach (Delegate cur in changedEvent.GetInvocationList())
     if (cur.Target == value.Target)
      return;

   changedEvent += value;
  }
 }
 ...
}

So wird ein neuer Listener nur noch hinzugefügt wenn er nicht schon vorhanden ist.

Für Kritik und Anregungen wäre ich euch sehr dankbar.

Wer lieber mit der alten VC++ Version weiter arbeiten möchte, findet auf Teds Blog eine Lösung dafür.