.. exchanging and serializing objects
One the interesting things I ran across while building the Trainer Tool was that I had exchange objects between different parts of the system. I have the excercise and its data in a couple of classes and it's the data that's is used in all parts of the system. I store it in my database (in an XML type field). The HttpHandler requests an excercise object through the web service and uses it to generate an image that is shown on the webpage. And so on. Simply said all the blue arrows in the diagram are used to transport an excercise object.
The excercise object
So all the different components need to have access to the defintion of the excercise object. Well, that's easy. Create a separate project, a class library, and simply set references to that from the other projects. Well, almost. It works for the Web Service and the Web Application, but not for the Silverlight project.
Why not? Well simple enough setting a reference to a project copies the compiled assembly (dll) from that project to the referring project's bin folder. And that just will not work with a Silverlight project. Simply because the it's a different type of dll.
The solution is very simple. Since both the .NET parts and the Silverlight files use the same C# (or VB.NET) code you can use the code in both projects.No, do not copy the class files from the .NET class project to the Silverlight! You will be doing all updates twice. It is quite easy to link the files from the class project. Create a folder to link the files into. And then use the context menu to Add Existing items.
Now, you have linked the class files. When you open one of the files through either of the projects you are in essence opening the same physical file. In the project explorer you can see the linked files with the little shortcut style arrow, which hints at that behavior. You get a warning when you try to open a file for the second time (once directly and once linked) and that makes perfect sense.
That was all
Another time some more information on how serialization poses some trickery as well.