Programming with .NET - General

Plugins, Reflection, the Downloader object and SecurityCritical code

Hi All

There have been a number of posts lately about downloading assemblies in the background. So tonight I decided to try and work up a sample. I hit a few roadblocks, though. The main one is the failure of Assembly.Load to actually load the assembly.

So, I was able to download the assemblies just fine using the downloader, and I have the code in place to do everything I need to do with them to get them on the canvas. However, calling Assembly.Load on the assembly (whether I just force it local or actually download it), resulted in a System.MethodAccessException on Assembly.Load(assemblyname).

"Attempt to access the method failed: System.Reflection.Assembly.LoadFrom(System.String)"

That seemed like a really an odd exception to get back given its usual interpretation, so I googled and managed to find this thread which I completely missed the first time around:

From reading the referenced articles (like this one), I have to conclude that Assembly.Load(string) is considered critical and therefore, despite being exposed, is not something we can call from our application code. Sure enough, after loading it up in Reflector, I see it is indeed marked as such:

[SecurityCritical]
public static Assembly Load(AssemblyName assemblyRef)
{
    StackCrawlMark lookForMyCaller = StackCrawlMark.LookForMyCaller;
    return InternalLoad(assemblyRef, null, ref lookForMyCaller, false);
}

Unless that changes and Assembly.Load is made SafeCritical, or a SafeCritical alternative is provided, it destroys the idea of background downloading assemblies and having a real componentized or plugin-style application model.

Pete

Re: Plugins, Reflection, the Downloader object and SecurityCritical code

As far as I can see, the only (non-adequate) alternative is to write an HTTP handler which will emit XAML, which will reference needed assemblies. I.e. to perform selection of assemblies to load on server and not on client.

Re: Plugins, Reflection, the Downloader object and SecurityCritical code

If I understand what you're suggesting, that won't work, as other than the main assembly specified in x:Class, the other assemblies are all downloaded due to their inclusion in the manifest of the main assembly.

Interesting idea, though :)

Pete

Re: Plugins, Reflection, the Downloader object and SecurityCritical code

Pete,

Thanks for trying this. I was one of the guys thinking about this incremental load idea. This must be something slated for the final release...there's no way you could build a RIA of any substance and not do incremental loading

Thanks again!

Re: Plugins, Reflection, the Downloader object and SecurityCritical code

Not at all. Do not use x:Class, use xmlns with clr-namespace like this:

Then iterate Children of the canvas and you will get your loaded plugins. I tried this and just copied the Plugin1.dll from totally different (but of course SL)project with no references. So you need just text xmlns:plugin1="clr-namespace:Plugin1;assembly=ClientBin/Plugin1.dll" in your XAML and corresponding file in your ClientBin. I have working sample which works, if you need it.

Re: Re: Plugins, Reflection, the Downloader object and SecurityCritical code

Just to correct you all, you can load assemblies downloaded with the Downloader class and then load them. I'm doing it now. I've made a plugins library if anyone wishes to check it out?

Re: Re: Plugins, Reflection, the Downloader object and SecurityCritical code

It would be interesting if you show key lines of code which loads a downloaded assembly.

Re: Re: Re: Plugins, Reflection, the Downloader object and SecurityCritical code

http://svn.digitalnetworks.co.uk/trunk/utilis/Utilis.Plugins/PluginDownloader.cs

It's open source.

Re: Re: Re: Plugins, Reflection, the Downloader object and SecurityCritical code

Thats strange. This directly contradicts what Psychlist1972 says about Assembly.Load excpetion.

Re: Re: Re: Re: Plugins, Reflection, the Downloader object and SecurityCritical code

It definitely does work (although I did just have a quick panic when I realised I was actually referencing the plugins from the main project since I was too lazy to copy them to the ClientBin folder everytime, but I just unreferenced them and did a test copying them manually)

The plugins have to be in the ClientBin in order to allow them to be loaded is the one stipulation I have discovered.

Re: Re: Re: Re: Plugins, Reflection, the Downloader object and SecurityCritical code

If that is working, that's pretty cool stuff, thanks for posting. The code looks almost the same as what I have. So, I would like to check a few things to make sure it doesn't just appear to be working:

1. Are you sure the files aren't coming down with the initial application load (having to be in ClientBin seems to point to that being the case). You can use Fiddler to check this out. Make sure you clear your browser cache first.

2. Since you had to reference them (I know you unreferenced and tried again, but sometimes caching can get in the way here), can you check to see if they show up in the metadata of your main assembly?

3. Can you put an exception handler around your Assembly.Load call and spit out something if you get an exception? In my code, since the Assembly.Load happened as a result of the download complete event, the exception was swallowed and never displayed.

I was trying to do something where the main assembly knew nothing about the downloaded assemblies other than that a class in there implemented a specific interface. I had a button on my main page - when you click it, the download happens. That way I could really tell exactly when the files were downloaded and the classes instantiated.

Pete

Re: Re: Re: Re: Plugins, Reflection, the Downloader object and SecurityCritical code

1. Cleared browser cache, and installed fiddler to check it out, added a 5 second Thread.Sleep() before it started looking for plugins, and there was a 5 second delay (at a guess, i wasn't actually timing) before fiddler showed the http requests for the plugin assemblies.

2. Nope not there.

3. No exception what so ever, loads fine. I did have to play around a bit before settling on this solution, initially tried downloading from anywhere and just loading a byte[] but Assembly.Load hates that, which landed me in the position that it'll only work if the assembly is downloaded using the Downloader class, and it must be in the ClientBin folder (i tried using a seperate /plugins/ folder but it also failed, i think anyway from memory).

Main assembly knows nothing of the files, queries the server for plugin assembly name and location then creates a Plugin object from my Utilis library like so:
new Plugin(string name, Uri location);
e.g.
new Plugin("Facilis.Editor.Plugins.Html, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null", new Uri("ClientBin/Facilis.Editor.Plugins.Html.dll", UriKind.Relative));

Then just feed all the Plugin objects to the PluginDownloader and it goes off and gets them. I'll probably write some documentation on the Trac for it in a bit.

There is the common library that both the plugins and main assembly reference with the plugin interface and that gets pulled down at initial load, but the others don't.

Re: Re: Re: Re: Re: Plugins, Reflection, the Downloader object and SecurityCritical code

I've written some basic documentation here if you fancy looking.

Re: Re: Re: Re: Re: Plugins, Reflection, the Downloader object and SecurityCritical code

Thanks. I'm going to check that out and see what's different with my configuration. Your stuff working seems to contradict what the security documentation says. I also dont't get why my rather simple example failed on assembly.load. I'll dig deeper and see if I can understand what is going on there.

My pattern, with the exception of using attributes, is very similar to yours. I have an IPlugin and use reflection to find out what classes in the assembly implement IPlugin. Right now, the assembly names are hard-coded in the manager class to avoid additional external dependencies.

Re: ClientBin: I had the opposite result. I found that I had to keep everything in the same folder as the Page.xaml in order for the downloader to download it. I moved all the assemblies to that folder, and then the download worked. This is consistent with the preloader example in the getting started, but does seem a bit silly.

Thanks for posting your experience on this. The plot thickens! :)

Pete

Re: Re: Re: Re: Re: Plugins, Reflection, the Downloader object and SecurityCritical code

Ok, that was really dumb on my part and I'm really glad that there are other folks out there trying stuff like this :)

I was calling Assembly.LoadFrom instead of Assembly.Load. I think that was just a control-space error, not a conscious decision. Once I changed to assembly.load, it worked. That still doesn't fit in to the security discussion from that other link, but working is working.

Thanks a TON for pointing out that there really is a working solution to this! I would not have revisited this until the next release if you hadn't pointed that out.

I now have a working, but unpolished, sample that shows how to load a usercontrol dynamically to support segmented/preloader-type applications written 100% in managed code rather than the combination managed/unmanaged sample that is in the quickstarts. Once I polish up a couple bits, I'll post it (probably in a couple days)

FWIW, all the assemblies in my sample are in the same folder as the page.xaml, which isn't ClientBin. I think generally all your DLLs need to be in the same folder, and that can be either the project main folder, or something hanging off of it.

Pete

Re: Re: Re: Re: Re: Plugins, Reflection, the Downloader object and SecurityCritical code

Psychlist1972

I now have a working, but unpolished, sample that shows how to load a usercontrol dynamically to support segmented/preloader-type applications written 100% in managed code rather than the combination managed/unmanaged sample that is in the quickstarts. Once I polish up a couple bits, I'll post it (probably in a couple days)

FWIW, all the assemblies in my sample are in the same folder as the page.xaml, which isn't ClientBin. I think generally all your DLLs need to be in the same folder, and that can be either the project main folder, or something hanging off of it.

That's interesting to know, I shall have to try a few experiments on that then.

As for posting in the next few days, I was wondering if you fancied helping out with the library I have already started making, which is opensource. It's licensed under the MIT license which means both opensource and closed source projects can use it, it's about the most liberal license there is.

Admittedly I've already asked if anyones interested and no one said anything so if you aren't that's fair enough, I just figured if we created useful things like this now then when silverlight 1.1 hits final there will already be these libraries that people can use to speed up there development and increase adoption. And due to the nature of opensource anyone can take a look at it and see if there are any improvements that can be made and put them forward. My aim is to (ideally) make something similar to mootools for javascript, which in my opinion helps things along a lot.

Damien

Re: Re: Re: Re: Re: Plugins, Reflection, the Downloader object and SecurityCritical code

damoxc

As for posting in the next few days, I was wondering if you fancied helping out with the library I have already started making, which is opensource. It's licensed under the MIT license which means both opensource and closed source projects can use it, it's about the most liberal license there is.

Damien

Hi Damien

Not right now. With a major set of changes coming, I hesitate to invest in anything more than samples when it comes to reusable Silverlight 1.1 code. I may revisit after the control model is fleshed out more, if you're still interested at the time.

That being said, I checked out what you have and it is extremely cool. I feel it will be a huge benefit to the Silverlight community both in its current state and when it is complete. If anyone here hasn't checked it out, please take a gander.

Pete

Re: Re: Re: Re: Re: Plugins, Reflection, the Downloader object and SecurityCritical code

I fully intend to run this through to silverlight final (due to the application I'm making going to be used in production eventually, and that application references the library) so once that happens and you're still interested that would be ace [:)]

And if anyone else feels like helping me make the transitions through the silverlight changes it would only help things.

Re: Re: Re: Re: Re: Plugins, Reflection, the Downloader object and SecurityCritical code

Hi all

I posted a quick and dirty sample that illustrates that here.

It doesn't even come close to the plugin framework damoxc is doing (which is quite nice), but it serves its purpose :) My main goal here was to find a managed way to get a preloader working for other application components. The sample in the quickstarts works ok, but it just smacks me as funky. Plus, due to the way the page was swapped out at runtime, the animation never worked correctly when I used that sample when doing the preloader for the carbon calculator.

Pete

Re: Re: Re: Re: Re: Re: Plugins, Reflection, the Downloader object and SecurityCritical code

Pretty cool stuff guys, I can see where this can become extremely handy. Imagine allowing 3rd parties to create new UIs for your applications, and just allow the users to pick which "skin" (which actually is an assembly) they want to use.

Your generic FindByName is nice, I might have to steal that one. Wierd that they did not implement it by default. Oh well, it's still alpha I guess :)

Only small issue I saw in the code was missing using statements around streams.

Roger Larsen