I prefer to separate my appSettings and connectionStrings elements out of my web.config and keep them in separate config files. My customized web.config file replaces the elements with the following:
What is the purpose of explicitly replacing the appSettings and connectionStrings elements with boilerplate code just because they contain a configSource redirect??
Note:
For reference and clarification, this all occurs in the first place because of this section in Umbraco.Web.UI.csproj:
<Target Name="BeforeBuild">
<!-- Create web.config file from Template if it doesn't exist -->
<Copy SourceFiles="$(ProjectDir)web.Template.config" DestinationFiles="$(ProjectDir)Web.config" OverwriteReadOnlyFiles="true" SkipUnchangedFiles="false" Condition="!Exists('$(ProjectDir)Web.config')" />
<!-- Transform the local Web.config file in Visual Studio -->
<TransformXml Source="$(ProjectDir)Web.config" Transform="$(ProjectDir)web.Template.$(Configuration).config" Destination="$(ProjectDir)Web.$(Configuration).config.transformed" Condition="$(BuildingInsideVisualStudio) == true" />
<!-- Always transform the Template file when not in VS (ie: build.bat) -->
<TransformXml Source="$(ProjectDir)Web.Template.config" Transform="$(ProjectDir)web.Template.$(Configuration).config" Destination="Web.$(Configuration).config.transformed" Condition="$(BuildingInsideVisualStudio) != true" />
<!-- Only runs if the Belle build folder doesn't yet exist -->
<CallTarget Targets="BelleBuild" Condition="!Exists('$(ProjectDir)\..\Umbraco.Web.UI.Client\build')" />
</Target>
<Target Name="AfterBuild">
<Copy SourceFiles="$(ProjectDir)Web.$(Configuration).config.transformed" DestinationFiles="$(ProjectDir)Web.config" OverwriteReadOnlyFiles="true" SkipUnchangedFiles="false" Condition="$(BuildingInsideVisualStudio) == true" />
</Target>
I was wondering if there was a particular reason you are building from source?
I've move my connection string details into a separate file and have had no issues with either debug or release builds removing that configuration from within my web config.
I'm troubleshooting a complicated issue and the simplest way to do this is to import my custom project into a solution with the full Umbraco source for better debugging visibility.
But since I use "configSource" to manage my environment settings separately, I have to comment out those lines in the config template; otherwise, I'd have to fix my web.config every time I build. So I'd just like to understand their purpose for being there in the first place.
configSource not allowed??
I prefer to separate my
appSettings
andconnectionStrings
elements out of myweb.config
and keep them in separate config files. My customizedweb.config
file replaces the elements with the following:However, I discovered that for some reason, when building from source, these are being stripped out and replaced in my modi
This is defined in
web.Template.Debug.config
:My questions is -- WHY?
What is the purpose of explicitly replacing the appSettings and connectionStrings elements with boilerplate code just because they contain a
configSource
redirect??Note:
For reference and clarification, this all occurs in the first place because of this section in
Umbraco.Web.UI.csproj
:Hi Brian,
I was wondering if there was a particular reason you are building from source?
I've move my connection string details into a separate file and have had no issues with either debug or release builds removing that configuration from within my web config.
I'm troubleshooting a complicated issue and the simplest way to do this is to import my custom project into a solution with the full Umbraco source for better debugging visibility.
But since I use "configSource" to manage my environment settings separately, I have to comment out those lines in the config template; otherwise, I'd have to fix my web.config every time I build. So I'd just like to understand their purpose for being there in the first place.
Hi Brian,
The reason lies in these lines in the Umbraco.Web.Ui.csproj:
The reason is from the past. Every developer was overwriting the web.config. And they had many different configurations checked in.
I am pretty sure, if you add an extra "web.template.**.config" file and you add a configuration to your VS solution, you will be a happy man again.
is working on a reply...