Re: Dot Net Limitations
From: Dave Brown (dave.AT.dbws.net)
Date: 02/11/04
- Next message: Michael Kennedy [UB]: "Re: COM, Unmanaged/Managed C++, and CoInitialize()"
- Previous message: pmurphy_at_nospam.servicentral.net.nospam: "RE: Scheduled tasks"
- In reply to: harry: "Re: Dot Net Limitations"
- Next in thread: Anon: "Re: Dot Net Limitations"
- Reply: Anon: "Re: Dot Net Limitations"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 11 Feb 2004 16:55:33 -0000
Well I was getting excited then, thought I was onto something, but after
signing the code and it has a strongname I still get the same ol problem...
I'm quite confident the signings ok, I have a set of steps I go through as I
made a fair few activeX controls in the past and had to sign them and the
cabs.
In this case I just signed the dll....
"harry" <thedreamer2000@hotmail.com> wrote in message
news:402a57bf$1_2@nnrp1.news.uk.psi.net...
> 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
>
>
>
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cptools/html/cpgrfFusionLogViewerFuslogvwexe.asp
>
>
> 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: Michael Kennedy [UB]: "Re: COM, Unmanaged/Managed C++, and CoInitialize()"
- Previous message: pmurphy_at_nospam.servicentral.net.nospam: "RE: Scheduled tasks"
- In reply to: harry: "Re: Dot Net Limitations"
- Next in thread: Anon: "Re: Dot Net Limitations"
- Reply: Anon: "Re: Dot Net Limitations"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|