Home/ Questions/Q 1838316
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-17T06:27:43+00:00

How can I find out if a DLL that was created for a desktop

  • 0

How can I find out if a DLL that was created for a desktop application (in .Net) will work in a Silverlight application?
Bonus question: As SilverLight for Windows Phone 7 is a subset of Silverlight, how do I determine if the dll will work in a app created for a Windows Phone 7?

note: As WP7 does not support P/Invoke – it would mean that any .Net dll that uses P/Invoke should not work for a WP7 silverlight app. I would like to know if there is any easy way to determine this (without having to run the app itself).

The reason for this is that I need some image manipulation algorithm implementation and would like to figure out if they will work on the Windows Phone 7 platform before I buy them.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    In brief, it won’t. The two CLR runtimes are completely different, although they have similar interfaces.

    There are three caveats to this:

    (1) If you have the source code, and that code doesn’t depend on anything Silverlight doesn’t support, you can try cross-compiling it for Silverlight, by referencing the source files in a Silverlight project. Sometimes you can get it to work with minor source tweaks, or judicious use of #if defines. Sometimes you can’t.

    (2) In Silverlight 4/.NET 4, you can sometimes reuse assemblies compiled for Silverlight in .NET. The CLR team has a blog post explaining how it works. This is a pretty limited solution, however, because (a) the assemblies first have to be compiled for Silverlight, and (b) these portable assemblies can only call a small set of other assemblies which are themselves portable, such as Mscorlib, System, System.Core, and so forth. (I should note that this won’t work for you, since you’re targeting WP7, which is based on Silverlight 3.)

    (3) You can occasionally muck about with the DLL internals and hack the compiled DLL into believing it’s a Silverlight DLL. There’s a blog post about how to do it here. But again, this is a pretty limited solution, because the assembly can’t call any methods or assemblies that aren’t included in Silverlight. This includes some pretty basic things, like some of the overrides for Buffer.BlockCopy(), that sort of thing. I’d be surprised if this technique worked with a complex commercial image-processing DLL, but stranger things have happened.

    • 0