I plan to call my projects KarlZ.Silverlight.* while the assemblies they produce will be called KarlZ.*. Then I’ll link from the Silverlight project to the existing files in the normal .NET projects.
The Problem – Different CLRs
I’d like to use both MVC (Model-View-Controller) and Silverlight presentation tiers. My development and test environment for MVC is 100{f073afa9b3cad59b43edffc8236236232bb532d50165f68f2787a3c583ed137f} 64-bit while Silverlight only supports 32-bit (for the valid reason of minimizing the payload required to download for a Silverlight application.)
I would like to make sure that my code base supports both.
The crux of the issue is that Silverlight has its own .NET CLR (Common Language Runtime) that is different from the “Real” .NET CLR.
Portable Assemblies – Nope
Late last month I talked about some challenges building a single logic tier for multiple presentation tiers in a post called “Single Logic Tier, Multiple Presentation Tiers – In a 64-bit world”. In that post I concluded that Portable Assemblies were not for me. Portable assemblies were an attempt to provide a single set of libraries that would work with both CLRs.
Different Projects, Same Code Files?
So what I started to do was to have the same files referenced by two different projects. To make my life a little bit easier, I actually would place the two project files into the same directory. Of course that means they can’t have the same name. I started by taking the default that means that the project name and the assembly name are similar – i.e., MyProject.proj, MyProject.dll. Now the problem was that as I started to have different layers in my libraries, I was having to use quite a few #if defines for the different references. Wouldn’t it be nice if I didn’t have to do that?
Solution
So what I’m doing is having two projects in different folders. While the projects might have different names: KarlZ.Entities.proj and KarlZ.Silverlight.Entities.proj. However, the name of the assembly generated would be the same: KarlZ.Entities.dll. Additionally, the code files are the same with the files actually residing in the normal .NET project while these files are in the Silverlight project through the Add as Link feature.
Steps
Starting point
I already have a project called Zachrys has lots of base level utility functions in it. For example, I have some classes that make working with IDataErrorInfo implementations much easier. So the Zachrys project with its associated Zachrys.dll already exists. These steps are the ones I used to create the Silverlight functionality.
Create a new Silverlight Class Library
As shown above, I created a new Silverlight Class Library called Zachrys.Silverlight. When I did that I got to following dialog for which I of course chose Silverlight 4 (not Silverlight 3).
Set the Assembly name and Default namespace
I then deleted the Class1.cs file, then brought up the properties for the project. By default, the Assembly name and the Default namespace were set to Zachrys.Silverlight. I changed those to simply Zachrys.
Add a folder
The next task is to add the folder that has the classes for the IDataErrorInfo handling. I placed these in Zachrys.ComponentModel since the namespace for IDataErrorInfo is System.ComponentModel. To do this I merely used the context menu and selected Add –> New Folder. (Note: You cannot Add As Link with a folder, just the files.)
Add the Three Classes
With the newly created folder (ComponentModel) in the Zachrys.Silverlight project I selected “Add Existing Item”. I then navigated to the Zachrys project, into the ComponentModel folder and selected all three files. I then selected “Add As Link”.
Source Control Message
Since all my work is under Source Control using Team Foundation Server (TFS) I get the following warning (once for each file):
Build and Quick Verification
So after I built the project successfully (I had a few more steps that were a bit tricky since I always use Resources.Designer.cs files in my projects under the Properties folder) I went to my Bin folder and opened it using Red Gate’s .NET Reflector. You can see that my classes are there.
Source Control in TFS
That was a bit tricky. I needed to add the “real” files manually it seems (but there are only a few). Here’s what my checkin looked like with the highlighted files being the ones I needed to add manually:
Build Successful
And moments later, the build was successful. Of course some previous posts point to some of the perils that exist here (and have already been worked out).
Very Next…
With this sorted out, my next step is to do the same thing with my unit tests. This library has 100{f073afa9b3cad59b43edffc8236236232bb532d50165f68f2787a3c583ed137f} code coverage, and I don’t want to let that practice suffer.
Ok… So very next, that I couldn’t press the publish button without doing it. So I tried using a normal Unit Test project and not a Silverlight project.
All test ran except one that uses some resources information. Looks like I’m back in the boat of having to sign the assemblies in order for this to work… I’ll check that out later.
One note, I get a yellow question mark when I add Zachrys.Silverlight project to the test project, but all the tests seem to run fine.
I feel better now… Even better if the code coverage were 100{f073afa9b3cad59b43edffc8236236232bb532d50165f68f2787a3c583ed137f}…
(Wouldn’t it be cool if ALL builds were only 18 seconds! 
)
After That…
After my tests are working, then I’ll start to look more at trying to use an MVVM (Model-View-ViewModel) pattern with Silverlight. I’m reading an Alpha Book from APress by Gary Hall called “Pro WPF and Silverlight MVVM: Effective Application Development with Model-View-ViewModel” due out in December. I’ve also been spending some time looking at Caliburn.Micro which is an excellent approach to making MVVM easy through the use of conventions. I’m sure I’ll be posting more on that in the future.