I use ConfigSource=localfile to keep my connectionstrings in a separate file on the productiton server. This works great.
But if you use IIS7 Manager to edit connectionstrings on the server, the strings end up back in the web.config. Subsequent deployments then trash those edits when the new web.config arrives.
II7, if it edits your connection (or appsettings) strings, should put them back in the file from whence they came.
no?
Indeed, it even seems that somewhere in this sequence the original localfile gets truncated (to just the header line in an xml file) ... which then errors out after the next deployment.
Related
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
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.
I have a config file linked from web.config e.g.
<features configSource="feature.config" />
When I make changes to the "feature.config" file the IIS application appears to restart, is this expected behaviour?
Yes, this is expected behaviour by default as typically any changes made to the web.config will cause an application restart however this can be overridden for app.config files. From the msdn:
Saving a Web.config file restarts the
application. You can alternatively use
the configSource attribute of
individual section elements to point
to a secondary configuration file that
does not cause an application restart
when it is changed.
Although you have moved some of your configurations into a linked config file they are still effectively part of your web.config file and any changes made there will have the same effect as if you made the change directly in the web.config file itself. However you can specify a section to not restart the application on change by using the restartOnExternalChanges attribute in the section definition. See here and here for further details. However, according to the documentation this is not valid for ASP.NET applications which makes the above statement a little misleading.
Here is what I have tried:
Change the directory in which the temp files are stored. (Changed locally to each website).
Store the XMLSerialization object in a global variable and use that instead of creating a new one each time.
Delete all temp files in the windows temp folder.
Set permissions on the windows\temp folder (I have them set to everyone at the moment just to try and resolve the issue).
My Setup is as follows:
IIS7 on windows 2008 dedicated server.
The website is written in ASP.NET using Delphi.
I have several XML files that need serializing so not just one.
My website talks to the web service and processes the XML (I am guessing this is the part that is breaking everything)
Does anyone have any suggestions other than what is listed? I have read about using SGEN to pre-compile the serialization object but will this work for more than one XML file? I don't really know much about it.
Here is an example:
This is the code for one of my XML files. StockXMLSer is held globally and after testing is only created once per site.
function IntGetSTOCK_ITEMS(S: TStream): STOCK_ITEMS;
begin
if not Assigned(StockXMLSer) then begin
StockXMLSer := XmlSerializer.Create(STOCK_ITEMS.ClassInfo);
OutputDebugString('StockXMLSer Serializer Created');
end;
Result := STOCK_ITEMS(StockXMLSer.Deserialize(S));
end;
You will need to add some settings to your code in order to be able debug your serialization code. Please consult the following article on msdn.
Troubleshooting Common Problems with the XmlSerializer
Also there is a neat trick there that will keep the files created in your temp folder so you can see what is happening.
Under normal circumstances, the
XmlSerializer deletes the C# source
files for the serialization classes
when they are no longer needed. There
is an undocumented diagnostics switch,
however, which will instruct the
XmlSerializer deletes to leave these
files on your disk. You can set the
switch in your application's .config
file:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.diagnostics>
<switches>
<add name="XmlSerialization.Compilation" value="4" />
</switches>
</system.diagnostics>
</configuration>
With this switch present in the
.config file, the C# source files stay
in your temp directory. If you are
working on a computer running Windows
2000 or later, the default location
for the temp directory is \Documents and Settings\\LocalSettings\Temp or
\Temp, for web
applications running under the ASPNET
account. The C# files are easy to miss
because they have very odd looking,
randomly generated filenames,
something like: bdz6lq-t.0.cs. The
XmlSerializerPreCompiler sets this
diagnostics switch, so you can open
the files to inspect the lines on
which the XmlSerializerPreCompiler
reported compilation errors in Notepad
or Visual Studio.
Just for the record, I had an error similar to this one and found the solution from this blog
After setting the permissions on the TEMP folder, the functionality that the error had started to work again.
XML Serialization creates a temporary DLL with the serialization code in it, somewhere in the temp directory. This is loaded into your App Domain when the serializer is created. It's possible that you are deleting this DLL when you clear the Temp directory, and for some reason, it's not getting regenerated correctly.
Why do we store connection strings in web.config file? What are the benefits of doing so?
The web config file is used so you can reference the connection anywhere in your app. It avoids having to deal with a fairly long connection string within your application.
Here is a good article which may give you detailed information: http://articles.sitepoint.com/article/web-config-file-demystified#
There is even a wiki page for it :) (surprisingly):
http://en.wikipedia.org/wiki/Web.config
If you ever move / change to a different database format the connection string setting inside of the web.config file can be changed in one place rather then digging through your entire application looking for it. This also avoids having to recompile or build an application to get the new connection string setting.
If you are wondering how to access the information from within a web.config file that can be found here:
http://msdn.microsoft.com/en-us/library/4c2kcht0(VS.85).aspx
There is also sample code right in there.
Imagine you have several classes which access your database; you can:
Place your connection string in every class
Create a constant to store that value
Place it inside your configuration file and to refer it
These have following characteristics:
Every time a connection string changes, for instance, migrating from development to production environment, you'll need to change everywhere;
By using a constant, you just need to change a single place. But in this case, when your string needs to be changed, you'll need to recompile it.
Same as above, without that recompile part. You can to develop your application and other people set that database connection to you
So, by storing a connection string into your web.config file you gain more flexibility to change that setting than other alternatives.
Reason #1
As everyone is mentioning, having the connection string in the web.config makes it easy to update/change as needed. It becomes a single source where the arguments can be easily be changed.
Reason #2
Beyond that though, IIS is configured not serve up web.config to users who request the file. If your website is,
www.mydomain.com
someone can't hit http://www.mydomain.com/web.config and scrape all your confidential settings, passwords, and so forth.
(As a side, note, IIS won't serve up files in the App_Code directory either to a user, so the web.config file isn't unique in this respect.)
Reason #3
ASP.NET automatically detects changes to configuration files and will immediately applies new settings.
More info..
MSDN has a discussion of the ASP.NET configuration system at,
http://msdn.microsoft.com/en-us/library/aa719558%28VS.71%29.aspx
What I like most about having the connection string in the web.config is when you have multiple environments that you test on. Say you have a Test server, Staging server and a Production server. Well you don't need to have code that checks which server you're on, or have to recompile different versions for each... just use the web.config to store your connection strings and that way you can have a different web.config on each server but the same web application with no hassles. You may want to Encrypt your Connection String Settings as well so they're not visible to everyone that has access to the folder.
You can reference them using the ConfigurationManager via the ConnectionStrings property.
http://msdn.microsoft.com/en-us/library/system.configuration.configurationmanager.connectionstrings.aspx
It allows the connection string to be configured by someone maintaining the site.
You don't have to re-build the application if the connection string changes. An admin can make the change and the code remains the same.