|
Well, I can now run it from the \Debug folder without running it in the debugger. However, I still can't "Start Without Debugging" in VS. I haven't changed project settings. But which one(s) could cause this?
|
|
|
|
|
I would suggest you now try a release build, and run that in the debugger, as well as by double-clicking the bin\Release\xxx.exe
If that works well, it increases the trust in the code; there are a lot of things one can do wrong, here are two relevant links:
Surviving the Release Version
http://www.codeproject.com/KB/debug/survivereleasever.aspx
Debugging Release Mode Problems
http://www.codeproject.com/KB/debug/releasemode.aspx
I have little experience with "start without debugging"; most if not all project settings seem to be common between with and without debugging. What may be quite different is the exception handling; there is an "Exceptions..." menu item under the Debug menu. Not sure what advice to give you, except what I do: always code defensively, make sure you try and catch everything that might go wrong, at some level (e.g. I always have a big try-catch in the static main that launches all), and ALWAYS do something with the exception you catch, never just swallow it.
I'm afraid I'll need some symptoms in order to be able and help you any further.
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
|
|
|
|
|
Alright, thanks much. I'll give that a try and post back with the results. I did read somewhere to set the "Exceptions..." dialog to catch all exceptions that are thrown instead of set to "User-Unhandled". I tried that but to no avail.
Also, I tried putting a simple "MessageBox.Show("Test");" before "InitializeComponent();" in the form's constructor, MainForm.cs: MainForm(). It never even displays the MessageBox when I encounter the issue where it won't run at all.
|
|
|
|
|
Matt U. wrote: It never even displays the MessageBox
OK, that is a clear symptom of something.
If that was your main form's constructor, what is there before it, i.e. what is in your static main() method, probably inside file Program.cs? Are you doing anything special there? Loading some assemblies explicitly? running a license scheme? showing a splash screen?
Matt U. wrote: "Exceptions..." dialog to catch all exceptions
I'm always inclined to have my app catch things, that way I'm in charge, without having to worry about potential quirks in Visual Studio.
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
|
|
|
|
|
There is nothing going on in my Program.cs aside from the default generated code.
|
|
|
|
|
Okay. Something else that may help more. When I run the application without debugging from within VS it doesn't even seem to make it into the "Main". I placed a MessageBox as the very first statement inside "static void Main()" and I never see that message. I have checked the project settings and "LME_Program" is set as the startup object for the project.
|
|
|
|
|
OK, nice. The startup object, when set, determines which class holds the static main() that should be executed when the app gets launched (both with and without debugging, as well as outside Visual).
So your startup code probably is in another file, and if it got moved on purpose, that purpose can only mean there is some special code in that static main(). You're zooming in!
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
|
|
|
|
|
What I don't understand is the fact that I can run the application from both Debug and Release from outside of VS. I said it wasn't working before because I was simply using the "Open File" dialog in VS and right-clicking then "Open"ing the application's .exe file. If I open a Windows Explorer instance and run it from there it works just fine.
If I place the MessageBox in Program.cs and run it either in the debugger or outside of VS (where it actually runs) I see the MB no problem. For some reason "Start Without Debugging" in VS is the only problem. Do you think that for some reason the entry point is being screwed with when I run it within VS without debugging? Because that seems pretty likely, though I'm no expert.
|
|
|
|
|
well, I can't answer that unless I get some strong facts.
One would be seeing the code in the actual static main(). So locate class LME_Program and look for its main().
Another strong piece of information would be getting a better symptom than "it does not work".
My best wild guess right now is your static main is containing some special code, let's say getting some settings, or checking a license. It needs to access a file, the access is based on the "current directory" (a bad idea), and for some reason this CD is a bit volatile. I know, that is a lot of assumptions, and actually just an example.
BTW: your open dialog thingy is new to me; I never tried opening an exe using VS; and when I do, it does not launch my exe, it opens an object browser window. Anyway, don't do it. Outside VS really means double-clicking the exe in Windows Explorer.
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
|
|
|
|
|
Yeah, I know what you mean about opening the .exe outside of VS via Explorer. That's what I was saying. I had made the mistake of opening it through the VS Open File dialog. And what I mean is that I was right-clicking the .exe in the Open File box and selecting "Open", not double-clicking to open it with VS.
Here's the code for "Program.cs" (which is set as the Startup Object in the project properties):
using System;
using System.Collections.Generic;
using System.Windows.Forms;
namespace LME
{
static class Program
{
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new MainForm());
}
}
}
That code has been the same since the day I first created this project.
|
|
|
|
|
OK.
FYI: you replied to one of your own messages, so I didn't get an e-mail notification this time.
Things don't add up yet. So I now have several questions I would like you to answer:
1.
you mentioned startup object was set to "LME_Program", I think that is incorrect, you probably meant "LME.Program"; please confirm.
2.
I trust your MainForm class is in some other file, however also in the LME namespace?
3.
Does your program still build (and run in one mode or other) when you temporarily choose "(not set)" as the startup object?
4.
Are both classes "Program" and "MainForm" in the EXE itself, or is MainForm in a DLL (i.e. in a separate project, probably inside the same solution; and being referenced by the project that builds the EXE and gets executed)?
5.
Have you ever been putting parts of your app into the "GAC"?
6.
Is everything on (one and the same) local disk? or are network disks involved?
7.
Is there anything odd you might want to tell about, but didn't so far, as it seemed unrelated?
That's it for now.
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
|
|
|
|
|
1.
Yes, I did mean "LME.Program" instead of "LME_Program". Sorry.
2.
Yes, it is in MainForm.cs and is also in the LME namespace.
3.
Yes, the application still runs when I choose "(Not set)" as the Startup Object.
4.
"Program" and "MainForm" are both in the same EXE.
5.
No.
6.
Yes, everything is on one (external) local disk. It's a Seagate USB drive which I've never had problems with (and don't have problems with any other projects on that drive or internal drives).
7.
There does not seem to be anything else wrong.
|
|
|
|
|
So let me summarize what we have here.
A WinForms app, in C#, has a static Main() with nothing special inside, calling a MainForm instance from within the same EXE (residing on a local disk, no DLL involved, no GAC involved), in the same namespace; the MainForm constructor starts with a MessageBox.Show() and under some circumstances this succeeds, while failing under others. The difference being only how the app is run (under Studio with debug, under Studio without debug, and straight from Explorer); removing bin and obj folders, and rebuilding, does not cure. Rebooting PC does not cure.
IMO, if all the above is accurate, the only possible conclusion is: something is ill outside your app; either your PC has problems, or your Visual Studio installation does.
[MODIFIED]
You may want to try:
- building and running your project on the same PC, but with another instance of VS (assuming you have an older or more recent one installed as well);
- building and running your project on another PC.
- building and running a very simple different project on the same PC with the same Visual.
Depending on the outcome, then maybe remove and reinstall Visual.
[/MODIFIED]
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
|
|
|
|
|
Maybe I will attempt to re-create the project and simply copy/paste code/files. I have other projects on the same drive and they all work with no problem. One thing I did do was create backup copies of this particular project. If you recall, I had posted a while back about "List" items being deleted for some strange reason. You provided me with a list of things to do in order to improve my coding, including using "Dictionary<key,value>" objects instead of a "List".
What I did was copy the entire directory and place it in a "Backup" folder in case I needed the old code, or simply needed to go back to the old project altogether. I attempted to build/run the old copy (with the original code) and it behaves just the same. I will create an all new project tomorrow and copy/paste code/files and I will let you know what happens.
|
|
|
|
|
OK. If it is only one project out of many that misbehaves, you could start over and import the source files (but not the solution or project files). If there are multiple problematic projects, something bigger is going on. You'll figure it out.
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
modified on Thursday, May 20, 2010 11:25 PM
|
|
|
|
|
Well, I appreciate you taking all this time to help me. I did just what you said and created a new project, in a whole new parent folder (J:\TempProject\). I then imported .cs files after copying/pasting them to the new temp folder. I built the solution and pressed Ctrl+F5. And I waited ... and waited. Still nothing. It would make sense to me that it's somewhere in the code. On the other hand, it never even reaches the application's entry point so it isn't even executing any code in MainForm is it?
BTW, I created a couple of test projects, gave them each a 'mock' GUI that performed simple tasks, then I built them. They run fine in every method of execution. I just wanted to make sure (again) that it wasn't more than this one project causing problems.
|
|
|
|
|
So the mystery continues.
You now have two projects that act strangely, both based on the same set of source files, but created separately, so their .sln and .csproj files aren't copies? and everything else works fine?
If you have no startup object set, your app can have only one class holding a static Main() and that, as far as your code is concerned, is where your app begins.
If you have a startup object set, it defines the class whose static Main() will be the entry point.
AFAICT you have two choices now:
- slim down your app until the problem disappears, so you might discover where it really matters; most likely that ends up in a bug report, not a solution;
- or reinstall Visual.
Some more questions to better understand your set-up:
Which VS are you running?
which .NET version are you targeting?
Which Windows version are you using?
Is UAC on (I'm not suggesting you turn it off!)
Did you do special things to run from say a networked disk?
are you using anything special in the manifest file?
Here is a short experiment for you: try again on a non-removable, local disk (maybe the system disk).
You might also try on the same machine with another VS (if only one VS is installed, you could easily add another one, say an Express version that is 2 years younger/older). The only side-effect that has it the one you install last will hijack your file associations.
And you could carry the entire project to another PC and see what gives there.
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
|
|
|
|
|
To answer your questions:
I am using Visual Studio 2008 Professional.
I am targeting the .NET Framework v2.0. I have tried v3.0 and v3.5 as well.
I am running Windows Vista Home Premium Service Pack 2.
I turned UAC off a while back.
No, I did nothing to run from a networked disk. (I have no networked disks to begin with .)
I have never touched the manifest file.
I placed the project on the local system disk (C:\ drive) with the exact same results.
I believe the only option at the moment would be slimming down the code until I find the trouble portion. But why will it ONLY not work in "Start Without Debugging" when I run it from VS via F5? That's what really puzzles me with this one. I've never once experienced this before. And it runs just fine when I execute it outside of VS or in the VS debugger. :-P
|
|
|
|
|
Thanks for the info. It tells me your system and mine are very similar; I'm running Vista too, and using VS2008 most of the time. The major difference is, I'm running with UAC.
Here is a new idea: maybe the trouble is related to static initialization; when your app runs, the classes and methods get compiled just-in-time; the first time some class is touched, its statics need created and initialized, and there could be issues about the order in which this happens, maybe race conditions even. If this hypothesis would stand, you could remove almost all code and still have the trouble, until you start simplifying the initializer stuff. Do you have static constructors at all? (i.e. classes with a constructor that is declared static).
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
|
|
|
|
|
No, I do not have any static constructors. I do, however, have a class (which is used to store the data needed to run the app.) which contains a few static members. Is there anything I can do to see if that class is the problem?
|
|
|
|
|
check for this pattern:
class Program {
public static Main() {
Application.Run(new MainForm());
}
}
class MainForm {
private int i=Globals.Value;
public MainForm() {
MessageBox.Show("We never get here");
...
}
...
}
class Globals {
private static j=...; <<<<<<<<<<<<<<<<<<<<<
private static Globals() {
... <<<<<<<<<<<<<<<<<<<<<
}
public static int Value {
get {
... <<<<<<<<<<<<<<<<<<<<<
}
}
}
All statements marked <<<<<<<<<<<<<<<<<<<<< will execute before you reach MessageBox.Show and could crash your app
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
|
|
|
|
|
The only time the static members of the class are assigned to happens after the main form loads. I am currently going through and removing the assignments to test that though. I'll be back soon with the results.
modified on Saturday, May 22, 2010 8:15 PM
|
|
|
|
|
Okay. That didn't work either. I wonder if I must re-code the project pretty much from scratch. :-P
|
|
|
|
|
have you tried another PC? another Visual?
either something in your system is broken (outside your app), or your code does something that (sometimes) fails, but then the cause should be visible in the source files. I haven't seen your code, I can't tell, but you should be able to.
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
|
|
|
|
|
Okay, I built the project in Release mode and ran it in the debugger. Success. Running it from the \Release folder, however, was a failure. Now running it from the \Debug folder won't work either.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
