By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,424 Members | 1,402 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,424 IT Pros & Developers. It's quick & easy.

Dot Net Limitations

P: n/a
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.
Nov 15 '05 #1
Share this Question
Share on Google+
11 Replies


P: n/a
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.

Nov 15 '05 #2

P: n/a
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:ev**************@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.

Nov 15 '05 #3

P: n/a
Actually, hosting WinForms controls in Internet Explorer is not only
supported but encouraged by Microsoft.
"Daniel Jin" <an*******@discussions.microsoft.com> wrote in message
news:13**********************************@microsof t.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.

Nov 15 '05 #4

P: n/a
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:%2****************@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:ev**************@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.


Nov 15 '05 #5

P: n/a
I'll give that a go thanks Harry.

"harry" <th************@hotmail.com> wrote in message
news:40********@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:%2****************@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:ev**************@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.



Nov 15 '05 #6

P: n/a
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.Simple Control

----- 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.CheckHelp er(PermissionSet
grantedSet, PermissionSet deniedSet, CodeAccessPermission demand,
PermissionToken permToken)
at System.Security.CodeAccessSecurityEngine.Check(Per missionToken
permToken, CodeAccessPermission demand, StackCrawlMark& stackMark, Int32
checkFrames, Int32 unrestrictedOverride)
at System.Security.CodeAccessSecurityEngine.Check(Cod eAccessPermission
cap, StackCrawlMark& stackMark)
at System.Security.CodeAccessPermission.Demand()
at System.Reflection.Assembly.InternalLoad(AssemblyNa me 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.HandleRe turnMessage(IMessage
reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateI nvoke(MessageData&
msgData, Int32 type)
at System.AppDomain.CreateComInstanceFrom(String assemblyFile, String
typeName, Byte[] hashValue, AssemblyHashAlgorithm hashAlgorithm)
at Microsoft.IE.SecureFactory.CreateInstanceWithSecur ity(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.

Nov 15 '05 #7

P: n/a
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/de...uslogvwexe.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:uM**************@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.Simple Control

----- 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.CheckHelp er(PermissionSet
grantedSet, PermissionSet deniedSet, CodeAccessPermission demand,
PermissionToken permToken)
at System.Security.CodeAccessSecurityEngine.Check(Per missionToken
permToken, CodeAccessPermission demand, StackCrawlMark& stackMark, Int32
checkFrames, Int32 unrestrictedOverride)
at System.Security.CodeAccessSecurityEngine.Check(Cod eAccessPermission
cap, StackCrawlMark& stackMark)
at System.Security.CodeAccessPermission.Demand()
at System.Reflection.Assembly.InternalLoad(AssemblyNa me 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.HandleRe turnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateI nvoke(MessageData&
msgData, Int32 type)
at System.AppDomain.CreateComInstanceFrom(String assemblyFile, String
typeName, Byte[] hashValue, AssemblyHashAlgorithm hashAlgorithm)
at Microsoft.IE.SecureFactory.CreateInstanceWithSecur ity(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.


Nov 15 '05 #8

P: n/a
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" <th************@hotmail.com> wrote in message
news:40**********@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/de...uslogvwexe.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:uM**************@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.Simple Control

----- 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.CheckHelp er(PermissionSet
grantedSet, PermissionSet deniedSet, CodeAccessPermission demand,
PermissionToken permToken)
at System.Security.CodeAccessSecurityEngine.Check(Per missionToken
permToken, CodeAccessPermission demand, StackCrawlMark& stackMark, Int32
checkFrames, Int32 unrestrictedOverride)
at System.Security.CodeAccessSecurityEngine.Check(Cod eAccessPermission cap, StackCrawlMark& stackMark)
at System.Security.CodeAccessPermission.Demand()
at System.Reflection.Assembly.InternalLoad(AssemblyNa me 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.HandleRe turnMessage(IMessage
reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateI nvoke(MessageData& msgData, Int32 type)
at System.AppDomain.CreateComInstanceFrom(String assemblyFile, String
typeName, Byte[] hashValue, AssemblyHashAlgorithm hashAlgorithm)
at Microsoft.IE.SecureFactory.CreateInstanceWithSecur ity(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.



Nov 15 '05 #9

P: n/a
"Dave Brown" <dave.AT.dbws.net> 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.


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...b;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...b;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...b;en-us;313892
Nov 15 '05 #10

P: n/a
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
"Daniel Jin" <an*******@discussions.microsoft.com> wrote in messag
news:13**********************************@microsof t.com..
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
----- Dave Brown wrote: ----

I believe I have found a severe limitation of DotNet, with respect t

hosting Windows Form Controls in WebPages
It appears this is only possible when the web is configured on Por

80. An other port and the control will not display
After a couple of days of searching the newsgroups/various forums hav found other postings requesting information on this anomaly ye nobody ha found a solution
What are Microsoft doing with this ? It seems a common situation t run o alternate ports, being restricted to the default 80 seems ludicrous
Dave

Nov 15 '05 #11

P: n/a
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:uY**************@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" <th************@hotmail.com> wrote in message
news:40**********@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/de...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

"Dave Brown" <dave.AT.dbws.net> wrote in message
news:uM**************@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.Simple Control

----- 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.CheckHelp er(PermissionSet grantedSet, PermissionSet deniedSet, CodeAccessPermission demand,
PermissionToken permToken)
at System.Security.CodeAccessSecurityEngine.Check(Per missionToken
permToken, CodeAccessPermission demand, StackCrawlMark& stackMark, Int32 checkFrames, Int32 unrestrictedOverride)
at System.Security.CodeAccessSecurityEngine.Check(Cod eAccessPermission cap, StackCrawlMark& stackMark)
at System.Security.CodeAccessPermission.Demand()
at System.Reflection.Assembly.InternalLoad(AssemblyNa me 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.HandleRe turnMessage(IMessage
reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateI nvoke(MessageData& msgData, Int32 type)
at System.AppDomain.CreateComInstanceFrom(String assemblyFile, String typeName, Byte[] hashValue, AssemblyHashAlgorithm hashAlgorithm)
at Microsoft.IE.SecureFactory.CreateInstanceWithSecur ity(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.
>
>



Nov 15 '05 #12

This discussion thread is closed

Replies have been disabled for this discussion.