I'm working on an application that utilizes the WCF Service Model concept to handle database calls from a WPF client via IIS on a remote server. In order to guarantee that I can modify & test the service layer without breaking the production application, I've deployed a 2nd "debug" service layer and would like to switch between these on the fly in Visual Studio by swapping the build config between "Debug" and "Release". To do this, I kept two separate App.config files, and run a Post-Build event depending on the selected build config:
if "Debug"=="$(ConfigurationName)" xcopy "$(ProjectDir)App_Debug.config" "$(TargetPath).config" /Y
if "Release"=="$(ConfigurationName)" xcopy "$(ProjectDir)App_Release.config" "$(TargetPath).config" /Y
if "Debug"=="$(ConfigurationName)" xcopy "$(ProjectDir)App_Debug.config" "$(TargetDir)$(TargetName).vshost.exe.config" /Y
if "Release"=="$(ConfigurationName)" xcopy "$(ProjectDir)App_Release.config" "$(TargetDir)$(TargetName).vshost.exe.config" /Y
This works, I check the output directories and they have the appropriate connection strings and parameters to access the desired services. However, when I hit the "Start" button in Visual Studio, it will overwrite both config files with the App.config file from my project... If I remove or rename App.config, then my post build event fails.
The next thing I noticed was that disabling the Visual Studio Hosting Process (vshost.exe) solves the overwrite, except debugging in VS becomes painfully slow... it seems this stems from re-loading components and debugging symbols every time. I reckon this alone is enough reason to keep the vshost process enabled, combined with whatever other benefits using it provides.
Why is the vshost overwriting my config files even though the solution is built and up to date? Is there anything I can do to prevent the vshost or Visual Studio from doing so? Are there any other strategies I can utilize to achieve the same functionality? The fallback would be to remember to copy and paste the appropriate config file when testing or deploying, but that's one more step in the build process that is cumbersome and confusing to anyone new to the application.