Referencing Silverlight assemblies from non-SL projects


One of the best things about Silverlight is that represents a set of portable functionality that you can expect to run almost anywhere. Its similarity – although reduced – with WPF results in an amazing way to develop rich UIs and logic in Browser-side apps. And then results normal to want to reuse Silverlight code from our own .NET applications.

Reusing code from Silverlight assemblies is possible; the referencing process works well because Silverlight is a subset of .NET Framework, so that “by logic” should just work. Of course this is not all happiness, there are lot of limitations, but it will work as long as you keep yourself into the borders of certain assemblies like Mscorlib , System ,System.Core ,System.ComponentModel.Composition and Microsoft.VisualBasic , playing with others might give you mixed results.

Now the trick.

You SHOULD NOT add the reference to the Silverlight PROJECT.

You MUST add the reference to the Silverlight ASSEMBLY.

So let’s assume you have a scenario with 2 projects, SilverlightCommonTools.dll and WPFMain.exe, targeting Silverlight and WPF respectively.

Steps:
1) Compile your Silverlight library project.
2) Add a reference to your WPF project, locate the compiled Silverlight dll on disk.
3) Code, compile and run!

NOTE: I have selected WPF as an example, but you can reuse your Silverlight code from any .NET code.


The Weird Errors
If you add a reference to the project in Visual Studio, instead of doing what I just said above, you might experience some very weird error messages. Specially some “Could not load assembly ‘some.asembly.dll’”. The “missing” assembly changes depending on your scenario. I got this one from a console app:

Could not load file or assembly 'System.Xml.Linq, Version=2.0.5.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified

And got this one from an ASP.NET:

Could not load file or assembly 'System.Windows, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e' or one of its dependencies. The system cannot find the file specified

It is also important to notice that at least for me, project always compiled fine, the problem was at runtime. But don’t worry, as long as you remember to reference the DLL file directly instead of the project, you will be ok.

Comments

Post a Comment

Popular posts from this blog

Get-ChildItem vs Dir in PowerShell

Image
Batch as usual Recently I was in the need of modifying a huge amount of files across a network share. After installing Serviio media streaming service I noticed that it will crash "randomly". After checking the logs it was clear that ffmpeg was crashing when trying to open subtitle files that were not in the encoding indicated by the Serviio console. I needed a quick way to update all subtitle files to a common encoding, so I decided to convert all files to UTF8. Since I use a windows environment I went directly to PowerShell and wrote this.  Get-ChildItem -path .\ -filter *.srt -file  | ForEach-Object { (get-content $_.FullName) | Out-File $_.FullName -encoding utf8 } This worked almost right except for files with "[" or "]" (among other symbols) on the name or path. To solve it, just added the "-LiteralPath" switch to tell powershell not to consider any wildcards on the path name and just use it exactly as it is.  Get-ChildIt
Read more

The case for a 4 week sprint

Image
Every time we talk about SCRUM, the length of the sprint is stated as a period of "two to four weeks", rarely, however, have I seen people going outside of the 2 weeks. This is not written on stone of course, and while 3 weeks might seems odd, there is a benefit to using a longer period for your sprints.  Image is taken from scrum.org Without any hard data to back that decision, the answer I get from asking about this decision seems to be related to "delivery speed", we assume that because we deliver value to the business every 2 weeks, we are in a more "agile" environment. Well, that might not be so true in every sense or for every project. Let's break some arguments: 1. Sprint length is not equal to the speed of delivery There is more to the speed of development and delivery than the timeframe of the delivery cycle, in a world with DevOps and full CI/CD implemented for your project, you could (should?) actually deliver features every single day all t
Read more

NODE.js fs.readFile and the BOM marker

Working on a ReactJS project, got a small glitch while trying to read a JSON file and parse it as a javascript object. getDataObject() { var dataString = fs.readFileSync("./json/data.json", "utf8"); return JSON.parse(dataString); } output:   SyntaxError: Unexpected token   After checking, double and triple checking again that the file was correct I went deeper and realized that "fs.readFileSync" was returning me the BOM for the UTF file at the beginning of the string. So we just need to strip it out. getDataObject() { var dataString = fs.readFileSync("./json/data.json", "utf8"); return JSON.parse(dataString.replace(/^\uFEFF/, "")); } I then checked and there are "packages" for this, however I don't think is proper to just import a new dependency just to fix something this small. The big issue here is why is this considered correct. The BOM is not
Read more