1

We're using an AfterBuild target in the vbproj to replace the config file depending on the selected configuration :

<Target Name="AfterBuild" Condition="'$(Configuration)' != 'Release'">
  <Delete Files="$(TargetDir)$(TargetFileName).config" />
  <Copy SourceFiles="$(ProjectDir)$(Configuration).config" DestinationFiles="$(TargetDir)$(TargetFileName).config" />
</Target>

As an example, let's say we have 3 configurations : Debug, Test, Release. Debug is the local debugging configuration. Test is a pre-production environment used for user-acceptance tests. Release is our production environment.

In the App.config file, we store the configuration for our Release environment. In the Debug.config file, we store the configuration for our local debugging needs. In the Test.config file, we store the configuration for our user-acceptance environment.

The goal of the AfterBuild target is to replace the Release configuration (App.config) when building/executing with the Debug configuration (Debug.config) or the Test configuration (Test.config).

Everything works as intended when we publish the application (Release, App.config) or if we build the application and launch the bin\<appname>.exe (Debug or Test).

However, if we Start the application from Visual Studio, with the Visual Studio hosting process, the correct configuration is copied to bin\<appname>.exe.config, but it seems that Visual Studio doesn't copy the correct configuration to bin\<appname>.vshost.exe.config. We tried cleaning the solution, performing a Rebuild before debugging, manually deleting the bin\<appname>.vshost.exe.config file before launching, but it seems that the hosting process always copies the configuration from the default App.config file. The same problem happens whether we try to Start with the Debug configuration or the Test configuration.

To add to the confusion, we created multiple test projects, using the same AfterBuild target, and some of them work correctly, others don't. All projects are using .Net Framework 4.5.1, but we also reproduced the problem with .Net 4.5. It doesn't seem to be caused by the project type, since we're able to reproduce the issue with a Console Application as well as a Windows Forms Application.

What could be causing the problem?

Alternatively, could we use another solution to manage the configuration for each of our environment?

Notes

  • We use the default App.config file for our Release environment because ClickOnce doesn't seem to support AfterBuild targets.
  • We use Visual Studio Express 2013 for Windows Desktop, so we can't use any plugin like SlowCheetah.
Benjamin Beaulieu
  • 995
  • 2
  • 10
  • 26
  • 1
    Just an idea to work with. Using the PreBuild event and copying the required config over the app.config leaving VS do its usual work? – Steve May 22 '15 at 16:17
  • interested to see if someone knows how to do this... we tried, and failed, and resorted to manually changing config files for running inside VS. – DrewJordan May 22 '15 at 16:26
  • 1
    Hard to see why you don't just add another `` command. Or simpler yet, just turn of the hosting process option. – Hans Passant May 22 '15 at 16:59
  • @HansPassant : I'm pretty sure the config is copied on launch, not on build. If we added another `` command, it wouldn't be executed on launch anyway. – Benjamin Beaulieu May 22 '15 at 17:08
  • @Steve : We tried the approach you suggested, and we still observe the same behavior. If we switch the configuration from Release to Debug, the App.config contains the correct parameters for the selected configuration (Debug), but the hosting process still uses the previous configuration (Release)... – Benjamin Beaulieu May 22 '15 at 17:12

2 Answers2

4

Following Steve's suggestion, we moved the logic to the BeforeCompile target, specifying to replace the App.config depending on the selected configuration : 

<Target Name="BeforeCompile">
    <Delete Files="$(ProjectDir)App.config" />
    <Copy SourceFiles="$(ProjectDir)$(Configuration).config" DestinationFiles="$(ProjectDir)App.config" />
      <Output TaskParameter="DestinationFiles" ItemName="FileWrites"/>
    </Copy>
</Target>

It wouldn't replace the file every time, and when it did, it didn't necessarily apply to the <appname>.vshost.exe.config file. We stumbled on another answer which guided us on the right path : Can Visual Studio automatically adjust the name of other file as it does with app.config?

Adding the following <Copy> command, we achieved the desired behavior :

<!--
Copy the application's .config file, if any.
Not using SkipUnchangedFiles="true" because the application may want to change
the app.config and not have an incremental build replace it.
-->
<Copy
    SourceFiles="@(AppConfigWithTargetPath)"
    DestinationFiles="@(AppConfigWithTargetPath->'$(OutDir)%(TargetPath)')"
    OverwriteReadOnlyFiles="$(OverwriteReadOnlyFiles)"
    Retries="$(CopyRetryCount)"
    RetryDelayMilliseconds="$(CopyRetryDelayMilliseconds)"
    UseHardlinksIfPossible="$(CreateHardLinksForAdditionalFilesIfPossible)"
    >

    <Output TaskParameter="DestinationFiles" ItemName="FileWrites"/>

</Copy>

We now have a config file for each configuration (Debug.config, Test.config, Release.config). Visual Studio replaces the App.config file with the correct one on each build/launch. The resulting <appname>.vshost.exe.config file contains the correct parameters.

Bonus

The underlying benefit with this solution is that we have one config file per configuration, so we can update the .vbproj file and replace, for example,

<None Include="Debug.config" />
<None Include="Release.config" />

with

<None Include="Debug.config">
    <DependentUpon>App.config</DependentUpon>
</None>
<None Include="Release.config">
    <DependentUpon>App.config</DependentUpon>
</None>

All config files will be grouped under the main App.config file in Visual Studio : enter image description here

Community
  • 1
  • 1
Benjamin Beaulieu
  • 995
  • 2
  • 10
  • 26
0

For me it helped to disable VisualStudio hosting process.

Remove the check mark in:

Project -> Preferences -> Debug -> Enable Visual Studio hosting process

This stops Visual Studio from overwriting the *config file.

martin
  • 1