I have a web application that we publish and provide for users to install and run on their local network. They choose whether they run it as an internet, or intranet application.
When we publish the application we label the folder with the publish date (e.g. 20140815) so we know which version they have. However, when they contact support, it is a pain for them to get on the server to see the folder information.
I want to add an appsetting for cloudVersion and display it on the license page so they can easily provide it from wherever if needed. Also, they feel better seeing the version increase so they know they are getting value with the service contract.
<add key="cloudVersion" value="20140815"/>
I would like to automate the version in the appsettings. I was hoping I could use a Web.Config transform to set it with a dynamic yyyymmdd, but can't see how to do that and have found nothing in my web search.
<appSettings>
<add key="cloudVersion" value="GETDATE()" xdt:Transform="Replace" xdt:Locator="Match(key)"/>
</appSettings>
Is this possible? If so, how? If not, is there a better approach to achieve the same result?
Short of finding a great solution for this, I have elected for the following:
After publication, I run a bat file that does the following:
copy the published directory and rename with today's date
update the Web.Config appSetting value
compress the updated directory using 7zip
upload the compressed directory to Google Drive so my support team can provide it to our users.
You can see how I modified the string here:
bat file to modify web.config setting
Related
I am trying to migrate an old aspx site that was built using GeneXus .Net Generator. Looking at the web.config I see keys with database connection information but it is encrypted
<add key="Connection-Default-User" value="******" />
<add key="Connection-Default-Password" value="*******" />
I don't know how to generate those encrypted values. Googling, the only place I saw someone referencing to those keys was this page: Web Model - .NET Generator Manual of GeneXus X.
Here is a sample value (from that page):
<add key="Connection-Default-User" value="Elj20MqY44RPdvT8FEpDD0==" />
But no details on it.
Any help on knowing how to generate those encrypted values is appreciated.
In your generated applications's bin folder, there is an utility called GxConfig.exe. When you run it, if it finds the web.config file it will modify it, otherwise it will create a new one (you may need to copy the file from your web server).
You can find more information in the GxConfig page from the Community Wiki.
Quoting that page:
In order to configure the database access parameters in production,
the Gxconfig tool is provided for each datastore.
It allows specifying a database Name, server, user password included
in the web.config file (web environment) or Client.exe.config file
(win environment and reorganization). The username and password are
encrypted in the same way as it is done in the GeneXus environment.
I've had a very frustrating experience on putting an MVC 5 app on Azure. I have been reading the following page: http://www.asp.net/identity/overview/features-api/best-practices-for-deploying-passwords-and-other-sensitive-data-to-aspnet-and-azure
But what I haven't managed to put in my head is the following:
Security Warning: Do not add your secrets .config file to your project or check it into source control. By default, Visual Studio sets the Build Action to Content, which means the file is deployed. For more information see Why don't all of the files in my project folder get deployed? Although you can use any extension for the secrets .config file, it's best to keep it .config, as config files are not served by IIS. Notice also that the AppSettingsSecrets.config file is two directory levels up from the web.config file, so it's completely out of the solution directory. By moving the file out of the solution directory, "git add *" won't add it to your repository.
And:
Security Warning: Unlike the AppSettingsSecrets.config file, the external connection strings file must be in the same directory as the root web.config file, so you'll have to take precautions to ensure you don't check it into your source repository.
The problem is the following: When I upload the Web.config file with the external files without being included I get hit by "The System cannot find the file specified", so for it to go away I must include the .config files defeating the purpose of Microsoft's post.
I really really really do not understand. I have added the connectionStrings and appSetting's keys in Azure's portal. What is the correct and secured way of putting my passwords and secrets online? What am I missing? Is it because I'm running in Debug mode?
According to this:
How can I secure passwords stored inside web.config?
There is nothing to worry about accessing the Web.config file...
But that just defies Microsoft's post.
Thanks.
I find the following technique to be the easiest way to do this.
Instead of putting the deployment values of these settings into the web.config, I keep the test values in there instead. I then put the deployment values into the Application Settings section of the Azure Website via the Azure Portal:
When the website runs, these settings will take precedence over what is in the web.config. This helps me avoid externalized files, allows me to keep sane development configuration that the team can share, and makes deployment very easy.
The best way is to set your secrets in the Connection Strings section of the portal. Any values set there will override values you specify in your web.config file.
This way they are only exposed to people who have admin access over the site itself. Having full access to the source won't even be enough to get the secret values.
More details here
I understand that I can add the following to the web.config file:
<httpRuntime maxRequestLength="10096" executionTimeout="120"/>
This will increase the upload limit for the application. The problem is that the WEB.CONFIG file is part of the application and part of my installation. I have multiple customers with different values they want to use. The Web.config file is overwritten each time they install a new version of my application. Thus, this would overwrite any modifications to the upload size they might have made.
Currently I have my customers change the Machine.Config file, but this is really not the best solution as they are changing the parameters for the whole IIS Server.
I figured maybe I could have the customer add an App.Config to the folder, where they could set their own parameters. Since that file is not part of my installation, it would stay.
Has anyone else had this problem, figured out a way to work around having the customer have an ability to have their own custom config file that will not get overwritten when they install a new version of the application?
Thanks,
Cory
In web.config:
<httpRuntime configSource="httpRuntime.config"/>
In httpRuntime.config:
<httpRuntime maxRequestLength="10096" executionTimeout="120"/>
See the configSource attribute in General Attributes Inherited by Section Elements and SectionInformation.ConfigSource Property on MSDN for an explanation.
Most of my websites include one LIVE (production) and two TEST environments which are accessible via three different domain names e.g.
www.mysite.com
test1.mysite.com
test2.mysite.com
Each of the above are IIS Websites which point to the same physical versioned folder when they are all running the same version of the website.
What I typically do when releasing a new version is to place the new version into a new physical folder e.g. /inetpub/wwwroot/mywebsite/v41/ and point one of the TEST sites to that version of the site and test it. Once passed, the LIVE (and other TEST) websites are also repointed to the new version (e.g. v41).
Now my problem is this. Each website has its own database (TESTs have a copy of LIVE which can be refreshed via a couple of SQL BACKUP/RESTORE commands) however, the three sites are all "looking" at the same web.config file and therefore the same Database Connection Strings (either a System.Data.SqlClient or System.Data.EntityClient provider).
Is there any way that I can configure web.config to provide different connectionStrings based on the domain name/IIS website of the incoming request?
Maybe a tag or an attribute that qualifies a given tag?
I've looked all over for a solution but not yet found one.
Thanks in advance,
BloodBaz
there are two ways to manage multiple environment Specific Web.config file....
using t4 template,below is the link for that
http://ilearnable.net/2010/08/02/t4-for-complex-configuration/
VS Configuration Manager and create new "LIVE", "test1", "test2" build configurations for your project,check out the link
http://weblogs.asp.net/scottgu/archive/2007/09/21/tip-trick-automating-dev-qa-staging-and-production-web-config-settings-with-vs-2005.aspx
hope this helps..
why not split your config file up so connectionStrings.config is its own file. Then you can deploy everything and not overwrite that connectionString file.
where you normally would put the connectionString do this
<connectionStrings configSource="connectionStrings.config" />
Then create a file named connectionString.config
<?xml version="1.0"?>
<connectionStrings>
</connectionStrings>
Alternatively you can create another build option other than just release/debug. You can have web.config transforms that output a different config file depending on which one is selected.
I had a similar problem; I solved it by setting up all the database connection info in the same web config file, and then writing a handler that decides on the fly, based on the request and context, which environment it's in and uses that database.
Is it possible to modify (or just replace) web.config of existing site using MSDeploy?
It's possible to replace certain sections (specified with an xPath query or regular expression) of the web config file. Use the -declareParam en -setParam commandline switches for that.
Like so
msdeploy -verb:sync -source:apphostconfig="Default Web Site" -dest:package=ParameterPackage.zip -declareParam:name=param,kind=XmlFile,scope=web.config,match=//add/#value
or so:
msdeploy -verb:sync -source:package=ParameterPackage.zip -dest:auto -setParam:name=param,value=MyDefaultWebPage.htm
You can find more info here if you're using the command line.
If your working with importing and exporting packages in and from IIS you can create a parameters.xml file. Vishal Joshi has lots of good posts about how to use msdeploy (for example this)
Yes you can do this. I just posted a blog on this at http://sedodream.com/2012/02/14/HowToUpdateASingleFileUsingWebDeployMSDeploy.aspx but I'm also copying the content below for you.
The other day I saw a question posted on StackOverflow asking if it was possible to update web.config using MSDeploy. I actually used a technique where I updated a single file in one of my previous posts at How to take your web app offline during publishing but it wasn’t called out too much. In any case I’ll show you how you can update a single file (in this case web.config) using MSDeploy.
You can use the contentPath provider to facilitate updating a single file. Using contentPath you can sync either a single file or an entire folder. You can also use IIS app paths to resolve where the file/folder resides. For example if I have a web.config file in a local folder named “C:\Data\Personal\My Repo\sayed-samples\UpdateWebConfig” and I want to update my IIS site UpdateWebCfg running in the Default Web Site on my folder I would use the command shown below.
%msdeploy% -verb:sync -source:contentPath="C:\Data\Personal\My Repo\sayed-samples\UpdateWebConfig\web.config" -dest:contentPath="Default Web Site/UpdateWebCfg/web.config"
From the command above you can see that I set the source content path to the local file and the dest content path using the IIS path {SiteName}/{AppName}/{file-path}. In this case I am updating a site running in IIS on my local machine. In order to update one that is running on a remote machine you will have to add ComputerName and possibly some other values to the –dest argument.
You can view the latest sources for this sample at my github repo.