Host and Add-ins --- sharing host assemblies

re: Host and Add-ins --- sharing host assemblies

Junfeng Zhang — Tue, 29 Nov 2005 08:03:09 GMT

You have to design your app to

1. know there is a change
2. know how to pick up the change.

There is AppDomain.AppendPrivateBinPath. But it is deprecated.

In general it is not a good idea to change probing behavior. If you really want, you can alwyas use Assembly.LoadFrom.

re: Host and Add-ins --- sharing host assemblies

Genna — Tue, 29 Nov 2005 07:13:33 GMT

Jungfeng,
After rereading your post i realised that i had a completely different scenario in my mind when I posted my previous comment. You load plugins in their own appDomains and make them find the shared assemblies they need. My scenario is similar but i try to solve a different task: I want the app, web application in my case, to be able to find plugins at runtime. Each plugin has its own package.config that is used by the app to lacate the services that the plugin provides.
The application is a critical one and adding a plugin should not affect the application (no restart). The user uses an Admin page to decide when the plugin is to be loaded.
I cannot update web.config on plugin deployment at runtime as this will restart the app, is there any way to add directories at runtime where the app will search for dependent assemblies (plug-in dlls).
Thanks
Genna.

re: Host and Add-ins --- sharing host assemblies

Genna — Mon, 28 Nov 2005 20:01:19 GMT

Hello Jungfeng,
You recommended creating a 'merged' app.config file as one of the solutions which I liked most. But I have one question. I am working on an ASP.NET application and by dropping plugin files in a predifined location and making selection from the hosting web application I want to make the host be able to find plugin assemlies at runtime without restarting the running application. Can you clarify the process of creating a merged app.config file, web.config in my case. And if this is purely file stream operations won't this cause the host restart as web.config will cause this restart on its change. One more thing, are there any security considerations for being able to change the web.config from a web application.
Thanks a lot.
Genna.

re: Host and Add-ins --- sharing host assemblies

Junfeng Zhang — Wed, 23 Nov 2005 21:37:49 GMT

hi David,

Good to see you again.

I did not go to PDC. None of the fusion team did.

The host.config change did not make it into v2.0 RTM. It is qualified as DCR and the windows was closed for DCR. Unfortunate but I guess it is not the end of world.

re: Host and Add-ins --- sharing host assemblies

David Levine — Tue, 22 Nov 2005 14:15:17 GMT

Hello Junfeng,

It's been a while since I've had time to get up here - it's been very busy for me. I see you've written quite a few blogs, all of which are very useful. Thanks and keep them coming.

I looked for you at the PDC but unfortunately you did not attend. Was anyone from the fusion team there?

Thanks for remembering our discussions. I choose to use option 3.1. This allows me a great of flexibility and and was fairly easy to implement. All assemblies are strong named, and at build and again at install-time I perform a dependency analysis to ensure consistency and to generate the app.config template.

I did not want to use option 3.2 as it requires me to host the runtime myself rather then use the default loader, although this is an option I may pursue once we move our development over to the 2.0 framework (we still use v1.1). Hopefully, the problem of not honoring the codebase hint until a binding redirect has occurred will be resolved by then. Is this going to be changed?

Also, I have the option of putting assemblies into the GAC. I wrote my own form of Click-Once, one that has the ability to perform post-deploy custom actions. I could easily add a custom action to install assemblies to the GAC. However, I still prefer to keep private assemblies private and not fill the GAC with them. I believe the GAC could become a great source of headaches if misused/overused, so I chose to avoid it. Also, not using the GAC makes uninstall a simple matter of deleting the entire directory tree.

Regards,
Dave