Any recent changes in IE Security w/ .NET components? e.g. IEExec?

  • Thread starter Thread starter Luther Miller
  • Start date Start date
L

Luther Miller

Does anyone know of any recent changes/patches/updates affecting how
Internet Explorer handles embedded and "no touch deployment" Windows Forms
..NET Controls?

I was working on a hosted .NET control a while back (not an ASP.NET control,
but a Windows Forms .NET control that is embedded with the <object> tag. It
was working very well then. I shelved it and recently came back to it and
now ti doesn't show in the page. I also created a container EXE that can run
from the same web site that was also working just fine, and now it throws a
Security exception, with no useful information as to why. The control and
the exe do nothing that required any additional permissions - no file
access, etc.

Im trying to figure what has changed - could it be that IEExec has been
updated to be more "secure"? (in other words, cripple .NET in the browser so
it takes the same downward spiral as java applets). It could also be that
something was added to the code, but I just tried a new sample with a
control containing only a label and no other code, and that failed to.

If something has indeed changed, which it appears it has, where can I find
more information on it? This needs to be deployed soon as part of an
Intranet application, and additional client install needs to be avoided.

Sorry for the wide cross-post, but this topic really does cross over several
newsgroup boundaries.
________________________________________________________
Luther Miller . MCSD (.NET), Sr Software Architect / Engineer
Softagon Corporation . www.softagon.com . San Francisco
 
Luther -
perhaps the security policy on your machine is not in the default state. You
can try and reset it with .NET Framework Configuration UI (found in the
control panel) or by running "caspol -all -reset". There were no changes in
IEexec or IE hosting mechanisms that would prevent simple winforms controls
from running. Another possible reason why your control may not work is that
you reference assemblies that do not have
AllowPartiallyTrustedCallersAttribute on them (for example,
System.Security.dll). To see what assemblies you are referencing you can use
ILDASM.exe (from SDK) or ADepents.exe (from SDK Samples). You can see the
assembly attributes with ILDASM (in the manifest section).
--Ivan
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Thanks, Ivan - I'll check all of these.

Ivan Medvedev said:
Luther -
perhaps the security policy on your machine is not in the default state. You
can try and reset it with .NET Framework Configuration UI (found in the
control panel) or by running "caspol -all -reset". There were no changes in
IEexec or IE hosting mechanisms that would prevent simple winforms controls
from running. Another possible reason why your control may not work is that
you reference assemblies that do not have
AllowPartiallyTrustedCallersAttribute on them (for example,
System.Security.dll). To see what assemblies you are referencing you can use
ILDASM.exe (from SDK) or ADepents.exe (from SDK Samples). You can see the
assembly attributes with ILDASM (in the manifest section).
--Ivan
This posting is provided "AS IS" with no warranties, and confers no
Click to expand...
rights.
 
We are doing a bare bones example now with a control and a label and the
problem continues.
The only external references (according to ILDASM) are:

System.Windows.Forms
System
mscorlib
System.Drawing

Also, we even added AllowPartiallyTrustedCallerAttribute to the sample, and
then stroing-named it and gave it a key, and that did not help either. We
also tried running "caspol -all -reset" on two XP test machines, and it had
no effect. (Note that we hadn't made any changes since it most recently
worked anyhow).

Any ideas on how to find out what is going on?
Thanks
 
Back
Top