Shel
Thu Aug 14 12:38:15 CDT 2003
You could turn on logging to see what's going on.
http://support.microsoft.com/default.aspx?scid=kb;en-us;313892
Shel
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Luther Miller" <luther.miller@softagondotcom.invalid> wrote in message
news:e$3yHgoYDHA.1580@tk2msftngp13.phx.gbl...
> 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
>
> "Ivan Medvedev [MS]" <ivanmed@online.microsoft.com> wrote in message
> news:%23G2twGoYDHA.2464@TK2MSFTNGP09.phx.gbl...
> > 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.
> >
> > "Luther Miller" <luther.miller@softagondotcom.invalid> wrote in message
> > news:%23SgHw2nYDHA.1680@tk2msftngp13.phx.gbl...
> > > 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
> > >
> > >
> >
> >
>
>