Is it possible to reference Silverlight 3 class library by .Net 3.5-based project in VS.net 2008?

Question

First, I know Silverlight project can't reference to non-Silverlight based project like Windows class library or Asp.net MVC project. But I need to create my projects which can support both Silverlight-based project & Asp.net MVC project.

So, I created Silverlight-based project for my sharing source code. It works fine on VS.net 2008 & .Net 3.5 SP1. However, I found some error when I try to use some method of Silverlight-based project from .Net-based project like the following code.

Silverlight-based Method

public static void InitializeInstance(object obj)
{
    // Initialize Field Value
    foreach (FieldInfo fi in obj.GetType().GetFields())
    {
        foreach (Attribute attr in fi.GetCustomAttributes(true))
        {
            if (attr is DefaultValueAttribute)
            {
                DefaultValueAttribute dv = (DefaultValueAttribute)attr;
                fi.SetValue(obj, dv.Value);
            }
        }
    }

    // Initialize Property Value
    foreach (PropertyInfo pi in obj.GetType().GetProperties())
    {
        foreach (Attribute attr in pi.GetCustomAttributes(true))
        {
            if (attr is DefaultValueAttribute)
            {
                DefaultValueAttribute dv = (DefaultValueAttribute)attr;

                if (pi.CanWrite)
                {
                    pi.SetValue(obj, dv.Value, null);
                }
            }
        }
    }
}

.Net-based Method

private void Form1_Load(object sender, EventArgs e)
{
    InitializeInstance(this);
}

Error Detail

System.IO.FileNotFoundException: Could not load file or assembly 'System, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e' or one of its dependencies. The system cannot find the file specified. File name: 'System, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e' at InitializeInstance(Object obj)

Finally, I try to solve this problem by copying system.dll of Silverlight to output directory and reference it. It still shows same error. So, I think this error may be limitation of both .Net & Silverlight platform. Do you have any idea for avoid this issue?

PS. I know I can use this technique for a few sharing code. But it’s impossible to do this for my projects. Because it’s very complicate & very complex more than directly create Silverlight-based or .Net-based class library.

Thanks,

Answer 1

The trouble here is that those types share an assembly with a different strong name: System.Windows in Silverlight, PresentationFramework or PresentationCore on the desktop CLR.

So at runtime, the intended type cannot be loaded, and there are no type forwarders for the Silverlight-to-desktop types.

My recommended solution Consider using file links, instead of actually trying to reference the same built binary.

This way, you can have a source structure for your project that may look like this:

MyApp\
   Silverlight\
     Page.xaml
     Page.xaml.cs
     (link) ..\AspMvc\MySharedDataFile.cs
   AspMvc\
     MySharedDataFile.cs
     MyApp.cs

This way, the source will be re-compiled with both projects. We use this on the Silverlight Toolkit to build many controls, including the charting and data visualization controls, for both WPF and Silverlight. This is by rebuilding for each platform, instead of referencing the binaries from both.

To insert a link in Visual Studio, just right-click on your project or one of its folder, Add Existing Item, then find it in the explorer open file dialog. however, instead of just clicking the button, click on the little down arrow drop-down on the Add file button, and select the "Add as link" option.

Then, it simply builds that file from another location, but it is not a copy, so you can maintain it in one place and use in both.

A crazy solution You can use .NET reflection from your desktop app that is of a much higher trust to actually create a new app domain, hook up to the assembly resolution event, and see what that does. You may be able to instead return the type from the desktop CLR, or just no-op these warnings.

No clue if it works.