Question

I am looking for a possible solution where I can add ShapeMap.dll as a reference,
but when I try to add the reference I get an error stating:

You can’t add reference to ShapeMap.dll, as it was not build against the Silverlight runtime. Silverlight projects will only work with Silverlight Assemblies”

What do I do now?

Answer 1

While Silverlight code may look and smell like good old .NET-backed logic,
the runtime for Silverlight is different from that supporting regular .NET applications.
It is useful to think of the Silverlight runtime as a subset of the .NET runtime: Silverlight is meant to run in a “sandbox” whereby many the unsafe features such as direct access to the file system are not allowed.

For this reason, one can only add Silverlight assemblies to a Silverlight project.

The error you’re getting is therefore as said: the version of ShapeMap.dll you have wasn’t build for Silverlight runtime.

There are two ways out of this situation:

• find or build a Silverlight-backed version of the DLL
• somehow refactor the Silverlight application so that it leverages the features of the DLL by way of WebServices (if that makes sense, for the name ShapeMap.dll indicates that this may deal with UI objects which are hard/impossible to deal with remotely)

To get a Silverlight-backed version of the DLL:
First choice: It may just be that you can get the binary of the Silverlight version of the assembly where you found the .NET version.
Second choice: it may be that you can get the the source code of the [.NET targeting] DLL.
If so you can try -and I stress “TRY”- to make a Silverlight assembly out of it. The problem may be that the source code uses .NET-only idioms/API calls and you’ll then need to convert these; several just .NET-to-SL “gotchas” can easily be converted, others are absolute roadblocks (eg. direct access to the file system, registry etc.), although, it may be possible to merely comment-out the offending sections of the code, if, somehow the Silverlight was not going to use the underlying features of the DLL.

Now… for sake of full disclosure…
there are a few techniques which allow “fooling” Visual Studio so that .NET assembly be accepted within a SilverLight project. See for example “Reusing .NET assemblies in Silverlight”. Beware, however, that while very insightful as to the nature of the .NET and Silverlight runtimes, and possibly useful in some cases, these techniques are undocumented and, more importantly, depending on the subset of .NET API used by the DLL, may merely allow to get over over the build-time blocking, to fall into various run-time errors (when/if the application makes calls into the DLL to methods which in turn invoke .NET-only methods of the runtime).