Certainly Jeremiah's code can be abused but what is really interesting to me is how this is one more way to push the limits of what Silverlight can do. 'Hacking' doesn't have to be evil but can be just that pushing the limits and making things better. With that commentary here is the first paragraph and sample code from his article and for the rest you will have to go read his post:
Silverlight 4 + OOB + Elevated Trust gives us the ability to use COM. That would be extremely useful (vs. really useful), except we cannot use just any COM class. It has to support IDispatch (COM automation). It also has to have a ProgID associated to it. That leaves you still with quite a few built-in COM objects to work with, as Justin document's quite well here. What about running our own native or .NET code? One would have to register a COM object first, which requires administrator rights. That’s no fun for an end user! Optimally, it would be nice to be able to add your desktop CLR objects as resources to your XAP, and from Silverlight code, be able to instantiate and use your Desktop .NET classes. This is a hack to do just that.
Huh? What does the hack do?
Let me explain it in code.
/* Create our Desktop .NET helper */
dynamic fullDotNetProxy = fullDotNetProxy = ComAutomationFactory.CreateObject("ClrProxy");
/* Have our .NET helper load up our .NET assembly we extracted from our SL app resources */
dynamic assembly = fullDotNetProxy.GetAssembly(m_assembliesPath + "\\Inject.Test.dll");
/* Get our .NET Type */
dynamic testClassType = fullDotNetProxy.GetDotNetType(assembly, " Inject.Test.TestClass");
/* Create an object instance of our .NET type */
m_testClass = fullDotNetProxy.CreateInstance(testClassType);
/* Run our RunMe method on our .NET object */
Read the rest at: