Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / .NET Framework / Interop / March 2006

Tip: Looking for answers? Try searching our database.

How to define a .NET 2.0 UserControl to be hosted in IE?

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Gary F. - 29 Mar 2006 20:44 GMT
Ok, I know this is an old topic, but for me it's new. And with all
that's been written, I still have outstanding issues. I've been able to
get .NET controls to be hosted in IE and able to deal with the
dependent assembly and strong name issues. But I've not been able to
get Javascript to communicate with the control.

In this blog post
(http://blogs.msdn.com/andrewdownum/archive/2006/01/25/ControlInBrowserProperties
AndMethods.aspx
),
this person claims to very simply get javascript to call a method and
property on a .NET control hosted in IE. Using the code as shown, I
cannot get this to work. Here's another article with a simple example
that I cannot get to work
(http://windowsforms.net/articles/iesourcing.aspx).

1) Is it even possible using such simplistic code? There are no
attributes shown. There is no mention of making it COM interoperable.
It makes sense to me. IE has special behavior to load up a .NET
control. Any access to it via Javascript or whatever script, you would
think, had .NET adapters so that nothing special had to be done on the
control side.

2) If it isn't as simple as shown, then how do I get Javascript to
communicate to the .NET control?

Do I *have* to expose a COM interface and register for COM interop?
Do I *have* to implement IObjectSafety?
Do I *have* to ....?

3) Lastly, if I have to expose a COM interface from my .NET control, do
I also *have* to register it (using regasm or whatever) BEFORE it is
usable in IE? Or, can it self register upon its first initialization?
If the former is the case, this is a bit counterintuitive since one of
the reasons to host a .NET control is to deploy it on demand without
any administrative activies upfront.

All help is appreciated.

Thanks

Gary F.
Gary F. - 29 Mar 2006 22:05 GMT
I don't believe this. Less than 1 hour after I posted this message, I
found some answers. Isn't it always the case.

Ok, so here's what I found (recorded here for posterity).

To answer my Question 1, yes and no. Yes, this very simplistic class
can be scripted against. No, not all info was in the author's article.
I enabled "Register for COM interop" in the build settings and turned
on COM visbility - [assembly: ComVisible(true)] - in AssemblyInfo.cs.
Yeah, I understand that turns it on for all classes but for now I just
want to get something working. I'll whittle down visibility later.

Re: Question 2, I'm exposing a COM interface by virtue of setting
ComVisible to true. I'm not doing anything special for IObjectSafety.
I've come across posting saying that a .NET control already implements
IObjectSafety. I've tried increasing some IE ActiveX settings and I
haven't run into anything yet, though I'm only running this as
localhost.

Re: Question 3. I love this one. It appears that the COM interface of
my .NET control is registered with the Windows registry after the .NET
control has been downloaded. I'm assuming IEHost or IEExec or something
is doing that on my behalf. That's perfect.

Just 1 glitch - the control still stays registered in the Windows
registry after it has been deleted from the download area of the GAC.
It doesn't make sense to me to still have it in the Windows registry if
all access to it from the desktop has been removed, or am I missing
something? Anyone know how to fix this?

On to the next hurdle.

Gary F.
Gary F. - 30 Mar 2006 04:20 GMT
I will now explain my next hurdle and how it was overcome.

So the hurdle (or hurdles) were to add an IObjectSafety implementation,
event source functionality, and a limited, cleaner exposed COM
interface. I did this all in this order.

IObjectSafety was easy mainly because of a well-written blog article
http://blogs.msdn.com/infopath/archive/2005/04/15/408728.aspx

The event source functionality was easy as well because of the said
blog article.

Lastly, the exposed COM interface was NOT easy. This was the last task.
So naturally, I just added an IUserControl1 interface to the end of my
class declaration. It looked like this:

  public class UserControl1 : UserControl, IObjectSafety,
IUserControl1 {;}

I could NOT get javascript to call any methods or props on
UserControl1. It was maddening especially having done it without
splitting the interface.

It turns out, after pouring over the ComXXXAttribute attributes,
there's one called ComDefaultInterfaceAttribute. That one specifies the
default interface for the class. I'm assuming that the late binding IE
has to use the default interface. Makes sense. Anyhow, it turns out
that I can use ComDefaultInterface or I can just rearrange my
interfaces in the class declaration.

Gary F.

Rate this thread:







Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.