Silverlight 3 & 4 Library Sharing with .NET 4.0 Library or WPF

slwpfapplication

As if you need “another” reason to start running Visual Studio 2010 Beta2, here is another for all the cross platform .NET Line of Business application developers.

Silverlight 3 & 4 Library assemblies can be referenced in .NET 4.0 applications and used. 

The above WPF application has a file reference also known as a binary reference (as opposed to a project reference) to the BusinessEntities.Silverlight.dll and has instantiated the Customer class and used it for the DataContext for the above MainWindow.

How To Do It

The steps are simple, but you need to follow the workflow to avoid issues.

1.  Your Silverlight Library can’t have any “Silverlight specific” code in it.  I have been able to share my own framework code (Ocean) and business entities without any issues. 

Now that Silverlight 4 has shipped and IDataErrorInfo has been added this enables entity sharing between Silverlight and WPF much easier since you no longer have to implement this interface youself just to get code compatibility with your business objects.

2.  Set up a file reference (as opposed to a project reference) between the .NET 4.0 project and your Silverlight 3 or 4 class library .dll.  In the add reference dialog, use the Browse button to locate the target .dll.

slwpfsolution

3.  If you have the Silverlight 3 or 4 library in the same solution as the consuming .NET 4.0 project(s) it is important that you establish the correct project dependencies and build order.  By default, Visual Studio will not alter your project build order when a file reference is make.

In our case, we need the project build order to look like the below image.

ProjectDependencies

To establish the above build order, switch to the Dependencies tab, select the other solution projects that depend on the Silverlight 3 or 4 class library and check the Silverlight 3 or 4 library as pictured below.

BuildOrder

A Few Thoughts

If you have never used file reference projects in your solution a few things in the user experience are slightly different. 

IntelliSense

If you edit the Silverlight 3 or 4 class library, don’t expect those changes to be picked up by the .NET 4.0 project(s) until after you build.  This means, if you added a property or method in the code editor, IntelliSense in the .NET 4.0 project won’t “list it” until you build the solution.

Build Order

Its easy to overlook manually setting the project dependencies to ensure the correct build order since for all other projects you have ever created Visual Studio did this for you.

Also, don’t overlook this step after adding a new project to an existing solution that you’ve already set the build order on.

Clean Solution

If you have the Silverlight 3 or 4 class library in the solution and you clean the solution, the library assembly .dll will be removed from output folder.  This will cause Visual Studio to add some errors to your Error List since it can no long find the referenced assembly.  After building the solution, these errors will be removed from the Error List.

So… if you clean your solution and send it to someone like on a blog post, developers that open your solution will see these errors.  Again, build and all is well.

Service References

Now that you can put your business entities in a Silverlight 3 or 4 class library and your .NET 4.0 service, business and data layers can consume those entities, take full advantage of service reference dialog Advanced settings.  Advanced button is located in the lower left corner of the Add Service Reference dialog.

I have had issues with the Add Service Reference feature when trying to get it to reuse my existing types.  So I always elect to help the wizard and specifically select the assemblies that contain my business entities as I’ve done in the below image.

Note:  The project download does not have a service reference, the below image is from another project.

ServiceReference

I love this feature because it allows me to use my business entities that have code in them in all the layers of my application without any duplication of code.  This also easily enables entity sharing between Silverlight 3 OR 4 and WPF.

Download

The project source code can be downloaded from my SkyDrive.

Source Code (97KB)

Close

Hope you like the new developer productivity capabilities of Visual Studio 2010.

Have a great day,

Just a grain of sand on the worlds beaches.

16 Responses to Silverlight 3 & 4 Library Sharing with .NET 4.0 Library or WPF

  1. Social comments and analytics for this post…

    This post was mentioned on Twitter by kdawg02: Posted on sharing assemblies between Silverlight 3 and 4 and .NET 4.0 assemblies here: http://wp.me/p53lI-iM

  2. progg.ru says:

    Расшаривание Silverlight 3 & 4 библиотек с .NET 4.0 или WPF…

    Thank you for submitting this cool story – Trackback from progg.ru…

  3. stefanolson says:

    Karl,

    Thanks for this post. Very helpful. Yesterday I had discovered that trying to use a project reference causes the debugger to hang.

    Can you explain why a project reference isn’t possible? How do we deal with situations where you do a release build and a debug build and it’s not going to switch between the correct files?

    …Stefan

    • Stefan,

      Yes, a project reference will cause problems. The reason you can’t use it this way, is that it brings in the referenced assembly into the other assembly.

      When you do a file reference nothing is brought in except for exactly what you ask for which is why this works.

      Release/Debug. If the “shared.dll” is in release mode, the simple set a file reference to that file located in the \bin\release.

      This code sharing can take some additional management you’ve not had to deal with before.

      If find that once my “shared.dll” is in release mode, I put it in a common folder with all my other “shared.dll’s” and reference them from that folder.

      Does this help?

      Cheers,

      Karl

  4. […] Silverlight 3 & 4 Library Sharing with .NET 4.0 Library or WPF (Karl Shifflett) […]

  5. […] This post was Twitted by adkinn […]

  6. stefanolson says:

    Karl,

    Thanks for your reply. I’m not quite sure what you mean that it brings the referenced assembly into the other assembly if you’re using a project reference? If I add an assembly to my project as a project reference, when I build, I still get two separate assemblies.

    Whilst I can understand that the tooling may not be there for this feature right away, I do hope that it does become much simpler to implement. It seems like a lot of additional work. I always use project references, which makes the management easier – Visual Studio does all the work for me.

    …Stefan

  7. jdj5a says:

    Karl,

    Please fill us in on what you meant by “it brings in the referenced assembly into the other assembly”. I can’t figure out how to make sense of that, or why the project reference doesn’t work.

    Yes, I recognize that it doesn’t work, and that it won’t work, but understanding the reason and what’s happening is a huge help. Otherwise, I could stumble into pitfalls that I don’t understand.

    Also, any links to more background on the feature of sharing assemblies between SL and .NET would be very helpful. I remember hearing about this at PDC, but I haven’t been able to find a reference of it (other than your post here).

  8. asesta says:

    Hi Karl,

    Thanks for the informative article. Just curious, where are you placing your object save and update code when you share the assemblies like this? Do you have separate Silverlight and .Net assemblies to handle these functions?

    Al

    • Al,

      Currently, I’m sharing Ocean framework code and business entities because that is the same code I’ve been using the linked files feature for. But you “could” add other code to the mix. I don’t share the viewmodel’s or business/data layer code since Silverlight always makes a call across the wire.

      Give this a look: http://blogs.msdn.com/clrteam/

      Cheers,

      Karl

  9. asesta says:

    Karl,

    Thanks for the response and the article link. I am still a bit curious how everything comes together since I am new to the web/Silverlight world. What do your business and data access layers look like? Do you construct your services to handle each operation for each specific business entity (CRUD)? One service for Customer objects another service for Invoice objects and so on.

    Thanks again for your help,

    Al

    • Al,

      The question of services, endpoints, contracts is one of those “it depends.” It could take a book to property answer this question. For my projects, I have an method for each operation. If you search around the web, you’ll find some examples of using just one endpoint for all operations. When I do this, I have one service for each business layer assembly.

      If you don’t want to deal with this, have a look at RIA Services that ships with the SL4 installer. Lots of examples and walk throughs on the web.

      http://blogs.msdn.com/brada/

      Cheers,

      Karl

  10. […] I have written about Silverlight code sharing in this blog post. […]

  11. […] The driving force behind that change is to ( for Silverlight 4 ) make System.ComponentModel.Composition.dll an assembly that you can reference from code libraries that can be shared to target both the .NET Framework on the desktop and the Silverlight .NET Framework. Very cool! For more on shared assemblies, see here. […]

Follow

Get every new post delivered to your Inbox.

Join 248 other followers