ActiveX control on a web page, Simulate Internet Security Zone?

  • Thread starter Thread starter Neo
  • Start date Start date
N

Neo

I have a usercontrol that I am trying to use as an ActiveX Control on a
WebPage, however it refereneces an Assembly that whenever the first
call is made to anything in the Assembly a Security Exception is throw.
I am having a lot of trouble debugging this, because I cannot catch the
exception in my code.

However if I could run the control under the Internet Zone Security
settings I could probably find this easily. Does anyone know how to do
this? (The control runs fine in the ActiveX container)

Maybe I am not appoaching this the right way. What is the "right" way
to debug a .NET ActiveX control on a webpage?

Thanks in advance
 
I have a usercontrol that I am trying to use as an ActiveX Control on a
WebPage, however it refereneces an Assembly that whenever the first
call is made to anything in the Assembly a Security Exception is throw.
I am having a lot of trouble debugging this, because I cannot catch the
exception in my code.

Make sure the assembly has the following attribute:

[assembly: AllowPartiallyTrustedCallers()]

Maybe I am not appoaching this the right way. What is the "right" way
to debug a .NET ActiveX control on a webpage?

If you mean a Windows Form control hosted inside IE, what you need to do is
run IE, then run VS and Debug-Attach to Iexplorer.exe.

Prior to running IE you may want to clear your downloaded Cache to make sure
you are debugging the same version that is running, to do this do:

gacutil /cdl

Other than this, you just have to make sure you don't make calls to any API
that requires a special permission not available in the Internet Zone, what
I do a lot is I change my settings to allow Full-Trust in my Local Intranet,
then once I have it working, I lower the permissions, this way I can test
locally.
 
Yep that fixed it right up thanks. Do you what the securty implications
of having this on all my Assemblies is?
 
This is what MSDN says:

Libraries that are private to a specific application do not require a strong
name or the AllowPartiallyTrustedCallersAttribute and cannot be referenced
by potentially malicious code outside the application. Such code is
protected against intentional or unintentional misuse by partially trusted
mobile code without the developer or administrator having to do anything
extra.

You should consider explicitly enabling use by partially trusted code for
the following types of code:

a.. Code that has been diligently tested for security vulnerabilities and
is in compliance with the guidelines described in Secure Coding Guidelines.
b.. Strong-named code libraries that are specifically written for
partially trusted scenarios.
c.. Any components (whether partially or fully trusted) signed with a
strong name that will be called by mobile code downloaded from the Internet
or the local intranet. These components are affected because under default
security policy mobile code receives partial trust.
d.. If default policy is modified, any code that security policy grants
less than full trust.
Note Some classes shipped in the .NET Framework class library do not
have the AllowPartiallyTrustedCallersAttribute and can't be called by
partially trusted code. See .NET Framework Assemblies Marked with
AllowPartiallyTrustedCallersAttribute for a list of classes that are
callable by partially trusted code.
The first point is key.
 
Back
Top