Spaß mit Visual Studio 2008 – hier: Deployment Projekte

Da denkt man sich, man nimmt mal eben so ein Visual Studio 2005 Projekt, lädt es in Visual Studio 2008 und alles ist hipp. Naja, zumindest bei MSI Setups (Deployment Projekte) hat sich Microsoft erlaubt, einige Fehler leicht inkompatibel zu beheben.

Da ist erst einmal ein Upgrade Setup. Früher war es so, dass bei einem Upgrade erst die alte Version deinstalliert wurde und dann die neuen Dateien installiert wurden. Diese Reihenfolge wurde umgekehrt (ohne eine direkte Konfiguration, die den alten Zustand wieder herstellt). Mit dem Effekt, dass eine Datei nur noch dann ersetzt wird, wenn sich die Dateiversion (nicht der Inhalt) ändert. Bei DVB.NET ist es etwa so, dass alle Dateien die Versionsnummer des Produktes tragen, also 3.2 oder 3.5. Also kein Problem? Leider doch: während der Beta-Phase ändere ich die Versionsnummern im Allgemeinen nicht. Wird also eine 3.5 Beta über eine andere eingespielt, werden die Dateien nicht ausgetauscht! Fazit im Moment: das Setup prüft, ob bereits eine Installation mit gleicher Versionsnummer vorliegt und verweigert dann seinen Dienst mit dem Hinweis, die vorhandene Version zu deinstallieren. Das ärgert für DVB.NET erst mal nur die Beta-Tester, bei VCR.NET leider auch den normalen Endanwender.

Meiner Ansicht nach noch einen Zahn schärfer ist das Ausführen so genannter Custom Actions. Beim VCR.NET etwa sorgt eine solche Custom Action dafür, dass die Konfiguration der Vorgängerversion aus der .EXE.CONFIG.CPY in die .EXE.CONFIG eingepflegt wird, die von der Installation als Template mitgeliefert wird. Bei einer ‘All Users’ Installation laufen Custom Actions nun (wieder nicht durch eine direkte Konfiguration im Visual Studio zu beeinflussen) unter dem Konto LocalSystem. Technisch gesehen ist das auch gut so, da eine ‘All Users’ Installation auch Zugriff auf Ressourcen haben muss, die dem normalen Anwender verwehrt sind. Leider startet beim VCR.NET die Custom Action aber auch die Überwachung. Die erscheint dann auch brav sichtbar, kennt aber nicht die Konfiguration des aktuellen Anwenders und läuft ebenso als LocalSystem. Das ist hier nicht im Sinne des Erfinders. Bis zu einer guten Lösung habe ich das Feature erst mal deaktiviert, der Anwender muss nach der Installation nun die Überwachung manuell in seinem Kontext starten – oder sich ab- und wieder anmelden, da die Überwachung in der Autostart Gruppe landet.

Selbst wenn diese Änderungen durchaus sinnvoll sind (zumindest in fast allen Fällen) hätte ich mir bei einer derart inkompatiblen (breaking change) Änderung schon gewünscht, dass man das alte Verhalten leicht wieder herstellen kann (und nicht durch Manipulation der fertigen MSI mit irgendwelchen COM Schnittstellen). Naja, zuviel erwartet…

Frohes Codieren

Jochen

Zusatz: Hier ein kleiner Vortrag, den ich voraussichtlich am 22. April 2008 bei Bonn-to-Code halten werde.

DVB.NET und .NET 3.5

Ich plane locker, DVB.NET 3.5 auch auf Visual Studio 2008 und .NET 3.5 umzustellen – die Koinzidenz der Versionsnummern ist zufällig. Ich werde dazu noch eine Umfrage im Forum machen, evtl. auch .NET 2.0, aber auf jeden Fall Visual Studio 2008.

Vorab habe ich schon mal geprüft, ob ich auch die BDAWindow Klasse auf WPF umstelle, werde davon aber absehen. Der Lernaufwand um es wenigstens etwas ordentlich zu machen ist mir im Moment zu hoch und ich habe eine ganze Liste anderer kleinerer Wünsche, die ich angehen möchte.

Was ich aber gemacht habe, ist mal zu schauen, wie schwierig es ist, eine WPF Anwendung zu machen, die mit DVB.NET ein Signal anzeigt. Hier der kurze Bericht, vielleicht reizt das ja den einen oder anderen, auch einmal herum zu spielen. DVB.NET 3.2 ist Installationsvoraussetzung, dito Visual C# 2008 – ich weiß nicht, ob die Express Edition reicht, kann aber gut sein.

Als erstes legen wir eine neue WPF Anwendung namens DVBNETSample an. Als zusätzliche Referenzen werden JMS.DVB.DLL und JMS.DVB.Provider.BDA.DLL benötigt – TechnoTrend Premium Anwender sollten der Einfachheit halber auch noch JMS.DVB.Provider.TTPremium.DLL hinzufügen und die TTDVBACC.DLL dorthin kopieren, wo später die DVBNETSample.EXE ausgeführt wird.

Auf dem Fenster Window1 wird nun ein WindowsFormsHost Control angelegt und zum Beispiel so ausgerichtet, dass es das ganze Window1 ausfüllt. Vermutlich geht das Folgende auch einfacher, aber da ich VS2008 erst seit einer knappen Stunde nutze hier mein Weg: in der XAML Ansicht habe ich auf dem Window Root Tag die Eigenschaft xmlns:dvbnet=”clr-namespace:JMS.DVB.BDA;assembly=JMS.DVB.Provider.BDA” ergänzt. Nun kann man im WindowsFormsHost Tag als Kindknoten <dvbnet:BDAWindow/> einfügen. Startet man die Anwendung jetzt, dann gibt es ein blaues Fenster. Ein gutes Zeichen, denn das WinForms BDAWindow läuft nun in der WPF Anwendung – das war eigentlich auch nicht anders zu erwarten.

Nun sind noch zwei Schritte zu erledigen. In der Anwendungsdatei App.xml.cs wird DVB.NET initialisiert und sauber terminiert.

public partial class App : Application
{
    private JMS.DVB.IDeviceProvider m_Device;

    protected override void OnStartup(StartupEventArgs e)
    {
        m_Device = JMS.DVB.Tools.CreateProvider();

        if (null == m_Device)
            Environment.Exit(1);
        else            
            base.OnStartup(e);
    }

    protected override void OnExit(ExitEventArgs e)
    {
        if (null != m_Device)
            m_Device.Dispose();

        base.OnExit(e);
    }

    public JMS.DVB.IDeviceProvider DVBDevice
    {
        get
        {
            return m_Device;
        }
    }
}

Und dann noch ein bisschen Code, um beim Starten der Anwendung den Sender ZDF auszuwählen, den Datenempfang zu aktivieren und Video sowie erste Tonspur an das BDAWindow zu schicken. Durch Doppelklick auf Window1 wird eine Methode angelegt und wie folgt gefüllt.

private void Window_Loaded(object sender, RoutedEventArgs e)
{
    JMS.DVB.IDeviceProvider device = ((App)App.Current).DVBDevice;

    JMS.DVB.Station station = device.ResolveStation("ZDF", null)[0];

    device.Tune(station.Transponder);
    device.SetVideoAudio(0, 0, 0);

    JMS.DVB.AudioInfo[] audios = station.AudioMap;

    JMS.DVB.BDA.BDAWindow wnd = (JMS.DVB.BDA.BDAWindow)windowsFormsHost1.Child;
    JMS.DVB.BDA.AccessModules.AudioVideoAccessor accessor = new AudioVideoAccessor();

    wnd.SetAccessor(accessor);

    accessor.StartGraph(2 != station.VideoType, audios[0].AC3);

    device.RegisterPipingFilter(station.VideoPID, true, false, accessor.AddVideo);
    device.RegisterPipingFilter(audios[0].PID, false, false, accessor.AddAudio);

    device.StartFilter(station.VideoPID);
    device.StartFilter(audios[0].PID);
}

Und das war’s schon

Geht auch mit HDTV

Viel Spass

Jochen

DVB.NET 3.5 – Ein Ausblick oder so

Nachdem ich nun doch schon DVB.NET 3.2 inklusive des DVB.NET / VCR.NET Viewers freigegeben habe, einige sehr rohe Gedanken zur nächsten Version – obwohl ich nicht glaube, dass ich vor Karneval 2008 anfangen werde, etwas Konkretes zu tun. Ich plane auch locker, die Versionsnummer statt auf 3.3 direkt auf 3.5 zu erhöhen. Erst mal überraschend, denn nach aussen hin sichtbar wird sich wenig tun.

Aber im Laufe der Jahre sind einige relativ umfangreiche Teile der Bibliothek relativ schnell enstanden, hier ist an mehreren Stellen mal eine Konsoldierung und ein Review notwendig, vielleicht sogar mal wieder eine Dokumentation für Entwickler (Stichwort Sandcastle – NDoc hat den Sprung nach .NET 2.0 ja nicht geschafft). Das betrifft vor allem die Unterstützung der BDA Treiber. In diesem Bereich werde ich aber vor allem die Anbindung der spezifischen DiSEqC Ansteuerung und (die zur Zeit noch gar nicht angedachte) PayTV Unterstützung via CI/CAM angehen. Für die nächste DVB.NET Version soll hier ein Provider Konzept her, dass eine Nutzung von anderen BDA Treibern durch eine Bereitstellung von kleinen Zusatzmodulen erlauben soll.

Auch der für den Viewer entwickelte Bereich der Anzeige von DirectShow Graphen soll noch einmal mit etwas Abstand betrachtet werden. An dieser Stelle kommt aber auch schon der zweite große Bereich ins Spiel, der etwas Auffrischung braucht. DVB.NET unterstützt heute mit einigen Klassen den Umgang mit Transport Streams: es gibt einen Parser, der zum Beispiel den Datenstrom vom Sender zerlegt, eine Klasse zum Erzeugen von Dateien und einen DirectShow Filter zum Einmischen in einen Graphen. Bei allen Aspekten gibt es noch offene Fragen, die möglicherweise Probleme verursachen. Der Parser verwendet für die Filter etwa keine eigenen Threads zur Datenverteilung, das könnte der Grund sein, warum einige PayTV HDTV Sender nicht gleichzeitig mit der Programmzeitschrift (EPG) aufgezeichnet oder fehlerfrei betrachtet werden können. Die Dateierzeugung hat einen Multiplexer auf Basis der TS Pakete, sondern verwendet die PES Struktur, was möglicherweise die Ursache dafür ist, dass Sender mit einem PES Paket pro GOP Aufzeichnungsdateien erzeugen, die nicht abgespielt werden können. Und die Einmischung von H.264 Material in DirectShow Graphen erkennt die innere Struktur des Datenstroms nicht und kann dem Graphen keine Hinweise auf so genannte Synchronisationspunkte geben, was vermutlich der Grund dafür ist, dass der Viewer FFDShow und andere Decoder nicht zur Anzeige von H.264 Material nutzen kann.

Ach ja: im Zusammenspiel mit dem Viewer wäre auch die Unterstützung einer Fernbedienung Thema für die nächste Version. Hier müsste ich mich auch mal schlau machen, was möglich ist, welche Software existiert und so weiter. Es geht schwerpunktmäßig um verteilte Szenarien, bei denen ein VCR.NET die DVB Hardware verwaltet, der Viewer aber auf einem anderen Rechner läuft und die Fernbedienung dort angeschlossen wird. Die bei den Karten mitgelieferten Fernbedienungen sind daher erst einmal nicht das Thema – auch wenn ich vielleicht damit anfange, da DVB.NET ja zumindest die Nexus diesbezüglich unterstützt.

Viel gesagt, viel Kram In-House, aber vielleicht kommen dabei einige ‘Bug Fixes’ heraus. Und wie immer: mal schauen, was ich davon wirklich umsetzen kann.

Man darf gespannt sein (naja: ich bin es)

Viel Spaß weiterhin mit DVB.NET und Konsorten

Jochen

… und mit VideoText

Nun gut, es wird eine (nicht ganz vollständige) Unterstützung des untersten Konformitätslevels geben, aber vielleicht reicht das schon. Ob es für alle Anwendungsfälle was wird, weiß ich aber noch nicht: im Moment verhindern Probleme bei der Transparenz die Nutzung von Untertitelseiten – das, was mir eigentlich am wichtigsten wäre.

Wie dem auch sei, hier ein erster Eindruck:

VideoText mit dem DVB.NET / VCR. NET Viewer

Bis bald

Jochen

Zusatz: wieder ein kleiner Schritt, zwar nicht für die Menschheit, aber immerhin.

Und doch mit Transparent