When build and run in VS, VS won't do web.config transformation, IISExpress always reads and uses web.config. Web.config transformation only happens when deploy.
Then why we need web.debug.config? We can add set all debug purpose properties in web.config directly, like <compilation debug="true">, then override those properties in web.release.config when do deployment. The whole process looks like it doesn't need web.debug.config at all.
Does anyone know why we need web.debug.config? Someone may say when we want to deploy debug build to web server, well, if that is the case it can also done by direct copy web.config to web server.
these files are added by default based on your default build configurations (Release and Debug). Acutally you can freely delete this file assuming that every publish and deploy to environment different than dev should be in Release mode.
Related
I have ASP.Net web form application created using Visual Studio IDE. The app has code that uses environment variable like this:
Environment.GetEnvironmentVariable("key")
The reason to use environment variable is for deploying in staging and production environment as a containerised app. But how do I run Visual Studio debug mode locally to use line break? Or how do I add environment variable in debug mode?
Preferably the environment variable is specific to the application locally.
There is no environment variable being set, so the code failed
'Environment.GetEnvironmentVariable("key")"
You can use the launchSettings.json feature to setup local environment variables for debug purposes. Here is the link to the documentation. Hope this helps.
Web.Config Transformation can generate different web.config files under different publishing environments, which is very convenient and practical.
There is a default web.config in the newly created web project, and the format can also be defined as web.[name].config file. The rules defined in this configuration file will modify the web.config file when publishing.
In the default project, Web.Debug.config and Web.Release.config files will be created, corresponding to the Debug and Release environments respectively.
First add the Test configuration
2. Add Test config Transformation file
On web.confg, right click, Add Config Transform, VS will add Transformation file Web.Test.config for the newly created Test configuration
3. Modify the Web.Test.config file.
This code needs to be uncommented.
Find the current project.
5. Open it with Notepad and scroll to the bottom:
Just add this paragraph.
If Visual Studio pops up a prompt box, click Overwrite, and then save.
I have an ASP.NET (4.7.2) app that successfully runs and starts on my machine. This app has a web.config file that contains the following:
Web.config
<appSettings>
<add key="username" value="someone#email.com" />
<add key="port" value="25" />
</appSettings>
These are the configuration values I want to use while working. However, when I deploy the app to my Azure App Service for test purposes, I want to change the port value. For that reason, I've added a config transform named "Web.Test.config" with the following:
Web.Test.config
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
<appSettings>
<add key="port" value="58" xdt:Transform="SetAttributes" xdt:Locator="Match(key)" />
</appSettings>
</configuration>
Unfortunately, it doesn't seem like the transform is happening. I've ready that the transforms only happen during "publishing". At this time, I'm deploying via an Azure DevOps Pipeline that includes the following tasks:
NuGet
Restores the packages based on the .sln file
MSBuild
Builds the .csproj that defines my ASP.NET app. The "Configuration" property is set to "Test".
Azure App Service Deploy
Attempts to deploy the ASP.NET app as a "Web App on Windows" to my deployment slot. The "Package or folder" is set to MyAspNetApp. The
While this build pipeline successfully runs, the configuration transforms do not seem to be taking effect. How do I do a "publish" via an Azure DevOps Build Pipeline to an Azure App Service so that my config transformations will be generated.
For App.Config or Web.Config (XML) file there are two options.
File Transform task suggested by #Jabberwocky in the comment.
Variable Substitution as per below image in the release pipeline.
Sample XML variable substitution
For modern .NET apps where we use json configuration, variable substitution is the only way. Even though File Transform task promises to work for both it is not clear as per this thread
For JSON variables, you have to enter the full path hierarchy like this
Sample JSON variable substitution
How do I do a "publish" via an Azure DevOps Build Pipeline to an Azure App Service so that my config transformations will be generated.
First, we need to make sure the web.*.config files are included in the build output and the file is transformed correctly. Check it locally first.
Besides, the following steps should help:
Remove the nesting of the web.dev/stest/atest/prod.config files
either by removing the element in csproj, a nesting
add-on for VS or the File Nesting context menu item in VS 2017
A note from the documentation stated XML transformation notes that:
By default, MSBuild applies the transformation as it generates the web
package if the element is already present in the
transform file in the *.csproj file. In such cases, the Azure App
Service Deploy task will fail because there is no further
transformation applied on the Web.config file. Therefore, it is
recommended that the element is removed from all the
transform files to disable any build-time configuration when using XML
transformation.
Make sure that the *.config files have the 'Copy to Output Directory'
property set to if newer or always
Build the solution locally and check the contents of bin\release
folder and make sure the web.*.config files are included
Run a build in VSTS and make sure the web.*.config files are included
in the zipped package
Check the checkbox XML transformation on the Azure App Service Deploy task:
There is a great document about how to Using XML Transformations when deploying to Azure App Service using VSTS, you can check it for some more details.
BTW, since you just need to change the port value, you can use the option XML variable substitution on the the Azure App Service Deploy task.
Ticket for details: How to transform Web.Config file 'Properly' with VSTS!
Hope this helps.
I've got a basic ASP.NET Web Application with the following publish settings:
Publish to File System.
Delete all existing files prior to publish - Ticked
Precompile during publishing - Unticked
Exclude files from the App_Data folder - Ticked
While the publish does work as expected, it seems to publish quite a bit of extra baggage.
\bin
Web.config
Web.Debug.config
Web.Release.config
WebServer.dll
\Properties
AssemblyInfo.cs
\PublishProfiles
Release.pubxml
MyWebForm.aspx
MyWebForm.aspx.cs
MyWebForm.aspx.designer.cs
Web.config
Web.Debug.config
Web.Release.config
WebServer.csproj
WebServer.csproj.user
Out of all this, I'm able to remove everything but the following:
\bin
WebServer.dll
MyWebForm.aspx
MyWebForm.aspx.cs
MyWebForm.aspx.designer.cs
Web.config
So, my question is two-fold:
Firstly, why does the publish option, publish various things such as *.csproj files, or the *.config files in the bin directory etc. as the site appears to function perfectly well without this baggage. What is the purpose of these files being made public?
Secondly, is there a way to configure the publish operation to just publish the minimum required files for the project?
I'm not sure as to the reason behind the publish option is publishing the unrequired files, but it seems there is a very easy way to stop it. In the properties of the project under the option "Package/Publish Web" there is a group "Items to deploy", where I am able to select "Only the files required to run the project".
Should developers keep the web.config file updated and commit it to a VCS such as SVN? At my company we very rarely update it via SVN; instead somebody will create an "instructions" text file in our deployment scripts (SQL scripts and the like, plus batch files to compile the ASPX files as individual DLLs for deployment) that says something like "Change X to Y in web.config files for Sites A, B and D", and relies on the individual developer following those instructions each time the file is updated.
This seems counter-intuitive to me: I would expect the web.config file to be kept in sync as needed, with necessary changes being made and the file committed as any other artifact of the codebase, but I have raised this issue in the past and nobody has paid it any mind.
What approach should be followed when dealing with config files like this?
Absolutely, web config must be in source control, and you can define differences beetween various versions of web.config with web.config configurations
for example we have one for local development server, one for test IIS server, and one for production IIS server. And we can set solution configuration and publish from visual studio for different targets and different clients (sites).
here are the links for web.config configurations :
Common Web.Config transformations with Visual Studio 2010
Web.config Transformation Syntax for Web Application Project Deployment
I wouldn't allow all developers to have access to web.config file at all either via SVN or other way. Although if in your company it is allowed for developers to access web.config i see no reason why it shouldn't be on SVN. Point of SVN is to keep track of your single/multi person development process. If you make changes to web.config and this cause a bug in someone's else code it would be much easier to revert changes using SVN
I just upgraded to Visual Studio 2010 and MVC 2.0 and I noticed the Web.config has two additional files attached to it? Are these files used to specify debug and release specific settings, so you don't clutter up the main Web.config?
Does it even make sense to place a connection string in the root Web.config file if I have a local and remote one in the debug and release Web.configs respectively?
Thanks!
It's the new Web.config transformation feature of Visual Studio 2010. More information here.
Edit:
Are these files used to specify debug and release specific settings, so you don't clutter up the main web.config?
It isn't limited to three files, you could (in theory) have as many files as you have environments. The "top level" Web.config provides a template of your web config. The files under it provide replacement values specific to that environment (like if you have different connection strings for local/stage/test/whatever).
Does it even make sense to place a connection string in the root web.config file if I have have a local and remote one in the debug and release web.configs respectively.
It would only make sense if it wasn't going to change between environments. Sounds like in your case it does so, in your case no, it would not make sense to leave it in the Web.config.
These are Web.config transformations files. From ASP.NET Web Deployment using Visual Studio: Web.config File Transformations:
There are two ways to automate the process of changing Web.config file settings: Web.config transformations and Web Deploy parameters. A Web.config transformation file contains XML markup that specifies how to change the Web.config file when it is deployed.
You can specify
different changes for specific build configurations and for specific
publish profiles. The default build configurations are Debug and
Release, and you can create custom build configurations. A publish
profile typically corresponds to a destination environment.
In case anyone is interested, here is something I wrote up to have a dynamic connection string per environment. I wanted to deploy the code to any environment (Dev, Test, Pre-Prod, Prod...) without having to worry about changing connection strings. I couldn't really find a good way to do this with Asp.Net MVC 4, so I came up with my own way to rely on a properties file per environment.
There may be a better solution, I come from a Wicket/Java background and recently started developing with MVC 4 so, it's possible a better solution exists. But here is a link to my question and answer for a dynamic connection string:
Asp.net MVC 4 dynamic connection string
That was something long needed in VS. Unfortunately there seems to be a problem with the implementation. For example consider this scenario (VS.2010 Ultimate, all SP):
Web.Config
No connectionStrings section
Full Membership User/Role/etc. Provider configuration using connectionStringName="test"
Web.Release.Config
No membership configuration (already specified in main web.config)
connectionStrings section including the CS named "test"
Web.Debug.Config
No membership configuration (already specified in main web.config)
connectionStrings section including the CS named "test"
When executing the application gives the following error:
The connection name 'test' was not found in the applications configuration or the connection string is empty.
In other words, because the connection string elements are in the Release/Debug designer files and used by configuration elements in the main (Web.config) file, it is unable to resolve it.