Nathan
Nathan

Reputation: 75

Sharing classes between Server and Client projects in Silverlight

Problem: Class B is a subclass of Class A. RIA service returns a list of object Bs. Class A and B are both necessarily defined on the server-side. They serialize fine, and I can use them in the primary client project.

I have two other libraries, organized as client libraries. One is for custom controls, and the other is for classes that are shared between custom controls and the actual client project.

I need Class A to be accessible from the Classes library clientside (so that the custom controls can get to it). How can I do this?

I've done this:

http://msdn.microsoft.com/en-us/library/ee707369%28v=vs.91%29.aspx

but the *.shared.cs convention doesn't give libraries other than the actual Client library access to Class A. The second method (Add as Link) does do what I want it to do, except that updating ClassA.cs in the server project doesn't cause the Client version to update, making it necessary to update both class files each time they're changed, which is unacceptable.

edit: Add as Link worked great after trying again several times.

Upvotes: 2

Views: 2710

Answers (1)

Nicholas Carey
Nicholas Carey

Reputation: 74187

In Visual Studio (2010, at least — dunno exactly whe the feature was added), you can add an existing item to a project as a 'link', meaning the source file is shared between projects. Only one version of the source file exists.

  1. Right-click on your project.
  2. Click on 'Add..Existing Item'.
  3. Find the source file of choice and select it.
  4. The 'Add' Button is a drop-down. Click the drop-down icon in the button.
  5. Click on 'Add As Link'.

Easy!

Now any change to the share source file is reflected on both places. The drawback, of course, is that the developer gets no indication that changes to the shared source file might have wider ramifications than she might realize.

Another option would be to create a hard link so two file names reference the same file ('inode' in Unix terms). On the command line, just chant the magic incantation:

fsutil hardlink create <new-filename> <existing-filename>

something like:

fsutil hardlink create c:\foo\bar\some-project\bazbat.cs c:\foo\bar\another-project\bazbat.cs

The restriction is that both names have to be on the same volume.

This has the possibility, of course, confusing your source control system. I'm willing to bet that TFS hasn't consider the possibility that a filesystem isn't necessarily a tree structure and that the same file might exist in multiple directories.

Hard-linked files may be deleted in any order: the file ceases to exist when the last link to gets removed.

The 3rd option, of course, and likely the "best-practice" — hate that term! — is to factor out the shard classes into an independent assembly that gets deployed to both the client and server. If want to limit the number of assemblies floating around, post-build, you can use ilmerge to merge assemblies:

Come to think of it, there's also no reason you can't embed the shared assemblies as embedded resources that get loaded on demand (or even at startup). This might even be cleaner than using ilmerge. Here's how to do that:

http://blogs.msdn.com/b/microsoft_press/archive/2010/02/03/jeffrey-richter-excerpt-2-from-clr-via-c-third-edition.aspx

Upvotes: 1

Related Questions