Calling a local .NET UserControl from a local HTML page

[Dave McCracken]

I am hosting .Net UserControls in HTML pages with Object Tags. These
UserControls are clients of remotable objects that run on the same machine.
The remote objects execute callbacks via sponsor objects. The UserControl
client creates and passes these sponsor objects to the remote objects.

I am able to launch .Net UserControls and their dependent .Net components in
HTML pages using the Object tag. I had to do the following to get it to work.

1. Run IIS
2. Build all assemblies with strong names.
3. Remove all copies of existing assemblies from the GAC's download directory.
4. Put the HTML page in the root of my machine's web site (I'm running XP
Pro).
The HTML page uses an Object tag whose classid is
"http:UserControl.dll#Class.Name".
5. Put the UserControl DLL in the same directory as the HTML page.
6. Create a bin directory under the root and copy the dependent DLLs there.
7. Set the Local Security Policy of the Local Machine to Full Trust on the
Intranet Zone to allow access to a remote server that is running on the same
machine.

Questions:
1. I have found that I cannot launch the UserControl unless IIS is running
and all of the above are as specified. Is there a way to launch a .Net
UserControl in an HTML page without running IIS?
2. Do I have to specify the classid as "http:UserControl.dll#Class.Name" or
can I use
something like "file:filespec\UserControl.dll#Class.Name"?
3. Is there a way to make the UserControl version-specific, like we did with
CAB files, so that they will reload and install automatically when an update
is available?

[Francisco Padron]

The <object> tag's CODEBASE will NOT take a file:// url for security reasons
(so that you can not use already installed ActiveX controls with malicious
purposes). So yes, the page needs to come from a web server.

Is there a way to make the UserControl version-specific, like we did with
CAB files

No (as far as I know). This is a bummer. What I did to prevent the control
from being downloaded every time is I built a wrapper control, very small in
size (and very simple in API) that has one property that tells the version
of the assembly to load, this wrapper uses LoadAssembly using this version
information and therefore downloads the assembly only when it is needed.

One important thing I discovered is that for some reason IE takes a LONG
time to load the page the first time explorer hits it if the control is very
"complex" (has a lot of properties and events), this is not noticeable when
working locally but it has a big impact (about 30 secs in my case) when
hitting a page in a remote site, this is why the wrapper control has to be
very "simple".

Since JScript works through Dispatch only, your wrapper object can expose a
property of type Object that returns the original control so that you can
script it.

I hope this helps.

--
Francisco Padron
www.chartfx.com

[Dave McCracken]

Thanks Francisco.
Do you know if there's a way to reference the object's classid or codebase
to a web url, but still have the html page just loaded as a file into IE?
Our testing indicates that the html page needs to be called via http (i.e.
http://localhost/page.html), otherwise the .NET object will not load
properly, even if the component's classid is referenced to a url.

"Francisco Padron" wrote:

The <object> tag's CODEBASE will NOT take a file:// url for security reasons
(so that you can not use already installed ActiveX controls with malicious
purposes). So yes, the page needs to come from a web server.

Is there a way to make the UserControl version-specific, like we did with
CAB files

No (as far as I know). This is a bummer. What I did to prevent the control
from being downloaded every time is I built a wrapper control, very small in
size (and very simple in API) that has one property that tells the version
of the assembly to load, this wrapper uses LoadAssembly using this version
information and therefore downloads the assembly only when it is needed.

One important thing I discovered is that for some reason IE takes a LONG
time to load the page the first time explorer hits it if the control is very
"complex" (has a lot of properties and events), this is not noticeable when
working locally but it has a big impact (about 30 secs in my case) when
hitting a page in a remote site, this is why the wrapper control has to be
very "simple".

Since JScript works through Dispatch only, your wrapper object can expose a
property of type Object that returns the original control so that you can
script it.

I hope this helps.

--
Francisco Padron
www.chartfx.com

[Francisco Padron]

That's because the CODEBASE for the control has to be the SAME as the page,
in other words, if you have a page in:

www.foo.com

Your control can not come from another site, say www.foo2.com, it has to
come from the same. Similarly, if your page is coming from C:\somepath, then
your control can not be downloaded from any site.

I believe this is for security reasons, maybe some MSFT person wants to
comment on this.

--
Francisco Padron
www.chartfx.com