Ralf's Sudelbücher

Es ist wieder mal geschafft: Die dotnet.tv Folge 4 ist geschnitten.

Gestern haben wir uns dafür als Ort einmal keine Kneipe und kein Café ausgesucht, sondern die "heiligen Hallen" von Microsoft in München Lohhof. Auf den ersten Blick scheint das zwar keinen Unterschied zu machen, denn dort gibt es einen Segafredo, in dem wir es uns zunächst einmal gemütlich gemacht haben:

An einem Mac in der Microsoft-Zentrale hat sich dann aber niemand gestört. So tolerant kann die Welt also doch mitunter sein :-)

Interessant war dann von diesem Beobachtungsposten aus zu sehen, wie wer wann zu welchem Zweck während der Arbeitszeit nicht an seinem Schreibtisch sitzt, sondern in der Espressobar. Ja, ja, das ist schon aufschlussreich :-)
Oder anders herum: Mit der Espressobar, dem Fitnessraum gleich nebenan, der guten Katine und den Kaffeeküchen/freien Getränken auf jedem Flur bemüht Microsoft sich einfach sehr, eine angenehme Arbeitsatmosphäre zu schaffen. So angenehm, dass die Mitarbeiter es einfach schwer haben sollen, sich von ihr zu trennen :-)

Aber zurück zu dotnet.tv: Der wirkliche Grund, warum wir Microsoft als Schnittort gewählt haben, war der Wille zum Versuch, die noch ausstehenden Bildschirmszenen einmal nicht mit der Kamera abzufilmen, sondern irgendwie direkt von meinem Laptop abzunehmen. Mit den beschränkten Ausgängen am Laptop war da allerdings nichts zu machen, also hatten wir gedacht, es über den Umweg mit einem Beamer zu probieren. Und den gab es bei Microsoft.

Wie sich dann aber herausstellte, waren unsere Hoffnungen auch hier vergebens :-( Obwohl mit mehr Ausgängen versehen, waren doch keine brauchbaren dabei. Schade. So haben wir es dann erst mit dem Abfilmen der Projektion versucht und schließlich doch wieder die Kamera auf den Bildschirm gerichtet. Die Lichtstärke war dabei einfach doch noch höher. Auch wenn dieses Vorgehen noch nicht optimal ist, so ist das Ergebnis zunächst einmal ausreichend, denke ich. Aufwand und Nutzen müssen auch im Verhältnis stehen. Durch große Schrift in den Powerpoint Slides bei den Animationen ist alles ohnehin besser lesbar als bei den früheren Screenshots. Trotzdem bleiben wir natürlich am Ball, was die Bildschirmdarstellungen betrifft. Es kann und noch besser werden.

Microsoft hat uns dann aber nicht nur den Beamer zur Verfügung gestellt, sondern auch einen großzügigen Raum:

Da hatten wir alle Ruhe der Welt für unsere Arbeit, die denn auch recht zügig voran ging. Bei den Outtakes mussten wir uns allerdings immer wieder gegenseitig versichern, dass sie nicht zu gewagt sind. Ein Absturz der externen Festplatte hat uns dabei Gelegenheit gegeben, die Zusammenstellung auch nochmal zu überdenken.

Auch wenn wir die Bildschirme wieder normal abfilmen mussten, hat das diesmal mehr Spaß gemacht. Denn anders als früher, hatten wir den Ton ja schon im Kasten. Ohne Sprechen ging die Aufnahme daher schneller. Da ich am Ende doch auf eine automatische Animation verzichtet habe, war sie darstellungstechnisch sehr einfach. Und das Einpassen in den geschnittenen Film an den Stellen, wo schon der Ton stand, war dann geradezu trivial. Hier haben wir unseren Produktionsprozess also vereinfacht und gleichzeitig das Ergebnis verbessert, weil der Sound der Erklärungen aus dem Off besser zu den Szenen davor/danach passt.

Jetzt werden gerade die verschiedenen Versionen des Video exportiert bzw. komprimiert: Für jede Folge erzeugen wir:

• 3 Streaming Video Dateien für den Trailer (.wmv)
• 3 Dateien zum herunterladen für das ganze Video (.mpg)
• 3 Streaming Video Dateien für das ganze Video (.wmv)
• 1 Datei mit geringerer Kompression des ganzen Videos für die Veröffentlichung auf der dotnetpro Heft-CD (.mpg)

Wir sind gespannt, wie diese Folge in der Community ankommt. Für uns ist sie jedenfalls - wie sollte es anders sein? :-) - die bisher beste. Allerdings nicht wirklich nur, weil sie die aktuellste ist, sondern weil wir denken, technisch noch besser geworden zu sein und gute "Bilder" (Analogien, Visualisierungen) gefunden zu haben. Aber auch die kürzere Spielzeit von knapp 28min trägt dazu bei.

Auf das Feedback sind wir gespannt.

There´s much talk about O/R mapping tools lately in the .NET world. ObjectSpaces are slowly materializing and more and more 3rd party vendors are offering their solutions. But when looking at the different solutions I´m still feeling kind of uneasy. But today I have been able to lay my finger at least on part of the reasons for my uneasyness: I´m not yet satisfied with the way we bind our programs to databases.

We are used to binding components to other components. And this has become even easier and more robust with the .NET Fx. We simply reference a component in our project (within VS.NET) and immediately the types defined therein become visible/usable, as if they were defined within our project.

Now the same works even for Web Services: We point to some metadata file (WSDL) - and presto, we get a proxy class generated automatically and from then on it seems, as if the services was part of our project.

So my question is: Why are we not able to do right the same with a database?

Why can´t I reference a database in my project - and presto, I get classes generated automatically? Or why can´t I generate some kind of assembly from a DB schema which I can then link into my project?

Why not have something like WSDL for databases? Let´s call it DBDL. Or maybe we have it already and it´s RSD? Ok, that would be fine for me (for now). So why then is there no tool generating classes from RSD? (No, Typed Datasets don´t do the job.)

Let´s see, what do we have for Web Services:
-WSDL describes methods exposed by a service.
-WSDL describes the data passed to/from those methods.
-A proxy class is generated upon referencing a WSDL document.
-SOAP defines the wire format for messages passed to/from services.
-System.Net is the API behind a Web Service proxy class.

So why not deal with databases in a similar way? (At least in most cases.)
-DBDL could describe the "methods" exposed by a database, i.e. stored procs.
-DBDL could describe the data passed to/from those methods.
-DBDL could describe the data accessible by standard methods (SQL select, insert, delete, update), i.e. tables/views, relationships.
-Persistent classes could be generated from the DBDL, and their implementation could differ depending on the datasource or on the persistence technology.
-SQL would be the wire format for messages to the database.
-ADO.NET would be the API behind the persistent classes.

For the same db schema, different DBDL documents could be written, depending on what a DBDL consumer needs to do with the database.

With Web Services nobody wants to link an arbitrary existing class to a Web Service. Instead Web Service proxy classes have just this single purpose of communicating with the remote service. Nobody really cares about their implementation or which class they derive from.
Why should it be different for database access? Why would I want to persist an arbitrary existing class? (Of course there are scenarios where you want/need to do it. But many, many developers will never encounter them.) So I think, generating persistent classes from DBDL would be perfectly fine.

Of course in the end DBDL would not be enough. There still is the question of the persistence API (e.g. what method to call on which object to persist an object?). But I think, that´s easy to solve.

So what I´m looking for is simplicity. I´m a friend of Occam´s Razor. So less entities is better than more. If there is an established programming model to bind to functionality, then why not use it for databases too? Why not view databases as a kind of service? Since we´re not talking about scenarios where cursors are needed, but disconnected data handling, a table definition or a SQL select statement is nothing more than a definition of a collection of objects of a certain type, e.g.

select customerid, companyname from customers ...

can be expressed as

class customers
 public customerid as string
 public companyname as string
end class

class customersCollection
 implements IList
 ...
 public property item(index as integer) as customers
  ...
 end property
 ...
end class

Quite a few O/R mapping tools are of course doing a great job - but (as far as I know) they still make database access something very special. Of course, there needs to be a special API, persistence is not transparent, but getting to the point when I can start programming in a strongly typed manner against a certain database still takes very long.

So my bottom line is: Not all our tools need to change. But our view of how to work with databases.
Maybe it´s not a large step, but still, I think, some step(s) need to be taken.

PS: By the way, one of my premisses is, that there are several kinds of database access needs/strategies. Some things can only be done with serverside cursors, for example (e.g. reporting on huge amounts of data). Some things, on the other hand, can be done in a disconnected manner by caching data (e.g. with DataSet). I´m concerned with the latter, which makes up a large part of many business applications. The former does not need an object oriented access to data.
Another of premise of mine is, that O/R mapping should not try to accomodate any and all existing database schemas. O/R mapping should limit itself to a number of structures/patterns. If, then, for some reason (e.g. performance) a database needs to go beyond them, it cannot be handled/mapped to objects. Or to say it the other way round: databases to be O/R mapped to objects should adhere to some rules (e.g. every single table has an explicit surrogate primary key). Since rules for database modelling are not new (we all know normalization rules), a couple of more rules should not appall db modellers.

Der heutige Tag war recht unspektakulär. Wir haben nur geschnitten. Allerdings mal wieder an einem anderen Ort: im Café Puck. Denn das Café Puck ist einer der kostenlosen Münchener Hotspots! Dort in der Öffentlichkeit zu arbeiten, gutes Essen zu genießen und nicht den Kontakt zum Rest der Welt zu verlieren, war schon sehr bequem.

Auch wenn wir von 9:30h bis 20:30h dort gearbeitet und nicht fertig geworden sind, ist es doch gut voran gegangen. Die Vorarbeit von gestern hat sich ausgezahlt. An anderen Stellen jedoch, mussten wir einigen Aufwand treiben, weil wir Neues ausprobieren wollten: Bilder mit Text aus dem Off unterlegen, Zeitraffer, annimierte Überblendungen sind für uns, die wir mit dem Profiprogramm Final Cut Pro erst anfangen, eben noch neu. Aber mit einem guten Buch ("Final Cut Pro 3", Andreas Zerr, Galileo 2002) haben wir dann doch alles hinbekommen. Noch nicht perfekt, aber vorzeigbar.

Neben "Spezialeffekten" haben aber auch Dialoge Aufwand gekostet und allgemein Passagen, für die es kein genaues Drehbuch gibt/geben kann. Denn dann muss viel Material gesichtet und bewertet, dann müssen Ausschnitte testweise zusammengesetzt werden, um die Wirkung zu beurteilen. Der Teufel steckt eben im Detail. Was so einfach im Drehbuch aussieht ist dann beim Schnitt oder Dreh oft am schwersten.

Trotz allgemeiner Zufriedenheit mit dem heutigen Tag hat uns eines allerdings doch eine Träne ins Auge getrieben: In der Aufregung um den unerwartet leeren zweiten Akku hatten wir vergessen, den Ton für eine Textpassage aus dem Off aufzunehmen. Obwohl zum Glück nur Ton fehlte und der auch nur 20 Sekunden ausmacht, haben wir uns geärgert. Denn gerade "künstlichen" Ton - aufgenommen im "Studio" - für Bildschirmszenen wollten wir vermeiden, indem wir auch Textpassagen aus dem Off an den Drehorten der Szenen aufnehmen, die um die Bildschirmpassagen herum liegen.

Für den fehlenden Text haben wir uns dann allerdings dafür entschieden, ihn nachträglich nicht am Drehort aufzunehmen, sondern an einem stillen Ort (im wahrsten Sinne des Wortes ;-) im Café Puck. Das klingt dann zwar nicht 100% "original", aber wahrscheinlich gut genug. Aufwand und Nutzen mussten halt abgewogen werden.

Unsere Lehre für das nächste Mal: noch minutiöser im Drehplan abhaken, was gedreht wurde. Ich werde noch etwas am Dokumentenlayout dafür basteln müssen. Sobald ich meine neue MSDN Subscription habe, werde ich mir deshalb eine Registriernummer für Office 2003 besorgen und ein XML Schema basteln, mit dem ich in Word 2003 Drehbücher strukturiert schreiben - und anschließend mit XSLT in unterschiedliche Darstellungen transformieren kann (Drehplan, Requisitenplan, Drehbuch).

Aber bis dahin ist noch ein wenig Zeit. Erstmal müssen wir in der nächsten Woche diese Folge fertigstellen.

Heute sind wir von unserem bisherigen Vorgehen bei der Produktion etwas abgewichen: obwohl noch nicht alle Szenen gedreht sind, haben wir mit dem Schnitt angefangen.

Bisher war es so, dass zuerst die Szenen mit Personen und Orten auf dem Plan standen und am Schluss dann Bildschirmszenen, d.h. Demos, Animationen. Erst nachdem wir alles gedreht hatten, haben wir dann das Rohmaterial in den Mac geladen und geschnitten.

Dieses Mal probieren wir aber etwas anderes aus. Denn die Bildschirmszenen habe ich nicht mehr ganz getrennt von anderen Szenen geschrieben, sondern aufgeteilt in Ton und Bild. Da die Bildschirmszenen in andere eingebettet sind, haben wir ihren Ton jetzt schon während der "normalen" Dreharbeiten aufgenommen. Der Sound ist dadurch hoffentlich natürlicher.

Das Bild (ohne Ton) für die Bildschirmszenen ist aber weiterhin am Schluss im Drehplan. Da wir nun aber schon den Ton haben, definieren wir schon eine genaue Länge für das Bild. Wir müssen also erstmal wissen, wie lang genau der Ton ist und wann darin was gesagt wird, bevor wir die Bildschirmszenen filmen. Deshalb haben wir den Schnitt vorgezogen. Sobald er abgeschlossen ist, kennen wir die genaue Länge der Sequenzen, die wir dann noch am Bildschirm drehen müssen.

Dieses Vorgehen ist nötig, weil die Soundunterschiede zwischen "Spielszenen" und "Bildschirmszenen" sich in den vergangenen Folgen einfach als zu groß herausgestellt haben, das Budget aber zu klein für eine gute Nachvertonung oder Soundbearbeitung ist. Wir sind auf das Ergebnis gespannt.

Aber nicht nur im Prozess sind wir von der Gewohnheit abgewichen. Auch beim Ort für den Schnitt. Heute waren wir einmal nicht im Café Mozart, sondern im Thalkirchner. Der liegt bei Sebastian und mir quasi um die Ecke - und die Bedienung vom Montag hatte uns so einen schönen Willkommensschriftzug geschrieben.

Sebastian ist dann trotz heftiger Schneefälle mit seinen Skates dort hingerollert. Er kann es halt nicht lassen :-)

Mit der Sportlichkeit war es dann aber bald vorbei, denn das Essen war wirklich lecker:

Irgendwie macht dotnet.tv wahrscheinlich am Ende dick und rund :-)

Abgesehen von einer gewissen Kälte durch offenstehende Eingangstüren hat es uns dann aber gut gefallen. Allemal hatten wir viiiel Platz für unser Equipment:

Manchmal klappen Dinge auch. Das ist schon tröstlich. Nach den Pannen gestern lief heute zur Abwechslung mal eigentlich alles wie geplant.

Angefangen haben wir zwar wieder mit einem Außendreh im Herzen von München, doch das Wetter hat mitgespielt. Statt Schneegestöber einfach nur Kälte. Sehr schön. Zum Aufwärmen sind wir dann mit der Kamera ein wenig Straßenbahn gefahren. Damit ging die Zeit bis 10h schnell herum, denn da wollten wir im Eisbach - einem In-Lokal - mit Darstellern filmen.

Dort nahm man uns nach ein wenig Erklärung sehr freundlich auf und stellte uns die komplette obere Etage bis zum Nachmittag zur Verfügung.

Dieser Ausschluss von Öffentlichkeit bei den Dreharbeiten war denn aber auch nötig. Denn - wie schon im letzten Blogeintrag angedeutet - für diese Folge haben wir keine Mühen und Kosten gescheut, um nicht nur die Herzen der Entwickler zu gewinnen (immerhin muss ich ja als Microsoft Regional Director stetig dem für uns ausgegebenen Motto "winning the hearts and minds of the developers" nachstreben), sondern auch ihre emotionale Beteiligung. Und wie kann das besser geschehen, als durch den vollen Einsatz aller Beteiligten in konzentrierter, ruhiger Atmosphäre

und die Arbeit mit gleichermaßen natürlichen wie sensiblen Darstellern:

Den durch Budgetgrenzen bedingten Mangel an filmtechnischem Equipment haben wir dabei wie immer versucht durch Kreativität wett zu machen:

Dolly, Kamerakran oder Steadycam sind etwas für Warmduscher.
Ein "Leben am Stock" dagegen, wie Sebastian es schon lange für seine Sportvideos praktiziert, ja, das ist etwas für wahre Männer beim Film!

Damit war dann auch anschließend der erste Ansatz einer Actionszene bei dotnet.tv kein Problem:

Straffe Organisation, funktionierende Technik, alles gebende Darsteller: Damit waren wir am Nachmittag sogar etwas vor der geplanten Zeit fertig. Zufrieden mit dem Tag haben wir ihn deshalb mit einer letzten Szene am Abend ausklingen lassen:

Denn entsprechend unserem methodischen Konzept bei dotnet.tv, Wissen in bester pädagogischer Tradition durch Involvierung von Hand, Kopf und Herz zu vermitteln, haben wir den handfesten Analogien und intellektuellen Codeerläuterungen auch noch eine Ansprache des Herzens durch Musik hinzufügen wollen:

Heute war der erste offizielle, voll geplante Drehtag für die dotnet.tv Folge 4. Alles sah auf dem Papier so schön aus. Und gestern hatten wir auch brav eine Drehplanbesprechung.

Aber dann heute... was einiges nach einem starken Start - so ca. die ersten 30min - wie verhext.

Da war z.B. das Wetter:

Kaum forderte dotnet.tv mal wieder einen ricthigen Außendreh, war es kalt und windig und öfter am schneien :-(

Dazu kam dann die Technik: In der letzten Folge hatten wir uns Funkmikros ausgeliehen, um sie einmal zu testen, und haben inzwischen in eigene investiert. Eine schöne Technik mit vielen Teilen zum Spielen - Sender, Empfänger, Kabel, Mischer -, die dazu angetan ist, Männerherzen höher schlagen zu lassen. Letztlich aber ist sie dann doch auch ein wenig eine Last mit dem vielen "Geschlocker". Am Ende haben wir uns daher gegen den Einsatz des Mischers (und Filters) in Szenen mit nur einem Mikro entschieden, um mobiler zu sein.

Aber damit nicht genug: Am Nachmittag mussten wir den ersten Akku auswechseln. Kein Problem, denn wir haben natürlich immer einen zweiten dabei. Der war auch über Nacht eigentlich aufgeladen. Aber nur eigentlich, denn im Einsatz gab er nach kaum 20min den Geist auf :-(

An einer Location, bei der wir eine Drehgenehmigung brauchten, die wir also nicht zu lange mit unserer Anwesenheit beglücken wollten, versagte uns also die Technik. Ohje. Was tun? Akku aufladen? Würde lange dauern, länger, als einen Ersatz aus Batterien zu basteln, meinte Sebastian. Also sind wir mal schnell zum Fröschl gegangen und haben eine Bastelstunde eingelegt:

Das war dann aber leichter gesagt als getan. Aus 15 geplanten Minuten wurden eher 45. Und dann, als endlich alle Kontakte hergestellt waren, die Kamera ansprang - zeigte sie uns, dass sie erkannte, nicht mit einem Lithium-Ionen-Akku betrieben zu werden und stellte ihren Dienst aus Selbstschutzgründen ein :-( Also musste wir doch noch eine zusätzliche Stunde Pause einlegen.

Aber nicht nur die Technik spielte uns einen Streich, auch meine Aufmerksamkeit. Denn in dem Trubel um den schwächelnden Akku hatte ich mein Drehplan-Notizbuch am Drehort liegen gelassen. Würde ich es dort wiederfinden? Zum Glück hatte es jemand bei einem Servicestand abgegeben. Puh...

Trotz aller Unbilden hilt der Abend dann aber noch Spannendes und Positiv für uns bereit. Ein paar Szenen hatten wir auf morgen verlegt, es standen daher nur noch Aufnahmen von Menschenschlangen auf dem Programm. Aber woher nehmen? Die Innenstadt war plötzlich wie leergefegt. Bei Hugendubel keine Schlagen. Beim Bahnhof nicht. Bei McDonalds wollte man uns nicht drehen lassen. Beim Mathäser-Kino schien auch bald der Sicherheitsdienst hinter uns her... So kamen wir auf die Post! Mit versteckter Kamera haben wir dann da - immer wieder unterbrochen durch Passanten im Bild und mistrauische Postangestellte - quasi "undercover" einige Szenen doch noch aufgenommen. Nicht schön, aber abenteuerlich:

Auf dem Rückweg überkam uns dann aber doch noch einmal der Mut und wir wollten ins Mathäser, um noch einen schnellen Überblick über die dortigen Schlangen drehen. Aber diesmal "mit Ansagen". Also bin ich zum Sicherheitspersonal und habe gefragt, wer für Drehgenehmigungen zuständig sei. Und ein freundlicher Herr Derse hat uns dann erlaubt, im Foyer des Kinos zu drehen. Wow! Das war sehr schön, denn jetzt konnten wir unser Equipment offen zum Einsatz bringen und Sebastian war voll in seinem Element:

Mit der Kamera am Stock haben wir hoffentlich ein paar hübsche Perspektiven eingefangen.

PS: Angesichts dessen, dass die Softwareentwicklung immer noch von Männern dominiert wird, haben wir in dieser Folge einmal keine Mühen uns Kosten gescheut, um nicht nur selbst während der Dreharbeiten an Technik Freude zu haben (s.o.), sondern auch den vielen männlichen Zuschauern etwas über harte Technologie hinaus zu bieten:

Das Feedback wird hoffentlich zeigen, ob diese Investition sich positiv auf Motivation und Konzentration der Zuschauer auswirkt oder eher für Ablenkung sorgt.

Manchmal muss man einfach spontan sein: Eigentlich schreibe ich noch am Drehbuch für die 4. Folge von dotnet.tv. Aber heute haben wir trotzdem schon gedreht.

Das Drehbuch forderte ein Beispiel für eine persönliche Betreuung. Eigentlich hatte ich da an eine sehr persönliche Bedienung in einem Laden gedacht - aber dann kam uns die Idee, stattdessen einen Personal Fitness Trainer als Beispiel zu nehmen. Wie gut, dass ich da gestern Abend Margit traf, die Fitness und Hip Hop Trainerin ist.

Margit hatte Lust mitzumachen und da sie am Montag - dem eigentlichen ersten Drehtag - schon nicht mehr in München sein wollte, haben wir eben kurzfristig umdisponiert. Ein Fitness Studio als Drehort hat sie uns flugs besorgt und so konnten wir heute im Body Up Diva filmen. Dort war man sehr nett und unkompliziert - und hatte auch kein Problem damit, dass es eigentlich ein Fitness Studio nur für Frauen ist :-) Sebastian und mir hat das natürlich nichts ausgemacht.

Wie es aber natürlich bei so plötzlichen Entscheidungen ist, haben wir prompt etwas vergessen: das Verlängerungskabel für unser Mikro :-( Zuerst haben wir es dann ohne probiert, aber nur 2 Szenen werden am Ende mit dem Ton sein. Die anderen haben wir dann nochmal gedreht, nachdem der Sound einfach nicht mehr akzeptabel war.

Und was lernt uns das: auch bei spontanen Aktionen immer die Ruhe bewahren. Das Chaos wird dann am Drehort von alleine groß genug :-) Überall liegt dann Zeugs herum, man sucht den Stift, das Drehbuch, die Requisiten... Aber das macht nichts. So ist das halt beim "Guerillafilmen", wenn man kein großes Team hat. Personal Trainer war für dieses Mal drin, aber leider noch kein Skriptgirl, keine Continuity, kein Fahrer, keine Regieassistenz, kein Tontechniker usw. Aber mal schauen, was das Budget an Special Effects hergibt! :-)

When I started playing with Whidbey´s ADO.NET ObjectSpaces object persistence technology (see [1] for an introductory article) I immediately ran into two nasty problems costing me a long time to solve:

1. Trying to avoid problems I started with a sample from Microsoft. But it won´t run at all. Instead it threw the exception "Can not load System.Data.Objectspaces.dll". I was very surprised, since Whidbey otherwise installed ok. So I thought, maybe the wrong versions were referenced in the Microsoft sample project. But that wasn´t the case. Then some newsgroup postings suggested to use absolute paths in the mapping schema file for the OSD/RSD references. This didn´t help either.
Finally the unlikely - or very likely - solution was, to just register System.Data.Objectspaces.dll in the GAC, since it turned out, it hadn´t been registered during installation.
Why this wasn´t done beats me. And I wonder, why only one source in some newsgroup in a slavic language I don´t speak recommended to check, if the assembly had been registered in the GAC.

2. After I had solved the first problem I was optimistic to now be able to really dive down into ObjectSpaces. But when running my VB.NET console app I again wasn´t able to get past the second line of code:

Sub Main()
    Dim conn As New SqlConnection("data source=localhost;database=northwind;integrated security=true")
    Dim os As New ObjectSpace("map.xml", conn)
End Sub

Instanciation of ObjectSpace now failed with the error message "Cannot locate a domain structure for Customer". (Customer being my sample class.) I again tried to put in absolute paths to the mapping files and add namespaces to class names. Nothing helped. Then I moved the type definition from the library project in my solution to the main project - and the error message at least changed. Then I added a namespace to the class name only in the mapping schema file, and the error message changed again.

What that means is: ObjectSpaces requires all types referenced by mapping schemas to be already in memory when it gets instanciated. This is of course no problem in the usual Microsoft demo scenarios, where everything is put into just one project. But real solutions consist of many projects, and class definitions for persistent objects mostly will not be located where ObjectSpaces are created.

So the solution is simple: Either put everything in just one project, or load all assemblies containing types needed by OS mapping schemas before instanciating an ObjectSpace. The simple solution for me was to first instanciate an object of the only type I needed in my main program:

Sub Main()
    Dim x As New ClassLibrary1.Customer
    Dim conn As New SqlConnection("data source=localhost;database=northwind;integrated security=true")
    Dim os As New ObjectSpace("map.xml", conn)
End Sub

3. When I switched from my console application to a winforms app, the above code did not work anymore. The mapping file map.xml could not be loaded. I tried to prefix the filename with the path from Environment.CurrentDirectory - but to no avail. CurrentDirectory does not point to the bin or bin\debug directory of a winforms project during development time. Instead it points to the solution root directory. So I used instead:

IO.Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly.CodeBase)

But this did not solve the problem, but just moved it. Now the mapping files referenced my by mapping schema could not be found. So I finally needed to make the paths in the Location attributes absolute:

<m:Schema Location="c:\...\bin\osd.xml" />

Resources
[1] Jan Tielens, Getting Started with ObjectSpaces