Debugging Windows forms applications hosted in IE
I'm very confused about how to debug Windows Forms applications hosted in IE.
I've adapted the Microsoft Sample SimpleControl as a test bed. I'm trying to understand how to debug and avoid security exceptions. I launch my application from IE using the link
<A href="simplehost.exe?arguement">link to program </A> and attach the debugger via the Processes dialog.
If my code looks like this:
public static void Main(string[] args)
{
Application.Run(new HostApp());
try
{
Environment.GetCommandLineArgs();
}
catch (SecurityException se)
{
System.Console.WriteLine(se.Message + se.PermissionType);
}
}
I'm able to set a breakpoint at Environment.GetCommandLineArgs(), its hit, I get the security exception. So far so good.
But if I expand my code to:
try
{
System.Collections.ArrayList argList = new System.Collections.ArrayList();
string[] cl = null;
cl = Environment.GetCommandLineArgs();
if( cl.Length > 1 )
{
string url = cl[1];
int delimiter = url.IndexOf('?');
if( delimiter >= 0 )
{
string qs = url.Substring(delimiter + 1);
HttpRequest request = new HttpRequest("", url, qs);
foreach( string key in request.QueryString.Keys )
{
foreach( string value in request.QueryString.GetValues(key) )
{
if( (key != null) && (key.Length > 0) )
{
argList.Add(key + "=" + value);
}
else
{
argList.Add(value);
}
}
}
}
}
}
catch (SecurityException se)
{
System.Console.WriteLine(se.Message + se.PermissionType);
}
I never get to the breakpoint, I just get a SecurityException.
What happened? Why does my breakpoint seem to get lost.
I'm getting very frustrated.
Frustrated in .NET deployment land
Mark Levison
Hi Mark...
The .NET debugger when attached to IE hosting winform controls does behave a little flakey at times, especially when exceptions are being thrown. I have a very large application that I'm hoping I'll be able to deploy as a control within IE and often run into these sorts of issues.
I recommend you look at security attributes and avoid using anything that requires security priveledges if at all possible.
I have to say I'm more than a little confused by your code... why are you trying to process commandline arguments ? This is a control embedded in a web page using the <OBJECT> tag right ?
If so what are you trying to achieve here ? I wouldn't have thought it possible to get "command line arguments".....
Michael
It's been my experience that the VS .NET debugger is much better at launching an application than attaching to it. I would configure the VS.NET debugger to launch iexplore.exe with the URL as an argument, and I would also configure the debugger to*space
space*on all exceptions.
This is especially true if you are trying to debug a retail file. Retail files in managed code are hard to debug and are often incorrect due to optimziations, just like with native code. But, managed code has a big advantage over native here: if the debugger is present at JIT time, the CLR will automatically JIT with full debug information. The result is that even a retail file can be successfully debugged, provided that you have the PDB. But, this also means that debugging is generally more reliable when you launch from the debugger rather than attach.
Thanks for the reply. After some more work, I discovered that the class HttpRequest lives in the System.Web.dll. This library requests minimum permissions that are not available to apps launched over the local intranet (let alone internet). The exception is thrown as soon as the library is loaded and it is loaded as soon as you enter a routine that uses the method.
> I have to say I'm more than a little confused by your code... why are you trying to process
> commandline arguments ? This is a control embedded in a web page using the <OBJECT> tag
> right ?
Half right - I'm trying to launch a no touch smart-client. It is launched using the tag:
<A href="simplehost.exe?a=arguement">link to program </A>
I need the command line arguments to get information that from web page to the full blown app.
Mark
> It's been my experience that the VS .NET debugger is much better at launching an application
> than attaching to it. I would configure the VS.NET debugger to launch iexplore.exe with the URL
> as an argument, and I would also configure the debugger to*space
space*on all exceptions.
I saw the launching trick suggested in a Chris Sells article, I've not suceeded in getting to generate the same security exceptions that I get under IE. The best trick, I've found to date is inserting :
'System.Diagnostics.Debugger.Break(); in the code.
As for breaking on the SecurityExceptions, that helped a bit, but you still don't get a good way of telling what caused the exception. I'm hoping my 1.1 upgrade will help there.
Mark Levison