configure for target environment for publishing

Question

hi all,

I have an old ASP.NET Framework 4.5 application that I want to deploy to three environments: Development, QA and Production.

When I deploy my current project to a folder on a local path, and pick from the available settings:
Target location: C:\myPath...
Delete existing files: true (and Precompile during publishing)
Configuration: Debug
it will create the files as instructed, however, in the Web.config file, my connection strings section will replace:

<connectionStrings>
  <add name="Database1ConnectionString" connectionString="Data Source=ServerName.domain.com;Initial Catalog=Database1;Integrated Security=False;User Id=myUser;Password=myPass;" providerName="System.Data.SqlClient"/>

with

<connectionStrings>  
<add name="Database1ConnectionString" connectionString="Data Source=DebugSQLServer;Initial Catalog=MyDebugDB;Integrated Security=True;" providerName="System.Data.SqlClient"/>

but I have no recollection of defining any values for DebugSQLServer and MyDebugDB. As well, the security is changed and I need the non-integrated security where I use my defined user.

Can anyone tell me where exactly I am supposed to configure these publishing environments in VS 2022?

thanks,
elsvieta

Answer 1

Hi @elsvieta,

In Solution Explorer, right-click and select Properties to display the Properties page, select the Package/Publish Web tab.

The Package/Publish Web tab on the web application project Properties page lets you specify settings that are used when you deploy the project.

There are some detailed deployment documents below that you can check out.

ASP.NET Web Deployment using Visual Studio

Quickstart: Publish an ASP.NET web app

Best regards,
Lan Huang

---

If the answer is the right solution, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 2

Ok, the where and how of that connection string being changed?

In your project, you see this:

(make sure show all files is selected)

So, you have 3 files.

Web.config - most everything goes here, and in most cases your basic connection strings USED FOR and DURING development go here.

the next 2 files. (Web.Debug.config, and Release) are based on the concepts of a xml "transform".

I in most cases do not use the Web.Debug.config. This means you can have that on compile/build OR web deploy package run these transforms to the config file.

The end result is you now have the ability to build, test, run local. But, at publish time, then you can have some reconfiguring occur.

For example, during local development, I do NOT use https, and thus I have some code ONLY in the release.config to add the re-direct rules, and that any attempt to use http as opposed to https is redirected to https.

And of course the connect strings are also different.

So, in web.config, I might have this:

      <connectionStrings>
        <add name="WTeams.My.MySettings.DB" 
             connectionString="Data Source=.\sqlexpress;Initial Catalog=Teams;Integrated Security=True"
          providerName="System.Data.SqlClient" />
      </connectionStrings>

So, since I'm running local, with a local copy of the database, then little reason exists to bother with any kind of passwords. And like for most windows prompts, I use a "." (period) for the server name. As a FYI the above works rather nice when using source control (github), since then each developer can work, and the defaulted database server is their local copy of SQL server or SQL express on their dev box (we used "dot" in place of server name).

However, when you publish, then depending on the publish settings, if you choose release, then the "release" transform (the above Web. release.config WILL BE used!!!). It is NOT used if you JUST set/choose/change the setting during development. This one:

So above DOES NOT change, nor use the different config's.

However, WHEN you use the publishing wizard, then YES the additional config files are used and "combined" with the base web.config file.

That publish option we are talking about is this one:

So, if you choose release in above, the web.config + the transforms in the web.config.Release are used. If you choose debug in above, then the release config IS NOT used....

So, how do the transforms to the xml work?

Well, they work by you having the ability to

modify existing values in web.config.

Insert new values into web.config

Remove existing values in web.config.

So, as an example, above we have a default to use the local instance of SQL server without passwords. But, for the target web server, of course the passwords will be different, so now in place of a local server, and windows authentication, we will of course use SQL server logons.

So, in the release config, we have this:

      <connectionStrings>

        <add name="WTeams.My.MySettings.DB" 
         
             connectionString="Data Source=SQL-C1i2;database=Teams;UID=TeamDB;PWD=TeamDB$1" 
             providerName="System.Data.SqlClient"
           xdt:Transform="SetAttributes" xdt:Locator="Match(name)"/>

      </connectionStrings>

      <system.web>
        <compilation xdt:Transform="RemoveAttributes(debug)" />
      </system.web>
    </configuration>

So, in above we "match" the existing connection string, and change it.

(above server and passwords are long gone - but you get the idea).

And in the 2nd part, note the "remove" attributes debug. We do NOT want the resulting published site to run as debug mode, so we "remove" the "debug" from that part of the configuration file.

So, the transform concept is nice, since often just a FEW things like removing a few attributes here and there, adding a few, and then replacing some other settings is all you require. Hence, the web release config file often has few changes, since most everything else remains the same as it should.

So, after solving your question (where does/did the password and server settings change)?

The problem is the above system ONLY supports 2 sets of settings. (my debug, local development, and then publish to production server).

What the above system DOES NOT support is say a 3rd option! (such as QA). And BOY do I wish it did!!!

And I also have a internal QA server that we test/try things out before release to the production server.

So, from local dev (debug), and to production?

The above system of "transforms" on the web.config works great.

However, what do we do for the QA build?

Well we created a published site, and then made a copy of that final web config, and edit/changed it for the QA server. We then save a copy of that web.config

So, to publish to QA, we use the release publish. We then delete web.config, and then over write (copy) with our "saved" QA web.config, and that's deployed to QA.

Now, over the years, it VERY possible I missed along the way that you can have more then just 2 configs at publish time (debug, and release). However, I'm not aware of such a feature.

So, how to handle the QA server? We made a copy of the final web.config of publish, edit it for our needs and saved a copy. At publish to QA server, we thus have a extra step to delete existing web.config, and copy the QA one we saved to that QA server. It not difficult to have this extra step, but it is a bit of a pain, since if we do make changes to web.config, we have to remember to transfer over to the QA web config. Not ideal, but it is what we do.