Three ADO.NET ObjectSpaces Newbie Problems Solved

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