I am currently working on a project to develop a game that allows users to add there own audio content, such as music tracks.

However, I cannot find a solution for adding in new audio assets that doesn't require the XNA project to be rebuilt in GameStudioExpress.

So far I have figured out the following:

The new audio has to be added to the .xwb wavebank file. This can be achieved by copying new audio into the audio source folder and renaming it and replacing it over an existing file. The XACTBld command line tool can then be used to to create the .xgs .xwb and .xsb files. However, these new files cannot simply be copied into the Debug / Release / Published folder as an error occurs when the existing build is run, using the .exe. Instead, a rebuild has to be done within GameStudioExpress.

Does anyone have a clue as how best to solve this problem? Here are the options as I see it:

1) Find another way to "trick" the .exe into using the new .xwb
2) Find a way to rebuild the XNA project from the command line
3) Find some other way to include audio assets into the built .exe.....

Thanks for you're time, I look forward to seeing if you guys come up with any solutions.

1) This 'hack' may help though other than theory there was no code released.

2) Quite possible but not necessary - see 3). Surely allowing people to mod and forcing them to have your source code to rebuild is a bit much anyway

3) YOu don't need to rebuild the entire product you can rebuild jsut the XACT part of it - the command line stuff for Xact is documented in the DirectX SDK See XACTBLD. However you ned to check the license for Xact to see if these parts of it can be released with your game otehrwise people will need a full LGS or DX SDK install just to get the parts you need.
**EDIT** Oops - you already found this..
So what error are you getting when you rebuild the EXE. Since your scenario is about people providing sound after the fact will they really rebuild the EXE anyway?

4) Use something other than Xact - though this won't work on the 360 of course.

Cheers Zman.

Yes, I have trying to use XACTBld - this clearly seems to be the way forward.

After using XACTBld to create new .xgs .xwb and .xsb files, I run the Game.exe file in my Release folder and get message saying,

"An exception 'System.ArgumentException' has occured in Game.exe"

from a Just-In-Time Debugger - I have never used one of these before and it claims to be "Unable to attach to the process" when I try to investigate further.

I would be keen to know how to get round this if you have any ideas. Also, I have successfully tried to build from within XACT to change the .xwb instead of using XACTBld and it works. However, this wouldn't be a suitable method in the final project.

My guess is that you are using XACTBld from a different version than XNA expects to see. Xact changes every DX SDK release.

XNA GSE 1.0 uses Xact from the Oct 2006 SDK

XNA GS 2.0 uses Xact from the Aug 2007 SDK

Ok, I've fixed the problem now.

I had the right version of GSE 1.0 and XACT Oct2006. However, I was using the normal Windows command promt. When I switched to the XNA Game Studio Express Command Prompt (found in Start: Microsoft XNA GSE: Tools), the rebuild of XACT files works and the game .exe runs fine.

Cheers for your input Zman:)

So you have multiple versions of XACTBLD on your system and I suspect the DirectX SDK (non Oct 06 one) is winning the PATH war... XNA command prompt must add its own path at the head of the list.

Yes indeed, you're right! I do have the 2 versions of XACTBld you suggest.

However, when I remove the DirectX XactBld (just by deleting the .exe), the command prompt stops recognising the xactbld command.

Its not too much of a problem though, cos I just use the XNA command promt....
Unless of course you have any suggestions of how I can remove the Direct X version and retain the xactbld command??:)

DirectX SDK adds its path to the global command prompt path which means that if you type xactbld without a full path it finds that one.

When you open the XNA command prompt it adds the XNA path just to that command prompt which is why it works

To make it work in every command prompt you need to use the full path c:\program files\Microsoft XNA\etc etc instead of just typing xactbld. Or you could add the XNA directory to the global path but then you wouldn't be able to call the DirectX version without using the full path.... this is the problem of paths and why they can be very unreliable on different systems.