Non-visual C# objects on a webpage are not marked as "safe for scr

[lwickland]

Non-visual C# objects on a webpage are not marked as "safe for scripting"

I'm developing .NET components in C# which are used as ActiveX-style
controls on web pages that are displayed inside a custom browser which is
based on the IE web browser control. On 3 of about 100 PCs that the controls
have been tried on, the browser produces the following error message:

An ActiveX control on this page is not safe.
Your current security settings prohibit running unsafe controls on this
page.
As a result, this page may not display as intended.

I believe this is the "not safe for scripting" error. According to what
I've read, we shouldn't be seeing this error because the object tag which
puts the C# control on the page references a URL in the CLASSID attribute;
supposedly this type of reference automatically marks the object as safe for
scripting. However, neither adding a 'mayscript="true"' attribute to the
object tag nor implementing IObjectSafety eliminates the problem.

The problem only plagues non-visual controls, i.e., C# objects which do not
inherit from System.Windows.Forms.Control. The only step required to
alleviate the problem is to inherit from System.Windows.Forms.Control or one
of its derivatives. However, inheriting from System.ComponentModel.Component
does not eliminate the error message.

Is this the expected behavior? Is there another workaround which would
allow me to put non-visual, non-Control-derived C# classes on the web page?

I'm using v1.1 SP1 of the Framework.

 

[Nicholas Paldino [.NET/C# MVP]]

lwickland,

I would try and define the IObjectSafety interface on your objects. You
would have to define it first, but that should be a trivial matter.

Hope this helps.

 

[lwickland]

lwickland,

I would try and define the IObjectSafety interface on your objects. You
would have to define it first, but that should be a trivial matter.

Nicholas,

Thanks for replying.

As I noted in my original post, I have tried implementing IObjectSafety to
no avail.

I stuck MessageBox.Show()s in the methods implementing IObjectSafety to
ensure that I had implemented it correctly. On a PC that didn't display the
"safe for scripting" error, the MessageBox.Show()s were displayed as expected
when the javascript on the web page referenced the C# object. On a PC that
did display the "safe for scripting" error, the MessageBoxes weren't
displayed, indicating to me that the web page wasn't recognizing that the
object implemented IObjectSafety.

Do you have any further suggestions?

We haven't been able to find any pattern to the PCs that the problem has
appeared on; we've seen the issue on both Windows 2000 and Windows XP.

Thanks,

Leif Wickland

 

[lwickland]

Robert,

Thanks for the implementation template for IObjectSafety.

I tried to say in my previous post that I implemented IObjectSafety and that
doing so did not improve the situation. I used an implementation very
similar to the one that you provided. I do believe that my implementation
was correct because my GetInterfaceSafetyOptions() and
SetInterfaceSafetyOptions() methods were being called on a PC that didn't
receive the "not safe for scripting" error, although they were not being
called on a PC that did receive the error.

Please let me know of any other suggestions you may have.

Thanks again,

Leif Wickland

 

[lwickland]

Robert,

Thanks for reply again.

Maybe you didn't registered again the now fixed assembly
on those PCs.

I have not been registering the assembly on either my PC or the PC with the
problem. I have the "Register for COM Interop" option disabled on the
project. My rationale for not registering the assembly was that the code was
not being referenced by GUID and because, to my understanding, registering an
assembly or its types didn't matter in the context of putting a .NET object
on a web page by referencing its URL. All the same I tried what you
suggested below.

You should use fixed Guids, give the assembly a strong name
(sign it) and register it with COM using regasm /codebase.

I followed these steps:
1. Ensured that the class had a [Guid()] attribute.
2. Ensured that the assembly has an [assembly: Guid()] attribute.
3. Build the assembly.
4. Executed "regasm /codebase <asmName.DLL>"
5. Changed my web page to have object tags which looked like "<object
CLASSID='clsid:<classGuid>'>."
6. Hit the page.

It worked great on my PC and on the PC that had previously had problems.

Does anyone have experience using GUID values inside the object tag's
CLASSID attribute in a production environment? I am very nervous about doing
so because we need to be able to run multiple versions of the same product at
once without the various versions of the assemblies stepping on each other's
toes. In order to run different version simultaneously, wouldn't we have to
change the GUID on each class and assembly for each release? We essentially
do a release to QA everyday and QA needs to be able to run multiple days'
builds concurrently on the same PC.

Are there any solutions which don't involve registering the assembly or
hard-coding the GUID in the web page?

Thanks,

Leif Wickland

 

[How to implement IObjectSafety with C#?]

Hi,

Can someone show me how to implement the IObjectSafety (or any other MS
defined) interface using C#? I am new to .NET and apparently I am missing
something. Everything I've tried does not work.

Jeff Finz

lwickland,

I would try and define the IObjectSafety interface on your objects. You
would have to define it first, but that should be a trivial matter.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Non-visual C# objects on a webpage are not marked as "safe for scripting"

I'm developing .NET components in C# which are used as ActiveX-style
controls on web pages that are displayed inside a custom browser which is
based on the IE web browser control. On 3 of about 100 PCs that the
controls
have been tried on, the browser produces the following error message:

An ActiveX control on this page is not safe.
Your current security settings prohibit running unsafe controls on this
page.
As a result, this page may not display as intended.

I believe this is the "not safe for scripting" error. According to what
I've read, we shouldn't be seeing this error because the object tag which
puts the C# control on the page references a URL in the CLASSID attribute;
supposedly this type of reference automatically marks the object as safe
for
scripting. However, neither adding a 'mayscript="true"' attribute to the
object tag nor implementing IObjectSafety eliminates the problem.

The problem only plagues non-visual controls, i.e., C# objects which do
not
inherit from System.Windows.Forms.Control. The only step required to
alleviate the problem is to inherit from System.Windows.Forms.Control or
one
of its derivatives. However, inheriting from
System.ComponentModel.Component
does not eliminate the error message.

Is this the expected behavior? Is there another workaround which would
allow me to put non-visual, non-Control-derived C# classes on the web
page?

I'm using v1.1 SP1 of the Framework.

 

[lwickland]

As I noted in my original post, I have tried implementing

IObjectSafety to

IObjectSafety & friends
...

I tried implementing IObjectSafety as you've listed it here and I saw the
same "not safe for scripting" error. It's worth mentioning that my class
wasn't derived from Control or UserControl as yours was.

Thanks for the suggestion.