Re: Dot Net Limitations
From: harry (thedreamer2000_at_hotmail.com)
Date: 02/11/04
- Next message: Dave Brown: "Re: Dot Net Limitations"
- Previous message: Dave Brown: "Re: Dot Net Limitations"
- In reply to: Dave Brown: "Re: Dot Net Limitations"
- Next in thread: Dave Brown: "Re: Dot Net Limitations"
- Reply: Dave Brown: "Re: Dot Net Limitations"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 11 Feb 2004 16:26:35 -0000
A useful tool for this is
fuslogvw.exe
if you go to the command prompt(probably the visual studio one unless you've
setup the paths correctly and just type
fuslogvw this will bring up this little app and will allow you see any
errors that occur)
Though it does have a Log failures check box I find you need to set a
registry key to get it to be really useful and
see everything that's going on.
To log all binds in the viewer
a.. Set the HKLM\Software\Microsoft\Fusion\ForceLog registry value to 1
(the value is a DWORD).
By default, Fuslogvw.exe only logs failed attempts to locate assemblies. You
might have a situation where it is useful to view all successful assembly
binds. For example, you might want to verify that an assembly is loading
from your application directory
Check out the article
by the way that log report does look like it's a security permission failure
so signing it may work. Though be prepared to spend
time getting it to work correctly (and getting very frustrated into the
bargain as well)
H
"Dave Brown" <dave.AT.dbws.net> wrote in message
news:uM3VVgL8DHA.2796@TK2MSFTNGP09.phx.gbl...
> Ahhh, I think I might be getting somewhere....
>
> Forget about IIS error logs or the event viewer, Error reports are created
> in the temporary internet files folder containing detailed information
about
> why the .NET files failed to load properly..... It does look like a
> security/permissions problem, so running on a different port gives it
> problems....
> This is the contents of the file...
>
> ***** IEHOST Error Log (Wednesday, 11 February 2004 15:52) *****
>
>
>
> URL: http://www.dbws.net:90/winctrlasppage/SimpleControl.dll
> Zone: 3
> Assembly Name: SimpleControl.dll
> Type Name: Microsoft.Samples.WinForms.Cs.SimpleControl.SimpleControl
>
>
>
> ----- Thrown Exception -----
>
>
> System.Security.SecurityException: Request for the permission of type
> System.Net.WebPermission, System, Version=1.0.5000.0, Culture=neutral,
> PublicKeyToken=b77a5c561934e089 failed.
>
> Server stack trace:
> at System.Security.CodeAccessSecurityEngine.CheckHelper(PermissionSet
> grantedSet, PermissionSet deniedSet, CodeAccessPermission demand,
> PermissionToken permToken)
> at System.Security.CodeAccessSecurityEngine.Check(PermissionToken
> permToken, CodeAccessPermission demand, StackCrawlMark& stackMark, Int32
> checkFrames, Int32 unrestrictedOverride)
> at System.Security.CodeAccessSecurityEngine.Check(CodeAccessPermission
> cap, StackCrawlMark& stackMark)
> at System.Security.CodeAccessPermission.Demand()
> at System.Reflection.Assembly.InternalLoad(AssemblyName assemblyRef,
> Boolean stringized, Evidence assemblySecurity, StackCrawlMark& stackMark)
> at System.Reflection.Assembly.LoadFrom(String assemblyFile, Evidence
> securityEvidence, Byte[] hashValue, AssemblyHashAlgorithm hashAlgorithm)
> at System.Activator.CreateComInstanceFrom(String assemblyName, String
> typeName, Byte[] hashValue, AssemblyHashAlgorithm hashAlgorithm)
> at System.AppDomain.CreateComInstanceFrom(String assemblyFile, String
> typeName, Byte[] hashValue, AssemblyHashAlgorithm hashAlgorithm)
> at
>
System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(Met
> hodBase mb, Object[] args, Object server, Int32 methodPtr, Boolean
> fExecuteInContext, Object[]& outArgs)
> at
>
System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessa
> ge msg, Int32 methodPtr, Boolean fExecuteInContext)
>
> Exception rethrown at [0]:
> at
System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage
> reqMsg, IMessage retMsg)
> at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData&
> msgData, Int32 type)
> at System.AppDomain.CreateComInstanceFrom(String assemblyFile, String
> typeName, Byte[] hashValue, AssemblyHashAlgorithm hashAlgorithm)
> at Microsoft.IE.SecureFactory.CreateInstanceWithSecurity(Int32 dwFlag,
> Int32 dwZone, String pURL, String uniqueIdString, String link, String
> licenses)
>
>
> I will sign the code and see if I still get the same problem...
>
> Rgds,
>
> Dave.
>
>
> > I believe I have found a severe limitation of DotNet, with respect to
> > hosting Windows Form Controls in WebPages.
> > It appears this is only possible when the web is configured on Port 80.
> Any
> > other port and the control will not display.
> > After a couple of days of searching the newsgroups/various forums I have
> > found other postings requesting information on this anomaly yet nobody
has
> > found a solution.
> > What are Microsoft doing with this ? It seems a common situation to run
on
> > alternate ports, being restricted to the default 80 seems ludicrous.
> >
> > Dave.
> >
> >
>
>
- Next message: Dave Brown: "Re: Dot Net Limitations"
- Previous message: Dave Brown: "Re: Dot Net Limitations"
- In reply to: Dave Brown: "Re: Dot Net Limitations"
- Next in thread: Dave Brown: "Re: Dot Net Limitations"
- Reply: Dave Brown: "Re: Dot Net Limitations"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
