.NET development: switching between DEV and PROD environments. Part one

Introduction

When developing and debugging a project in Visual Studio, you usually do this by compiling code in a Debug configuration. On the same combat server project is laid out, compiled in the release configuration. And each project sooner or later grows to such an extent that a certain “debugging” or “release” code appears in it - that is, the code that should work only in one of the configurations. And if the case was limited only to code, then the conditional compilation directive #if would solve all the problems. But usually, the code specific for each of the configurations, and often the layout of web pages, is still pulled after the code. At the very beginning, when such problems are just beginning to appear, and are not yet a severe headache, the usual commenting on unnecessary lines at a particular moment with code / markup / settings is usually used. But this is Road To Hell in its purest form. But I would like to tell you about Stairway To Heaven.



When I first encountered such a problem and was already mired in crutches from comments and sets of various configuration files, then at some point I decided to take an interest in someone else’s experience, as well as better explore the possibilities of the development environment and the tools used. And suddenly I found out that all my artificial crutches are absolutely redundant - the problem can be solved by standard means and without degrading the readability of the code. I will describe the results of my research in a short series of articles, where I will review examples of environmental problems and mechanisms by which all code, settings and html markup can be automatically brought to the desired form when a project is published. This will focus on the development of ASP.NET MVC applications, as an area in which I mostly work. However, everything written will be applicable to any .NET-development in Visual Studio.

Transform a web.config file

In this article I will start with the first important tool - with the transformation of a web.config file. If you are still not familiar with this technique, then this section is definitely worth reading.
')
Transformation appeared together with Visual Studio 2010 and immediately solved a huge number of problems associated with different settings for DEV and PROD environments. In this case, the rules by which the transformation is performed, are extremely simple and flexible.

You probably noticed that, starting from VS 2010, the web.config file suddenly began to appear in the project tree as a container, inside of which two new web.release.config and web.debug.config files now lie. These are the files in which the transformation of the main web.config file is configured. You may not use these two files at all and work with the main web.config as the only one, and this will not cause any problems. But it will be better to comprehend this Zen, to subsequently practice it always and with the mind.

Studying how transformation works, the most important thing is to clearly understand the two main things when setting it up:

1. Transformation only works when publishing a project.

2. The web.debug.config and web.release.config files do not replace the original web.config, but change (transform) it

It would seem that the first paragraph imposes serious restrictions on the use of transformation in development. And really, what can be the use of it when you are developing a project, for example, under IIS Express, that is, without publications? But in fact, this is not a problem, but I will touch on this moment later.

As for the second point, this is a common mistake of those who first encountered the transformation, including me: at first I decided that when publishing, the web.config file was replaced with the corresponding release / debug file. Of course, the very first publication made me read the manual carefully, because it does not work at all.

It works in the following way: in the transformation files, it is indicated exactly how the original web.config should be changed when published in the appropriate configuration. We will not go far and consider the standard example. The auto-generated web.release.config file by default already contains one standard transformation directive. Here is its listing (with deleted comments):

<?xml version="1.0" encoding="utf-8"?> <configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform"> <system.web> <compilation xdt:Transform="RemoveAttributes(debug)" /> </system.web> </configuration> 

First, note the key point: the configuration element defines the xdt prefix for the XML-Document-Transform namespace. In this namespace, two attributes are declared, with the help of which the transformation is defined: Locator and Transform. The Locator attribute defines what you want to change in the configuration file, and the Transform attribute specifies how you want to do it. In the given example, only Transform is used - its value tells us what we need in the compilation element of the original web.config file to remove the debug attribute (along with its value, of course).

Reference: the debug attribute of the configuration / system.web / compilation element is responsible for compiling asp.net pages. In the default web.config file, the value of this attribute is usually true, and this means that asp.net pages will be compiled with debug information added. In the Release configuration (that is, in the configuration in which the project is usually compiled for laying out in PROD), this is not necessary, and for this purpose, the default command is inserted into the transformation file web.release.config to remove this attribute. I will mention all of this in more detail, but later.

Let's return to our example. When a project is published in the Release configuration, the debug attribute in the configuration / system.web / compilation element will be removed from the final web.config file, regardless of what its meaning was and whether it was there at all. Note that in the example the Locator attribute is missing, because the transformation is explicitly set for a specific element of the config file. But using the Locator attribute, it is possible to more flexibly specify elements of a web.config file for transformation, in particular, using XPath expressions or specifying an explicit correspondence of attribute values. Here is another example:

 <configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform"> <appSettings> <add key="Setting1" value="SettingValue" xdt:Locator="Condition(@key='key1')" xdt:Transform="Replace"/> </appSettings> </configuration> 

In this example, the source web.config will search for the configuration with the key1 key (this is specified via XPath in the Locator), and if such is found, it will be completely replaced

(the Replace value of the Transform attribute) on the setting from the file with the transformation. The Condition value of the Locator attribute contains an XPath expression applied to the element of the config file in which it is defined, and the element automatically becomes current for the XPath expression. In addition to Condition, you can specify the value of XPath in the Locator attribute - it differs only in that the XPath expression will be considered in a global context.

Another example:

 <configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform"> <system.web> <customErrors mode="On" xdt:Transform="Insert"> <error statusCode="404" redirect="/Error404" /> <error statusCode="500" redirect="/Error500" /> </customErrors> </system.web> </configuration> 

In this example, we add to the final web.config an entire customErrors settings section (by the way, a very useful and often used section for customizing the behavior of a web application in case of an error). Note that using the Insert value of the Transform attribute, we assume the absence of this section in the original web.config. If it is there, then we should use Replace instead of Insert.

As a result, we have a powerful tool with which we can change the web.config file on the fly when publishing a project in various ways, namely: change, delete or add individual elements or attributes of elements (as well as entire groups of elements) and change values any attributes of any elements. This allows us to get rid of the constant commenting on the settings in the web.config file or its regular substitution with a “test” / “combat” when debugging. A complete list of transformation attribute values ​​with usage examples can be found in MSDN .

If we talk about the actual use of transformations in my projects, then of all the settings of the web.config file, the following are most often affected:

1. Connection Strings or, in other words, all database connection settings. This applies to the connection string itself and the settings of all ORM frameworks.

2. Settings section appSettings. All settings are transferred from development / debug mode to combat mode.

3. Web application error handling settings - section /<system.web>/ in the example above. When developing and testing, for me personally, it’s preferable to see all the errors with text and stack trace at once, rather than being thrown over to a beautiful blank page. Of course, this is unacceptable for combat applications.

4. Settings trace / log / debug. In addition to the above settings /> from the web.config, all settings related to debugging and tracing are cleared (or left but turned off). And the log settings are transferred from the paranoid mode to the worker.

5. Settings for caching profiles for web pages. Http page caching is completely unnecessary when debugging, so the caching profiles in web.debug.config are simply disabled via the enabled = ”false” attribute. (I hope you use caching profiles in the OutputCache attribute?)

Of course, this is not a complete list - it all depends on the specific project. But it is these settings that are affected by transformations in almost all cases.

As for the development using IIS Express, in which publications do not occur, then, as I have already said, this is not a problem for the use of transformations. I often develop web applications using IIS Express (that is, without publishing on a real web server), and I do it quite simply: the original web.config file contains all the necessary settings in the DEV version, and transformations are set only in the web .release.config. That is, the original web.config, in fact, serves as a web.debug.config file.

So, Visual Studio gives us the opportunity to flexibly control the operation of the application in the DEV and PROD environments, while not embedding it in the code, layout or settings with various crutches or stubs. If you still do not own this technique, then this gap should be urgently closed. In the following articles - about minification, bundles, scripts, DEBUG and how to use it correctly.