.Net Client DLL Delivery Question

I have a .Net DLL that I created that implements a WCF client that talks to a WCF service, allowing the end-user to pipe data to the server where the service resides.

I use this DLL in client programs I developed for work, but now I wish to use this .Net DLL in a web page so the client can be delivered to an end-user on the net.

ASP.Net has this great feature that allows one to reference a .Net DLL in a web page using the object tag pattern:

<object id="demolib" classid="DemoLib.dll#DemoLib.DemoClass"></object>

What this does is alert the client's runtime environment that specific functionality is available in a .Net DLL (DemoLib.dll in the code above) that may not be present on the client machine. If the requested functionality does not exist, the DLL is transferred to the client and set up in the client's GAC for use by the web page.

I have made it work locally, as well as remotely in a full-trust environment, without an installer. The DLL is delivered via the web page and installed into the GAC for the end-user without problem.

The problems arises when I try to deliver the DLL outside full trust. I don't want end-users to have to set the site that they are connecting to to full trust in order to access the DLL. I have no problem strongly-naming and signing the .Net DLL with a valid ce开发者_Go百科rtificate. The trust for this DLL should be implicit, but it does not seem to be the case.

I believe that there must be a way to allow the user to authorize the delivery and use of the DLL if they wish, but I have not been able to model such a delivery without failure.

The question then is, what is the strategy I should use to allow the user to authorize the DLL's delivery and functionality using the object tag patter above without forcing them to install it (OneClick, MSI, etc.)?

---

So- you want to silently deliver a .NET assembly to a client machine, outside full trust, and have it communicate in the background with a WCF service? This is precisely what the trust system is designed to prevent.

I think you should consider a OneClick deployment. Users should be aware when they are installing software that communicates with the cloud.