views:

439

answers:

1

I'm using Microsoft Visual C# 2008 Express Edition. (And I apologize - this is more of a MS Vis C# usability question than a strict programming question...)

I wrote a little program. when I run it in MS VC# with the debugger, all is well. When I use the "click Once" to generate something to deploy (I'm using the "from a CD-ROM" option as opposed to "from a website) , and then I install it on my machine (or a different machine) and all is well except a piece of the code doesn't run!

The code that isn't running is the "catch" part of a try/catch loop. I intentionally have a bug I know generates an exception still in the application so I can test this catch. The catch brings up a GUI and asks the user to send data back to me. In the debugger - this works fine. In the standalone, published app, this doesn't work.

any ideas?

I point out that I'm running the "Express edition" because a friend mentioned that I might have a deployment "issue" and it appears that the Express Edition is limited in deployment options and that maybe the Standard edition is what I need... (since I can use Windows Installer instead of the "click once" publish method).

Does any of this make sense?

Appreciate the help!

-Adeena (an old command line unix C++ programmer who's struggling to make sense of this Microsoft "Visual" world)

+2  A: 

Is this code in the constructor/OnLoad of a form, by any chance? There are known differences in this area between with / without debugger. The fix is usually to defer the code until the UI thread is processing events. For example:

    protected override void OnLoad(EventArgs e)
    {
        base.OnLoad(e);
        BeginInvoke((Action)LoadStuff);
    }
    void LoadStuff()
    {
        // todo...
    }
Marc Gravell
The try/catch is around my Application.Run()... see this other post I had the other day: http://stackoverflow.com/questions/366718/what-is-the-best-way-to-collect-crash-data
adeena
Yes, I've seen Application.Run behave oddly if you throw an exception in the form load.
Marc Gravell
ok - maybe having the try/catch there was not such a great idea after all... I'll look at staging it around other key areas/functions throughout the program... thanks!
adeena
better yet - look at Application.ThreadException event
DK