I have a transform for my web.config that currently works if I publish to Azure, but it's not working locally when I build/run. How can I go about "Publishing" locally so the Local transformations are applied to my web.config on my dev box?
Currently I right-click > publish to Azure, do I need to create a new publish profile for my local box? Is there any way to get the transforms to work on Build instead?
It depends on which dev server you are using. As #Citronas said on this answer:
It depends on how you debug. If you are using Cassini, afaik your
web.config contents will be read regardless of the selected solution
configuration (e.g. Debug or Release).
If you are debugging with your
local IIS, it depends on what you have set the path in the IIS to. If
you have set it to your source code directory, you need to write your
local settings into your web.config. If you publish your code into a
local directory and set the IIS path accordingly, you can use
web.config transforms. (You said, that your web.config transforms are
working)
You do not need to publish locally (even though you can do that, publish to local IIS then attach the debugger to the worker process of the application pool) since it is annoying. The easiest way is to simple have your debug settings in the web.config file and then apply transforms for your "publishable" environments.
In short: do not use transforms for debug, only for publishing. Use the regular web.config to debug.
Related
I have a Blazor Server app that is running under IIS. I see that it generates a web.config file upon publish with some settings in it.
I need to add some more settings to the web.config as they are used by another component (asp.net 4 app). Does anyone know which file I need to create/modify in order to be able to add these values.
At this stage I do not need to use transforms on the web.config, but it would be nice to know this as well.
What I found is that the web.config works as per Asp.Net Core documentation. In brief for a Blazor server app hosted under IIS (this is my understanding)
If there is no web.config existing in the root of the project directory, one is created during the build and copied to the bin directory. It will contain default information.
If a web.config exists in the root of the project directory, it is copied to the bin folder unmodified (note: it requires some default settings inside).
If transforms exist, they will be applied.
I didn't realise that the web.config is created if it did not exist hence my original question.
Also, I have not been able to get transforms to work yet.
I found that if you publish the project the web.config in the root gets ignored and uses the auto-generated one.
Adding this to my blazor project file solved it and can see the web.config getting published to Azure now:
<PropertyGroup>
<PublishIISAssets>true</PublishIISAssets>
For my Play 2.2/Scala application (built with SBT), I would like to deploy different configuration files depending on the environment I'm deploying to (e.g. to couple a deployment with a particular database server). How does one create different variants of the application's configuration file (conf/application.conf) for different deployment targets? Hopefully variants can be generated from a base version?
What I'm used to from .NET is to have a base configuration file (Web.config), which undergoes a certain transformation depending on the profile one is deploying (e.g. Production). Does one use a similar technique in the Play/Scala world?
Alternative configuration files are covered in Play's documentation quite well in section Specifying alternative configuration file.
In short - in application.conf you place default configuration of your app, and additionally you need to create additional files for you environment(s) ie. life.conf, dev.conf etc. In these files you first need to include application.conf (which will read whole default configuration) and next just overwrite only parts which have to be changed - ie. DB credentials, it could be dev.conf:
include "application.conf"
db.default.driver=org.h2.Driver
db.default.url="jdbc:h2:mem:alternative-database-for-dev-testing"
db.default.user=developer
db.default.password="developerpass"
So finally you start your application (after dist) as
./start -Dconfig.resource=dev.conf
or with the Play console
play -Dconfig.resource=dev.conf run
Several tips:
It's good idea to do not place your 'life' DB credentials in default application.conf file, if some dev will forget to include his dev.conf he won't damage the production DB, instead you should put it in prod.conf.
Also these additional configs shouldn't be placed in any VCS (ie. git) repository - creating them directly on target machine (and ignoring in repository) give you sure, that people who shouldn't know the life database credentials won't see it.
It's also possible to use remote alternative config file, which can be useful ie. when you deploying several instances of the same app ie. on several hosts in the cloud.
Each dev can has own config file ie dev_aknuds1.conf, dev_biesior.conf etc, so you can ignore them with one pattern dev_*.conf in repo.
Finally you can just create a shell script (unix) or bat file (Windows) to start using choosen config file like start_dev.sh, run_dev.sh etc. so you won't need to write -Dconfig.resource=... each time
We've started using TFS2010 over at the company I work at. We create e-commerce web applications (shopping sites). I'm creating a custom template to deploy web projects after a build using a build template.
I've looked at the web deploy tool, but MSDN seems to indicate that it can only do initial deployments, and I need to be able to do incremental deployments with the same script.
I'm thinking of using the invokeActivity activity in the template to use powershell to do the job by specifying an FTP script which automatically copies the output of a build to a designated FTP site and then runs the SQL (upgrade) scripts, if needed by using SSH or s powershell remoting interactive session. (possibly specified in a separate SQL script)
There is some unknown for me which I can't get clear through the use of google:
When queuing a build, will I be able to let the user specify a script present in source control ( e.g. $(source)\scripts\ftpscript.ps1 ) as the script which is to be used? Will powershell be able to access/use that file? or should I copy it to the build directory and specify when I run it? (I don't know how to set up the template to get files from source control, so a pointer to some helpful info how to do that would be very much appreciated)
If the previous just doesn't work at all, could I create a folder \scripts\ in my website project, commit that to source control and then use BuildDetail.DropLocationRoot & "\scripts\" as the location for the script and fore a copy of the script files by enabling the force copy option?
To run a PowerShell script I think you can use the InvokeProcess activity which would trigger something like this:
%windir%\system32\windowspowershell\v1.0\powershell.exe "$(SolutionRoot)\test.ps1
And yes, you can reach a script file present in source control using the "SourcesDirectory" keyword.
I'm using NAnt to build an ASP.NET MVC project.
The NAnt script then creates a zip package, containing a deploy script and all the necessary files.
The deploy script backs up the current running website, sets up the newer version of the website and updates the DB.
This works fine for a single environment.
However, we're asked more and more to set up a Staging/Acceptance environment next to the production. These environments, of course, differ in file structure, DB server, config settings etc.
How can I best handle this in the deploy scripts? I don't want to create separate variables for each environment, distinguishable by name only.
Providing defaults and providing the variables in separate files seems more logical.
Does anyone have practical experiences with this?
Store the things that you think are likely to change between environments in config files.
Visual Studio can do the heavy lifting here if you like; you can create settings and specify default values from the Settings tab of a Visual Studio project's properties.
This will create the config file for you and provide strongly-typed access through Properties.Settings.Default.
As for handling multiple environments through your build, I've seen some people recommend maintaining multiple copies of the config files - one for each environment for example - and others recommend using nant to modify the config files during the build or deployment phase. You can use a property passed to nant on the command line (for example) to select which environment you are building (or deploying, depending on how you're doing it).
I don't recommend either of these approaches because:
They both require changes to your build to support new environments.
If you change a setting in a deployed environment and forget to update the build then the next deployment will reset the change (somewhat defeating the point of config settings).
If someone creates a new environment (lets say they want to explore issues arising from upgrading to a new version of SQL Server for example) and doesn't fancy creating all new config files in the build system, they might decide to just use an existing environment's settings. Let's say they choose to deploy using the live settings and forget to change something afterwards. Your new 'test' environment could now be pointing to live kit.
I create a copy of each config file (called web.config.example, for example) and comment out the settings within them (unless they have meaningful defaults). I check these in and have those deployed instead of the real web.config (that is, web.config is NOT deployed automatically. web.config.example is deployed as web.config.example.
The admin of the new environment will have to copy and rename the file to web.config and provide meaningful values). I also put all the calls to the settings behind my own wrapper class - if a mandatory setting is missing I throw an exception.
The build and my environments no longer depend on each other - one build can be deployed to any environment.
If a setting is missing (a new environment or a new setting in an existing environment) then you get a nice clear exception raised to tell the admin what to do.
Existing settings are not altered after an upgrade because only the .example files were updated. It's an admin task to compare the current settings with the latest example and revise if necessary.
To configure the deployment, you could put all the environmental settings (install paths, etc) into nant properties and move them into a separate file (settings.build for example) then use the nant include task to include that file at the top of your deployment file (deploy.build for example). You can then deploy a new version of deploy.build without overwriting your config changes as they are in settings.build. If a new property is introduced into deploy.build nant will fail with a nice message to tell you that you haven't set that property.
I am developing a logging framework using Log4j. I am not able to figure out how to maintain separate log files for different environment, i.e., development, testing, staging and production.
Firstly you'll need a different copy of your log4j.xml for each environment.
Lets call it log4j-dev.xml, log4j-test.xml, log4j-stage.xml and log4j-prod.xml each having their own settings like log file name and log levels.
You then pass in the corresponding file at the the server startup as a system property like below -
-Dlog4j.configuration=log4j-dev.xml
This URL has the example on how to pass this for Tomcat. The concept is the same for whichever server you are deploying on.
On Windows, I have used "set CATALINA_OPTS=-Dlog4j.configurationFile=log4j2-dev.xml" instead of log4j.configuration