I am trying to improve the development and deployment experience in our company by trying to limit the overhead in using multiple environments. We currently have 3 environments: Debug, Test, Release. This means I have multiple configuration files: web.Debug.config, web.Test.config, web.Release.config.
We are using NuGet packages to deploy the internally developed libraries. The library itself is responsible for the configuration values it uses. This is easily done with NuGet transformation files. Thus, when adding a package to a project, the correct environment transformation file is applied to the correct .config file. Using SlowCheetah and some manual modifications to the csproj file, this works quite well. When switching the build configuration during development, the correct .config file is used; when creating a deployment package it also uses the correct .config file.
The problem arises when I want to use a parameters.xml file to allow the release manager to change the configuration values when deploying. (How to: Use Web Deploy Parameters in a Web Deployment Package) He sometimes wants to set up a separate environment to do be able to test certain things, whilst not disturbing the existing test environment.
In theory, the use of a parameters file is the perfect solution. In reality it seems the parameters file is not capable of using the configuration values from the corresponding configuration file when no values are passed. This means that, when we provide a parameters file, we must define the actual default values for each possible replacement value. And of course, this complicates things as their is only one parameters file for all configurations. Always specifying every configuration value when deploying is also not preferred, because this means that, when a configuration value changes, we must change it in two places: the NuGet package and the deployment script which deploys to the default environments.
What would be the easiest way to solve our problem? How can we tell the web deploy wizard to use the default values from the .config file generated when creating the deployment package if no value is filled in?
I have been struggling with this issue as well, The best solution I can come up with is to add parameters via the .pubxml files for each deployment, this means a duplication of efforts unfortunately(Surely someone has a better approach?)
Related
I am trying to understand how the appsettings.json and appsettings.{Environment}.json and the environment variables play along in a dotnet core 2.1 application but I don't know how at runtime the appsettings (whatever the final transformation is) are accessed by the application.
I would expect to have the appsettings among the compiled dll (e.g: MyWebApiApp\bin\Debug\netcoreapp2.1), but I don't see it there.
Understanding this would help me find out the best approach for OpenShift configmaps vs appsettings, because I need to know whether I should rely on appsettings at runtime or whether appsettings is something useful for development but on production I should rely on environment variables rather.
Thanks!
Are you running the code from within Visual Studio? The default CreateDefaultBuilder uses the Directory.GetCurrentDirectory() to determine which folder to load the settings files from. When you are running from within Visual Studio the current directory is your project directory - so when you run/debug the program it finds the correct settings file.
One way to test this is to change to a command line and run your applications using dotnet myapp.dll. If you are loading settings from an appsettings file it will not find the file and the settings will be null.
If you change the properties on your appsettings file to copy if newer and rebuild your app, when you run it from the command line it will correctly find the settings file.
You can take a look at the how the webhost determines which settings to use by looking at the implementation file. But, in short, dotnetcore will use settings in the following order:
appsettings.json
environment variables
command line
The documentation for this is here
So, if there are settings that could change once the app is deployed then you can overwrite them via environment variables. You could redeploy the appsettings files if you want to configure that way but, from my experience, it is much easier to handle production settings via environment variables, possibly using a third party tool e.g. puppet.
Hope that helps.
I have several Azure deployment slots: dev, staging, production, etc.
I want to create a set of web.config files, one for each deployment slot. So web-dev.config, web-staging.config, etc.
I do not want to use the slot-specific settings in Azure because if you have more than one or two settings it seems vastly easier to just have all your settings in a text file.
I do not want to write XML transforms on a single web.config file because that is insane. Config files already have enough complexity without an extra layer of indirection. And even if I didn't think that, web.config transforms seem to be tied to build configuration and not to a deployment destination. I don't want to contort my build process for the benefit of my deploy process.
I know copying and pasting config settings across files is gross but here we are. Until someone at MS fixes configuration in ASP.net, I just want to have one file for each deployment destination and call it a day.
How do I do it?
You have a few options.
The most obvious is the transformations. I don't know why you're so quick to discount it: only a few settings should be changing between environments, right?
Or you can have multiple .config files and then make it part of your deployment script (I hope you're not just using VS to deploy). Your scripts can select the correct file and rename it to web.config.
And of course, you can move all the app settings and connection string stuff, and probably more, out of the web.config file and use alternative configuration systems. Perhaps a giant XML or JSON file with all the settings for each environment in it. Or perhaps use environment variables.
Really, it's up to you to write your deployment scripts and set your configuration up how you want it. It's not "up to Microsoft", it's up to you, though they have made it even easier to use a common configuration system across multiple sources in ASP.NET 5.
I'm maintaining a webforms application for several different clients in Visual Studio 2008. Each client has their own separate web.config file. We are using config transformation when deploying which works great.
There are many developers currently working on this project, and while developing each developer needs to have the configuration values for a specific client. Right now, what we are doing is that each one of us, has their own version of web.config locally, and we just try to be careful not to check in the web.config file.
This approach of course has several drawbacks. We need to do this manually, which is annoying, we need to be really careful not to check in the config files since it could cause trouble for the rest of the developers, it's cumbersome to add a new value to the config, etc.
I'd like to transform the config files when building from visual studio, so we can chose which file to take the configuration values from, without having to manually edit web.config.
I've been looking in the web for a while, but the best thing i found so far is this:
http://www.codeproject.com/Articles/399002/Project-Build-Web-config-transformation
Which is not working for me, it gives me a build error saying it can't copy Web.config_output because the file is missing.
By default tools like SlowCheetah and other config transform technologies use the $(Configuration) to figure out the name of the transformation to apply. You could take the slowcheetah.targets file and edit it to take $(username) which will pick up the standard windows logged on user name if you're building inside visual studio. You could use a condition to apply the change specifically when '$(BuildingInsideVisualStudio)'='true'.
This will require you to do some work with MsBuild target files, but the end result would be that your developers can check in a web.jesse.houwing.config (in my case) and that of that file is there, their transformation will be applied instead of the standard release or debug transformation.
As for a good starting point, look at SlowCheetah.
I'm wanting to know how to perform the following
Build & package an ASP.NET website to the file system
Be able to deploy the website to one or more environments. I want to the transforms of config file to happen at the point of deployment, rather than at the point of building. This way my code is not recompiled for each deployment and there is not risk of new changes being introduced.
From my own reading I'm unsure of how to do this. WebDeploy seems to package, transform and deploy based on a configuration but Im unsure how these steps can be decoupled to avoid the need to recompile code from source control.
Does anyone have any experience in solving this issue?
You can use the Parameterization feature of web deploy a.k.a MSDeploy. You will need to use a parameters.xml file and a setParameters.xml file to dynamically swap out settings since you are not transforming your package at build time.
At deployment time you can pass in any .xml file to set the parameters you have specified in the parameters.xml file. Since the parameters.xml is at the root of your project solution (e.g see example link of where to place the file) then at build time it gets baked into your web package. However, you now have the flexibility to change those values by passing in the setParms .xml file from the command line during deployment. This is different than transforming the values during build time based on configuration settings.
Here is a msdeploy command line example of passing in a ParamFile for a staging environment.
msdeploy -verb:sync -source:package="c:\packages\mypackage.zip" -dest:auto,computername=StagingServer1 -setParamFile="c:\StagingParameters.xml"
See the below links for examples and MSDN technical information:
Web Deploy Parameterization in Action
Parameterization vs. Web.Config Transformation
Web Deploy Operation Settings
Similar question on stackoverflow that provides several methods
I'm trying to learn/use the Enterprise Library 5.0 Configuration tool and it seems like it would work perfectly with a few minor exceptions. The problem I am currently having is when it comes to working with different environments. We have 3 environments for one of our web sites, so I can create the 3 different environments within the configuration tool and I can set up the delta files and which properties to overwrite and when.
All is well until I Export Merged Environment Configuration File. When I do this, it creates the file as intended, however it changes the Environment Configuration File field to now include the absolute path.
Also, the delta file now contains a reference to the absolute path.
We use source control (VSTS) - so absolute paths are no good. Our build process consists of creating branches and then merging the code back into a root. We can't have absolute paths when the branches are created by different team members having their code in a different local folder structure.
Is there any way to stop the absolute path from automatically being added? Or any other suggestions?
My research indicates that there does not seem to be a way to make the GUI tool not override the Environment Configuration File value. The solution I am going with is to use the command line tool provided when installing the Enterprise Library. The command line tool is MergeConfiguration.exe.