I have a collection of web service and sites all installed on the same machine which share settings so I have put them in an external config file one folder above the application folders such as below.
<appSettings file="../common.config"/>
I see that with Config Transforms I can change individual values within this section had my settings been inside the appSettings block but is it possible to change the file attribute itself?
<appSettings file="../common_release.config"/>
or
The config transforms are actually applied by Visual Studio upon building a deployment package; so there is no *_release* or *_debug* version in the output.
Of course, you could use what ever files you want for external configuration.
Related
In my solution, there's a single appSettings.config file which is shared by a number of projects. It's referenced in the config files of those projects like this:
<appSettings file="appSettings.config" />
And that's all fine.
The individual config files also have Debug and Release configurations that I can use to control things like connection strings when I publish from local to live and that's also fine.
However, most of the key settings I want to change aren't in the project config files: they're in that appSettings file.
I could have two appSettings files in my solution and have the Debug > Release configuration change which one is referenced when the solution is published, but that seems a little clumsy - most of the settings are the same.
Right-clicking on the appSettings.config file doesn't give me an "add config transforms" option, so I'm guessing I can't have a Debug/Release transformation of that file itself.
Is there any other way to go about this other than replacing the whole file on publish?
I'm part of a large developmentteam with a big project that is built with TFS 2013. We have gotten the build to work with automatic tests and web transformations as well as deployment to correct folders. The last part we need is a way to copy additional files to the drop location with regards to different environment.
We have a folder in the solution that contains several deployment files for different environments. We build for several environment with each build.
The folder looks like the following:
A folder named contains several powershell scriptfiles
(Deploy.ps1, RunDeploy.ps1, StartService.ps1)
The first file should be copied to the root of the drop folder location for each configuration/environment.
The last two files should be copied to a new folder named Deploy under each configuration in the drop folder.
Additional to this we have several settings files in the same sourcefolder. One file for each environment named settings-.txt
These files should be copied to the Deploy folder for the correct configuration under the drop location.
We are using TFS 2013 so preferable using a custom workflow but we can use a target-file if needed.
Any idea how this can be created?
Where should I start?
I have been unable to locate a variable in a custom task in the build process that contains the location of the dropfolder for each configuration.
I managed to create a custom task in the build template after some searching for the variables I finally could create a custom task that created the correct folders and located the files that needed to be brought along in the build.
To find the variables I used the common task GetEnvironmentVariable with the specified variables. To see what each variable contained I added a print line just afterwards and tried the build and then when I had found the needed sources of information the task to create a custom build task was fairly easy.
Using websphere 8.5. I am trying to use Monitored Directory deployment and use a deployment properties file using this guide
I have enabled the monitored deploy in the global settings. I have also extracted the properties file using wsadmin and verified that it contains the correct configuration (eg. path to a shared library).
I have put the myconfig.properties file in:
C:\websphere\myserver\monitoredDeployableApps\deploymentProperties
I then drag my application test-ear-app.ear (an ear file containing a war file) into:
C:\websphere\myserver\monitoredDeployableApps\servers\my_server
As a result the app is automatically loaded but the myconfig.properties is NOT loaded and hence I need to manually specify the shared library afterwards.
Any ideas why the myconfig.properties is not loaded?
Actually when you deploy using property file you don't drag ear to monitored directory, but just the property file. So in your case you should just drag myconfig.properties to the monitoredDeployableApps/deploymentProperties directory. In your config file you have to define location of your ear by EarFileLocation=/temp/yourApp.ear it will be automatically loaded and installed in proper scope defined by the TargetServer/TargetServer/TargetCluster properties.
See detailed description in page Installing enterprise application files by adding properties files to a monitored directory
As I read, I think the procedure is the opposite of what you were currently doing : drop the Ear first and then start the install process with the props file.
I have a Windows.Forms client that is packaged as MSI by using a Visual Studio Deployment Project.
My app.config has some configuration properties whose values must be replaced by the correct ones depending on the environment I want to deploy the client into.
For instance, my client do connect to a set of COM+ services that are behind a WCF facade, so I have some URLs in the configuration file that vary depending on the environment (development, integration, etc etc).
In such way one can find in the application config line like this:
<add ServiceName="MyService" ServiceEndpoint="$(WS_URL)/MyService.svc" MaxMessageSize="xxxxxx"></add>
Well, the thing is that I need to execute a batch file (.bat) to load some variables and then replace the variables in the app.config, but, I need to do the replacements in the application configuration file that is being packaged in the MSI, and not perform the replacement in the "original" configuration file that is in the client project.
In fact what I would need is just to get the path, of the application configuration file, that VS is about to package, and pass the file-path to my script so that it does the replacements.
NOTE: In the above sample line $(WS_URL) is the variable that must be replaced by its correct value depending on the deployment environment configuration.
I would create 2 copies of your App.Config in source control and associate one with your project for F5 builds / dev debugging and another one that gets consumed by the installer for production use.
Finally I have the solution that fit our needs. My need was mainly to just have one unique configuration file for the Windows.Forms client and being able to replace some property values in it, just before the file is packaged in the MSI.
I thought the binaries that are packaged within the MSI were taken from the project(s) output dir., but they are not, so I couldn't use that location to execute our "variable replacer" script and get the final App.config file ready to be packaged.
We a have a .bat file, one for each kind of environment configuration, in which we centralize the configuration properties applying for Windows.Forms, Web-Applications, COM+ Serviced Components, so I was disgusted with the idea of replicating the configuration file of the client, because my aim is also to reduce the number of configuration files, to reduce the risk of making a mistake, while keeping the process of creating/maintaining build environments easy.
I couldn't find any doc to tell me how could I get the path, of the temporal folder or whatever, where the files are, just before the MSI is being packaged. If I would have access to it, then I would have executed our "variable replacer" script pointing to that directory and problem solved.
My workaround was to place a customized pre-build event, so that the I copy the "template" App.config to the project directory, and once it is there, I run the script to replace the property values.
Now, every time the deployment project is built, we are sure it contains a valid configuration file.
Just FYI, here is how the pre-build event looks like:
XCOPY /Y $(ProjectDir)config\*.* $(ProjectDir)
CALL ..\ScriptsCentral\do_apply_config.bat $(ProjectDir)App.config etc
EXIT 0
NOTE: I had to put the EXIT 0 explicitly because we build all the projects with msbuild and devenv.com and I got the build process stopped in the part where it executes the build event.
(thanks #ChristopherPainter for your time and comments. +1 for your proposal)
I'm working in a solution which includes a windows service host project that uses a single app.config file which contains everything the service needs (logging configuration, WCF configuration, custom configuration, and, connection strings).
The way I actually work is when a user complains about something wrong in the production environnement, I edit the app.config file, modify the connection string so it points to the production database, recompile the service host project, then run the application in my dev environnment to see what's going on.
If I have to test things that would be too risky for the production environment, I edit again the app.config file, modify the app.config file so it points to the test database, recompile the service host project, ... you see where I'm going ...
To avoid the burden of editing the app.config file everytime I have to switch environments, I decided to create a "Production" build configuration and a "Test" build configuration. I added two additionnal config files, one for each environment, which are replicas of the main app.config file except that their connection string points to their respective database. I modified the pre-build event of the project to include code that copies the environment's app.config file depending of the selected build configuration.
I have two concerns about that method :
If I have anything else to modify in the app.config file (WCF, logging, etc.) I have to remember to replicate my modification in the other file. (Big problem for me as I have as much memory as a red fish)
I hate making the project more complex to work with because of the additional build events, additional files in the project directory, etc.
Each build configuration outputs in a different directory. I hate having duplicates of the same code just to overcome that data source issue.
Anybody can suggest a simpler way to work with multiple environments ?
Thanks in advance.