What is the difference between running in VS 2010 and running a builded EXE?
As a school project we've created a C# XNA 4.0 Game that runs perfectly when run (in either Release or Debug) from Visual Studio 2010 itself. However, when it's built, the game inexplicably crashes at a certain point.
The responsible code portion seems to be this:
while( true )
{
if( Client.readInfo )
{
开发者_StackOverflow t.Stop();
t.Dispose();
// Save last good IP to file
string toWrite = IPinput.filledIn;
using( StreamWriter file = new StreamWriter( "multiplayer.dat", false ) )
{
file.WriteLine( toWrite );
}
ExitScreen();
using( LobbyScreen screen = new LobbyScreen( c ) )
{
screenManager.AddScreen( screen );
}
break;
}
else if( itTookToLong )
{
Client.killMe = true;
IPinput.Text = "Server IP: ";
IPinput.filledIn = "";
break;
}
}
This waits till the started Client thread makes the public static attribute readInfo true (which happens, because the server obtains the client) or a timer runs out after 10 seconds. Both things work perfectly fine when running through VS, but the game just stops responding when run as built EXE.
What could this be?!
Edit: I seem to have found the fix already, FINALLY. Adding Thread.Sleep(1);
at the bottom of the above while(true)
loop seems to fix all problems! Don't know why this is different between running an EXE and running from Visual Studio though, but hey it works.
Edit2: This site explains my whole problem: http://igoro.com/archive/volatile-keyword-in-c-memory-model-explained/ Thread.Sleep just accidentally fixed everything ;)
Hard to tell from the code you have posted, but I believe you need to make Client.readInfo
field volatile
. The reason that Thread.Sleep
fixed your problem is that it puts a memory barrier as a side effect.
I suspect that there is a problem with permissions to write the file to disk. The .exe has different permissions when it us running than VS does.
Here is where I would start: add some try-catch blocks in your code so you can figure out where the exception is occurring. While troubleshooting, display the exception details on the screen.
As a temporary debugging strategy, you could also try this: add some kind of logging and record every step along the way here. Right after the line if( Client.readInfo )
, test that you have arrived at that line. Right after the line string toWrite = IPinput.filledIn;
look at the contents of the string toWrite, and so on.
If you'd rather, just for debugging purposes, you could throw those messages to yourself on the screen. I'm not familiar with XNA, but in any old web app you can usually do this with Response.Write
.
Once you narrow down where the exact problem is, you can test further for what it is. And when you've fixed it, of course, you remove all this code.
精彩评论