|
Home > Archive > IIS Server > February 2004 > Dot Net Limitations
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Dot Net Limitations
|
|
| Dave Brown 2004-02-11, 12:35 am |
| 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.
| |
| newsgroup user 2004-02-11, 1:36 am |
| hope you do realize that there is a reason why they are called windows form controls, not fancier web form controls. you are doing something that's not *officially* supported by Microsoft. If there's truly no solution, tough luck, it was never meant to
work in the first place.
----- Dave Brown wrote: -----
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.
| |
| Dave Brown 2004-02-11, 1:37 am |
| Hi when I set it to Scripts and Executables, its definately a no-go..
Even when running on port 80, it has to be set to Scripts Only. When
otherwise the control wont show.
"Dave Brown" <dave.AT.dbws.net> wrote in message
news:evc53GK8DHA.2460@TK2MSFTNGP09.phx.gbl...
> 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.
>
>
| |
| Stephen Martin 2004-02-11, 2:36 am |
| Actually, hosting WinForms controls in Internet Explorer is not only
supported but encouraged by Microsoft.
"Daniel Jin" <anonymous@discussions.microsoft.com> wrote in message
news:1349FDC6-F1BD-4FE2-8E70-26F17C37A181@microsoft.com...
> hope you do realize that there is a reason why they are called windows
form controls, not fancier web form controls. you are doing something
that's not *officially* supported by Microsoft. If there's truly no
solution, tough luck, it was never meant to work in the first place.
>
>
> ----- Dave Brown wrote: -----
>
> 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.
>
>
>
| |
|
| I'm not near a webserver at the moment so can't try this out, but it may be
because you are using unsigned controls
and the .net securty is saying hold on a second you don't have rights to run
this from a dodgy port. You could
try making it a signed control and creating a new security group in the .net
frameowrk that allows everything
and see what it does.
Try looking for an article called
DHTML and .NET: Host Secure, Lighweight Client-side controls in internet
explorer
in the msdn. Will give you more details.
As I said not near a web server to be able to try this out at the moment but
hope it helps.
H
"Dave Brown" <dave.AT.dbws.net> wrote in message
news:%231FnS3K8DHA.2644@TK2MSFTNGP11.phx.gbl...
> Hi when I set it to Scripts and Executables, its definately a no-go..
>
> Even when running on port 80, it has to be set to Scripts Only. When
> otherwise the control wont show.
>
>
> "Dave Brown" <dave.AT.dbws.net> wrote in message
> news:evc53GK8DHA.2460@TK2MSFTNGP09.phx.gbl...
> Any
has[color=blue]
on[color=blue]
>
>
| |
| Dave Brown 2004-02-11, 2:36 am |
| I'll give that a go thanks Harry.
"harry" <thedreamer2000@hotmail.com> wrote in message
news:402a4b82_1@nnrp1.news.uk.psi.net...
> I'm not near a webserver at the moment so can't try this out, but it may
be
> because you are using unsigned controls
> and the .net securty is saying hold on a second you don't have rights to
run
> this from a dodgy port. You could
> try making it a signed control and creating a new security group in the
..net
> frameowrk that allows everything
> and see what it does.
>
> Try looking for an article called
>
> DHTML and .NET: Host Secure, Lighweight Client-side controls in internet
> explorer
>
> in the msdn. Will give you more details.
>
> As I said not near a web server to be able to try this out at the moment
but
> hope it helps.
>
> H
>
>
>
> "Dave Brown" <dave.AT.dbws.net> wrote in message
> news:%231FnS3K8DHA.2644@TK2MSFTNGP11.phx.gbl...
80.[color=blue]
have[color=blue]
> has
run[color=blue]
> on
>
>
| |
| Dave Brown 2004-02-11, 2:36 am |
| 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.
>
>
| |
|
| 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/d...Fuslogvwexe.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.
>
>
> Any
has[color=blue]
on[color=blue]
>
>
| |
| Dave Brown 2004-02-11, 3:36 am |
| 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/d...Fuslogvwexe.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...
created[color=blue]
> about
System.Security.CodeAccessSecurityEngine.Check(CodeAccessPermission[color=blue]
stackMark)[color=blue]
>
System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(Met
>
System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessa
> System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage
System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData&[color=blue]
dwFlag,[color=blue]
80.[color=blue]
have[color=blue]
> has
run[color=blue]
> on
>
>
| |
|
| What have you done for Code Access Security (CAS) settings? It seems the
code doesn't have the correct permissions.
"Dave Brown" <dave.AT.dbws.net> wrote in message
news:uYxhq$L8DHA.1804@TK2MSFTNGP12.phx.gbl...
> 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...
> you've
1[color=blue]
> You
assembly[color=blue]
>
http://msdn.microsoft.com/library/d...-us/cptools/htm
l/cpgrfFusionLogViewerFuslogvwexe.asp
> failure
> created
System.Security.CodeAccessSecurityEngine.CheckHelper(PermissionSet[color=blue]
Int32[color=blue]
> System.Security.CodeAccessSecurityEngine.Check(CodeAccessPermission
assemblyRef,[color=blue]
> stackMark)
Evidence[color=blue]
m)[color=blue]
String[color=blue]
String[color=blue]
>
System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(Met
>
System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessa
> System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData&
String[color=blue]
> dwFlag,
to[color=blue]
> 80.
> have
nobody[color=blue]
> run
>
>
|
|
|
|
|