2

I have an xna game exported in a dll file. Everything to run the game (except the content) is in this library, especially the main game class.

In another assembly, I load the game dll, instantiate the game class and call Run() on it. This will run the game. After that, when the game is closed, I call Dispose() to completely close the game. The main program (that, which loaded the dll) is still running.

Up to here, no problems.

However, when the game uses a Song with the MediaPlayer, it seems that the game is not closed completely. In the content directory of the game, there are the according .xnb and .wma files for the song. And although the game does not run anymore, I cannot delete the .wma file, because a process (my main program) still holds a handle to this file. The .xnb file can be deleted without any problems.

I found out that an additional thread is created by the game, which is not closed after the game exits. I suspect this thread to be a media player thread that still holds the file handle. Is there any way to force xna to give up the file handle? Maybe killing the additional thread would be an option (although it is not very nice), but how to do that?

Calling Stop() on the MediaPlayer does not change this behaviour.

Nico Schertler
  • 32,049
  • 4
  • 39
  • 70

1 Answers1

0

Generally, the general practice when creating XNA games is to not use the MediaPlayer at all, instead using the Sound & SoundInstance alternative. Though they may use different sound formats, they are better for performance since MediaPlayer is a huge hog, and in your case, threading issues.

I am probably wrong, but I think MediaPlayer actually calls the local machines actual MediaPlayer. This might be one of the reasons why it's so hard to stop it's thread.

It's up to you, but I would avoid MediaPlayer entirely. It's considered a curse to me :D