Dot Net Limitations

[Dave Brown]

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.

 

[Guest]

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]

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.

 

[harry]

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

 

[Stephen Martin]

Actually, hosting WinForms controls in Internet Explorer is not only
supported but encouraged by Microsoft.

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]

I'll give that a go thanks Harry.

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



run

 

[Dave Brown]

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.

 

[harry]

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...ools/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

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.

 

[Dave Brown]

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....

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...ools/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

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

 

[UAError]

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.

Your problem may well be related to this:

Microsoft Knowledge Base Article - 827558
FIX: IEHost Makes Calls Back to Port 80 When Internet Explorer Is Bound to a Port Other Than Port 80
http://support.microsoft.com/default.aspx?scid=kb;en-us;827558

Microsoft Knowledge Base Article - 821991
FIX: IEHost Causes Additional Traffic on Port 80 for Sites That Are Hosted on Other Ports
http://support.microsoft.com/default.aspx?scid=kb;en-us;821991


When hosting windows controls inside of IE this could be useful

Microsoft Knowledge Base Article - 313892
HOW TO: Use the IEHost Log to Debug .NET Object Hosting in Internet Explorer
http://support.microsoft.com/default.aspx?scid=kb;en-us;313892

 

[Guest]

well, sorry then. I must have missed all the fanfare

----- Stephen Martin wrote: ----

Actually, hosting WinForms controls in Internet Explorer is not onl
supported but encouraged by Microsoft

hope you do realize that there is a reason why they are called window

form controls, not fancier web form controls. you are doing somethin
that's not *officially* supported by Microsoft. If there's truly n
solution, tough luck, it was never meant to work in the first place

 

[Anon]

What have you done for Code Access Security (CAS) settings? It seems the
code doesn't have the correct permissions.

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....

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/htm
l/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

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 hashAlgorith m)
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.