--Rajeev
Okay, I admit I had made some false assumptions about your project. The project you are showing has a completely custom build process. You've implemented your own "Build" and "Compile" target, and you didn't code in the step to copy APP.CONFIG to the bin directory as AssemblyName.exe.config. When I said that this should happen automatically, what I really should have said was that this happens automatically if you are using the build process defined in Microsoft.VisualBasic.targets and Microsoft.Common.targets. This is the default VB build process that gets run for all VB projects that you just create from Visual Studio, because those .VBPROJ files will have an <Import Project="... ... Microsoft.VisualBasic.targets"/>. But since you're using your own build process, you'll have to add the step to copy APP.CONFIG yourself.
Couple other notes and questions:
1. Just out of curiosity, why did you implement your own build process rather than just importing Microsoft.VisualBasic.targets? There's nothing wrong with what you did; I'm just curious.
2. You actually don't have APP.CONFIG listed as an item in your project anywhere, or at least not that I can see. In one of the ItemGroups you need to add:
<None Include="app.config" />
3. The <ResGen> task doesn't exist anymore. Which version of MSBuild are you using? The replacement for this is the <GenerateResource> task.
4. When you pass in the "Sources" parameter to <ResGen>, it's actually expecting a bunch of .RESX files, but it looks like you're passing in .RESOURCES files which are already compiled.
--Rajeev
1. You don't need to implement your own build process in order to have flexibility. I would suggest that you remove the <Target> nodes from your generated project file, and instead just add this line:
<Import Project="$(MSBuildBinPath)\Microsoft.VisualBasic.targets" />
That will take care of everything so that you don't have to figure out the whole build process yourself. If you do need to customize portions of the build, you can still do so by overriding specific targets or inserting your own build steps into the chain where appropriate. If you have a specific customization you're trying to achieve, and need help with it, post another question to this forum and somebody will try to help.
Also, something you said is making me wonder if you currently have two different project files ... one .PROJ file which you're generating yourself and using with MSBuild.exe from the command-line, and a separate .VBPROJ file which you are creating with Visual Studio for builds inside the IDE. Is this true? If this is the case, it is absolutely not necessary to do this. You can use a single project file for both. You can just run MSBuild.exe on the .VBPROJ that Visual Studio created. Also, you can open the .VBPROJ and customize portions of the build process as necessary, and it will still work both on the command-line and inside Visual Studio.
3. You may also consider upgrading to the final release version of VS 2005 and .NET Framework 2.0, which just shipped.
Regarding the error you're getting when running the project as built by MSBuild but not when built by VisualStudio ... this again makes me wonder if you have two different project files with different build processes ... one for MSBuild and one for VisualStudio. If you use the exact same project file for both, then the build process should produce identical binaries, and they should run the same way. By the way, what exception were you getting when you ran your app after building it with MSBuild?
--Rajeev
