Develop Reference

Deployment plan for .net core application along with environment variables

I am currently working on .net core web application deployment in multiple environment - Testing, UAT, PROD, etc.
As per documentations says, we should have environment specific appsettings.{environment}.json files so when we deploy application onto specific environment, respective file will be used.
I believe we use IIS -> configuration Editor to set ASPNETCORE_ENVIRONMENT variable.
However, I am unable to find, how can we do this thru deployment plan without going onto server.
Currently I am using Octopus deployment tool.
Any idea?

I think you need to store environment specific settings in Octopus Deploy (in scoped variables) rather than in your .json files which will
- or should even - be under source control.
Say your appsettings.json looks like this
{
"weatherApiUrl": "dev.weather.com",
"weatherApiKey": "DEV1234567",
"tempImageFolder": "C:\temp\img"
}
In your Project Variables you specify the weatherApiUrl variable and set it to dev.weather.com scoped to Development, test.weather.com scoped to Test, etc.
In your Process, in the Deploy step, goto Configure Features and enable JSON configuration variables. Now the Deploy step will have an extra section named JSON configuration variables, specify the name of your config file there, appsettings.json and off you go.
More information here: JSON Configuration Variables Feature

web.config not app.config being published to xxx.dll.config in Visual Studio 2015

I have an ASP.NET project that outputs a class library as a dll which is then deployed to IIS. Per standard builds a config file is also output along with the dll as xxx.dll.config and it contains many useful environment variables such as connection strings (i.e. it conforms to the application settings architecture requirements).
In VS 2012 the contents of xxx.dll.config file were sourced from app.config in the project root directory.
In VS 2015 it appears xxx.dll.config's contents are instead sourced from web.config in the project root directory.
Steps to reproduce:
Create a ASP.NET application with VS2015.
Add a app.config file in this application.
Build this application.
Open the bin folder and find the application.dll.config file and open it. The content is the same with Web.config.
Do the same operations from Step 1 to Step 4 in Visual Studio 2012, the content is the same with App.config.
This is causing me a bit of a headache as I was relying on app.config to hold variables (connection strings, auth providers) for my functional tests while web.config held variables for deployed code.
Most of the reading I've done on AppDomains and their configuration variables seems to indicate that web.config shouldn't factor into the build output unless explicitly instructed and even then it isn't exactly easy to transform a web.config file, nevermind have it end up as the xxx.dll.config file.
I could rework my test fixtures to set the environment variables directly from the tests but for things like ASP.Identity that requires writing quite a few new classes to load a RoleManager and associated providers which I'd like to avoid.
If anyone could suggest how to engineer the VS build to output a config file that is easily used by the assembly AND the nunit tests when run via the nunit runner or Resharper that would be awesome.

To restore the original behaviour of Visual Studio 2015 back to what I was accustomed to in Visual Studio 2012 I added a post build event:
Go to Project-> Properties
Select Build Events
Add the following to the "Post-build event command line" :
copy /Y "$(ProjectDir)\App.config" "$(TargetDir)\$(TargetName).dll.config"
The .dll.config is now once again the App.config instead of Web.config

Easiest way to make web.config transforms for deployment?

Anyone have a preferred method for making web.config transforms? I am curious as to what others have done for this. I hate having to continuously update the web.config every time I update or republish.

A few years ago Scott Hanselman gave a solution using pre-build events and batch files:
http://www.hanselman.com/blog/ManagingMultipleConfigurationFileEnvironmentsWithPreBuildEvents.aspx
Basically you maintain a separate different configuration for each build and run the batch script pre-build to copy over the Web.Config. The obvious disadvantage is that if you have thirty different build configurations you need thirty different configs, but I find it's nice for projects where you only have two or three configs (like hobby projects, or tools you'll only ever be publishing to internal servers). Plus, it's nice knowing that if you want to you can take extra control of the build process if you want to.

The easiest way to use VS built in support:
You have versions of web.config, for your build versions, (by default Debug and Release)
In the release version you can define transforms what are applied during build. The effective web.config will be the result.

Look into the nuget package for slow cheetah: https://www.nuget.org/packages/SlowCheetah/ This does what you are looking for quite nicely. Be aware that it is for publish transformations only, switching to a different config for local debugging will have no affect.

Create a build configuration for each server you want to deploy to
Example
-Dev Server "copy from debug"-
-Prod Server Debug "copy from debug"-
-Prod Server Release "copy from release"-
Then right click your web.config and select "add config transforms"
You will get new transforms for each configuration you added above.
Now configure your web config transforms for each environment.
Now when you publish you can just select the configuration "Dev, Prod Debug, or Prod Release" and out it goes, no need to update them after that.
Now, the base web.config should always be configured for your local environment, so if you set up in IIS locally it will use web.config without any transforms. Your transforms should transform your local settings in the base web.config to w/e they need to be.

Where Is This Configuration Coming From?

I am helping a team whose builds have started failing due to test failures.
The failures are being caused by missing connection string configuration. I checked the usual issues in respect of the config file to ensure that the connection string was specified with exactly the right name.
In the end I obtained the full path of the config file to check that the one on the build server contained the exact configuration that was expected.
AppDomain.CurrentDomain.SetupInformation.ConfigurationFile
The path did not point to the TestProject.exe.config file, but instead pointed to the vstest.executionengine.x86.exe.Config at the following location:
C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.executionengine.x86.exe.Config
This file contains no connection strings at all.
When I write out all of the available connection strings from configuration, I get the default connection string:
Name: LocalSqlServer Connection: data source=.\SQLEXPRESS;Integrated
Security=SSPI;AttachDBFilename=|DataDirectory|aspnetdb.mdf;User
Instance=true . Aborting test execution.
This is coming from the machine.config file (kudos petelids).
So the big question is:
Why is the vstest.executionengine.x86.exe.Config being used rather than the app.config (at runtime TestProject.exe.config)? (I can guess that this is because the process running is the test runner, but I think it is fair to say that you would expect the test runner to let the test project use its own config file, which is what normally happens).

I think it is fair to say that you would expect the test runner to let the test project use its own config file, which is what normally happens
That's perfectly true assumption when working with NUnit, xUnit, etc. but not with Microsoft Test Runners (MSTest and VSTest). They simply ignore target assembly config file and use their own config.
There are two solution to this problem:
Change MSTest to NUnit or xUnit
Use custom config file (not the default one)

MSTest runs tests in isolated mode by default.
The solution to this issue was to add a new test project and move the tests into it.
The new project behaved like all of the other projects, running the tests in an isolated process and using the app.config file from the test project.
I'm putting this down to a quirk.

settings.settings connectionstring in development vs production

I'm using Visual Studio 2008, developing a winforms app.
I have my database connection string stored in settings.settings.
My development and production environments require different database login credentials and right now I'm manually changing the connectionstring by hand before building for the 2 different environments.
Is there a better solution?

An eternal problem! :-)
Basically, right now, Microsoft doesn't really have a good answer for this.
What I would do is have both connection strings in my settings file, under two separate names, and then have a config setting in app.config which tells me which one to use:
MyDatabaseDEV = server=(local);database=mydatabase;-........
MyDatabasePROD = server=ProdServer;database=MyDatabase;........
and in app.config
<appSettings>
<add key="UseDatabase" value="MyDatabaseDEV" />
</appSettings>
This setting in app.config can be tweaked in your build process, e.g. by a "after build" batch file, or an MSBuild task or something, to be switched to "MyDAtabasePROD", when you do a production (release) build.
Microsoft promises us more and more flexible tools for .NET 4.0 / Visual Studio 2010, which should be out by the end of the year 2009. You should be able to create "config transformations" - check out these blog posts:
Web Deployment: Web.Config Transformation
ASP.NET 4.0 and Visual Studio 2010 Web Development Beta 1 Overview
Visual Studio 2010: Web.config transforms
Web.config Transformations with Visual Studio 2010
Marc

Where I work this is done by creating a folder called config that holds the various configurations.
source
config
MyProject
environment1
environment2
MyProject2
environment1
environment2
When the build script is run, it grabs the correct config based on which environment you're doing the build for...

you can make form asking the user to enter the connection parameters such as server name and database..., and store those parameters in Registry, files etc...

You should add an app.config file to your winform application. In this file store the connection string under the ConnectionStrings section.
In your code, when create a connection use that connection string using ConfigurationManager class to access config file.
So when you deploy your application, you have to chance the connection string once in config file and everything runs as expected!

You can defines your connections in settings, use dev connection in debug mode else production connection with #if directive.
//affect your prod connection here
#if DEBUG
//re affect your dev connection here;
#endif
A link to explain : http://msdn.microsoft.com/fr-fr/library/4y6tbswk.aspx

Right-click on the web site in the Solution Explorer and select Add Web Deployment Project.
Whenever this new WDP project is built, it will replace all the configuration elements you specify. You can also have different versions depending on Debug or Release builds. It works for almost all of the configuration options, including the connection string. There's lots of documentation on how to configure it correctly on the net, just search for "Web Deployment Project".
This is definitely the new "default" way to do this until MS decides to make it more formal in some future version of .Net/Visual Studio, if they ever do.

I've started using a setting called TestMode="dev|prod|uat".
The problem with compilation targets is that you can't change anything after build.
With this approach you can include all the connection strings and settings you need for all the environments you want. In your code configuration provider you can switch based on this setting.
With this approach all you have to do is change the flag once deployed or use deployment software like Octopus to change it for you.
I have given up with merging .config files which is difficult and error prone.