Hosting control in IE where control references Wrapper

  • Thread starter Thread starter Daniel vom Saal
  • Start date Start date
D

Daniel vom Saal

I've searched for this but can't find an answer: is it possible to use a
wrapped COM component in a windows.forms class that is then loaded using
ASP.NET?

Specifics: we have a control that we build in VB.NET that uses WIALib. The
reference was created using Visual Studio, so there is a reference to
InteropServices and a new dll created in the bin directory when built.

We copy the dll to the root of an ASP.NET app, then have a page that
references it using <OBJECT>... notation. However, it doesn't appear on the
page. Is this a security issue? How will the app know to get the wrapper
dll?

If there is a good doc on this I'd welcome a pointer; nothing I found
discusses what to do if you are using multiple DLLs as part of the control.

Thanks,

DvS
 
Hi Daniel,

From your description, you've a winform control and want to host it in IE.
Also, the control has referenced a Wrapped COM component. And you found
when run the page , the embeded winform control not work well, yes?

Based on my experience, the problem is likely caused by the COM wrapper dll
rather than security issue. As we know , the IE hosted winform control will
be downloaded to the clientside and run in the client's CLR. However, since
you used a COM wrapper dll and COM component are all registered in the
server's registry which can be accessed on serverside, so the control won't
be able to make the wrapper call remain working at client machine. Do you
think so?

And here are some of my suggestions which can help the IE host control to
call the COM service on the server:
1. Make a .NET Remoting Service component which help to call the wrapper
COM dll. Then you can call the remote service object in your winform
control.

2. Make a webservice to expose all the interfaces of the COM wrapper
component and call the webservice in he IE hosted control. And this means
is widely used in many rich client application.

Hope helps.


Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

Get Preview at ASP.NET whidbey
http://msdn.microsoft.com/asp.net/whidbey/default.aspx
 
Steven,

This is the first reply that I have seen to my question. Where is the other
reply? I do not see it in the newsgroup.

Thank you very much,

DvS
 
Steven,

Just found this post - guess my newsreader hadn't refreshed.

Option 2 won't work, as the process needs to be completely on the client
machine. The component that is being wrapped is WIA - the interface for
scanners, etc. - and therefore is already on the client machine.

Option 1 sounds interesting - how do I do this? Can you point me to an
example? Our code is in VB.NET, and I haven't found a good example to
follow, thought I will keep looking.

Thanks,

DvS
 
Hi Daniel,

Since you mentioned that the option2 won't work, the option1 is also not
suitable I'm afraid. Because the .net remoting service also need a remoting
server and all the client call the service from the server.
In addtion, as you said that all the client will also have the WIA
component installed(are you sure all the machine's WIAlib's version are the
same with the machine where you generate the wrapper class?), I think its
ok to let the assembly be downloaded to client and call the WIA component
on the clientside machine. In other word, what you need to do is just
generate the wrapper classes and make sure that it is in the correct path
and can be downloaded to the clientside. As for the problem that it not
work, I think it may be caused by some security issue. You need to
configure the .net code access setting on the clientmachine. Use the .net
configuration tool (in the control panel/administrator tools/.net
configuration tool).
#Configuring Security Policy Using the .NET Framework Configuration Tool
(Mscorcfg.msc)
http://msdn.microsoft.com/library/en-us/cpguide/html/cpconusingnetframeworkc
onfigurationtooltoconfiguresecuritypolicy.asp?frame=true

You can create a new code group for the IE host control's assembly or for
the certain url Or directly choose the intranet code zone and grant the
Unmanaged Code permission to it. After that, retest to see whether the
COM's wrapper class can work.

Further more, if the problem still remains, I suggest that you create a
simple assembly (to host in the IE) to repro it so that we can test it on
our side and do some further research on it. Thanks.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

Get Preview at ASP.NET whidbey
http://msdn.microsoft.com/asp.net/whidbey/default.aspx
 
Hi Daniel,

Have you got any further ideas on this issue? I've a good news on this
since I've made a general test on my side. I created a simple winform
control which use the wrapper class of the WIALIB. And then, I try visit
the page from some different client machine which also has the same WIALIB
COM (must have the same CLSID which can be found on that machine). That the
IE hosted control worked well. So I think you can apply your original
solution without problem as long as you can confirm that the client machine
have also installed the same version of the COM component. Please have a
try to confirm whether this also works on you side. If you have anything
else wondering, please feel free to post here. Thanks.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

Get Preview at ASP.NET whidbey
http://msdn.microsoft.com/asp.net/whidbey/default.aspx
 
Back
Top