I have one application "App1" under IIS. Inside "App1" I have another application called "App2", in IIS. They both have web.configs and each needs to read their own.
On one server configuration this is not an issue. On another, it didn't like the fact that the connection string values are in both files.
Would this indicate that the "App1" web.config is first?
Our server guys say that the configuration is the same. Has anyone see this before?
Many of the values in web.config like this are inherited. appSettings and connectionStrings are two such areas where values are inherited.
There is a syntax to remove inherited settings before adding new ones. That should be done in your connectionStrings section, to avoid collisions on what i assume are conn strings with the same name.
<remove name="connstringname"/>
<add name="connstringname" ... />
Related
I have never used Visual Studio 2017 (or previous versions) before and have been asked to work on a project that includes getting information from a sql database. I am trying to open a connection to the database using an external config and then using configSource in my App config. However when I run this code I get an error: The ConnectionString property has not been initialized. I have been doing a bit of research on this but I'm uncertain of some of VS features and syntax. First, does the ConnectionString need to be initialized in the app config or somewhere else like a module or form? Here are my app config and external config code.
External config:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<connectionStrings>
<add name="WindowsApp4.My.MySettings.TrakConnectionString"
connectionString="Data Source=Trak;Initial Catalog=Trak;User
ID=TrakMe;Password = TrakMeData;"
providerName="System.Data.SqlClient" />
</connectionStrings>
</configuration>
App config:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<connectionStrings configSource ="external_conn.config"/>
</configuration>
Thank you for any help.
To answer your question
I have always kept my connection strings in the app.config file. I can't think of a good reason to keep it in a separate file, so I would suggest moving it to app.config.
The Data Source should be the address of the server hosting the SQL database. If this is your machine you should use localhost, if it is a dedicated server you could use the server's IP address.
I don't think it could be the spaces around the equal sign for Password but I would get rid of those if only for consistency. Voodoo might be making your password " TrakMeData"
What I would do
Just let VS handle it by using Entity Framework to make the database connection. Right click in your Solution Explorer and select Add > ADO.NET Entity Data Model, enter a name and select EF Designer from database. Create a "New Connection..." and you'll have a handy dandy interface with a "Test Connection" button so you don't have to keep recompiling to see if the connection string in your app.config is correct. Here's a tutorial (that follows a different path to the same result) with pictures! You can probably skip the database creation bit as I'm assuming you already have one up somewhere.
I've tried several approaches with *.gitignore for managing connection strings when working on a larger team.
From the official repository of .gitignore files at gitignore, I've downloaded VisualStudio.gitignore and used it as a starting point for all the projects.
The same process can be done by visiting http://gitignore.io/, typing VisualStudio, then downloading the file.
The approach I currently use is by leveraging the SectionInformation.ConfigSource Property
<connectionStrings configSource="myConnectionStrings.config" />
and then adding myConnectionStrings.config to .gitignore, which is nice because it doesn't add the entire *.config.
Also you can use the same myConnectionStrings.config inside another project (your MyProject.Data layer)
<configuration>
<connectionStrings configSource="myConnectionStrings.config"/>
</configuration>
Just remember to set Copy always!
Also I've tried using filters as described at Git - Ignoring a specific modification to a config file, but I find that to be an overkill.
I wonder if there is any other approach that is considered a best practice?
I can't speak for your setup, but this is how I have tackled this problem.
Firstly, all the guys in my team use local databases with Integrated Security set as true. This means that when we check out the files from source control, it is good to go with a local setup. So my Web config file looks like this
<add name="appConnString"
connectionString="Data Source=(local);Initial Catalog=MyDatabaseName;Integrated Security=True;"
providerName="System.Data.SqlClient" />
Regarding going deploying to different environments, the first option you have is to use transforms. If you don't know what that is, read here
Since we use Octopus Deploy as our deployment tool, our transform file has the connection string for "web.release.config" like this
<add name="appConnString"
connectionString="{{appConnString}}"
xdt:Transform="Update"
xdt:Locator="Match(name)" />
When Octopus runs it's course, it grabs the web.config and overwrites the relevant sections using the release file. Then depending on which environment/machine/branch I am deploying to, it replaces the {{appConnString}} with the configuration that has been set up for that deployment.
I'm sure Visual Studio has pretty much the same process.
If you don't like the Transforms process. You can also use a parameters.xml file. msdepoy uses this file to replace values in your web.config at build. You can read up more about it here.
Another consideration is if you are hosting with Azure, you can set up certain configuration replacements on your various deployment slots all the way to production.
These are just a few techniques I have used and seen being used very effectively. Some take a bit getting used to and also a lot of frustration setting up, but having a proper deployment system will pay in the long run.
Perhaps a bit presumptuously, I hold that there is no need for a policy for adding shell globs to a file. I've never heard of "connectionStrings" before reading this question, but from what I could gather, they hold URIs / credentials for various backends.
How often does a backend change? Better yet, how often does the path of the configuration file change? Probably not often enough to warrant a policy. The only thing you need is a convention for naming the configuration files that contain these connectionStrings to easily identify them with automation tools.
So use your tools or write a script and append the foobarService.config from <connectionStrings configSource="foobarService.config" /> to the .gitignore file for all your backends.
1. Find the files.
$ find -name cs.xml
./more/configs/here/cs.xml
./cs.xml
./some/sub/folder/cs.xml
2. get config-file names
$ find -name cs.xml | xargs grep -ho '[^"]\+\.config'
getImagesService.config
users.config
ldap.config
foobar2k.config
ratpoison.config
moo.config
foo.config
trololol.config
moreconfigz.config
myConnectionStrings.config
data.config
base.config
filebackend.config
offsitewhatever.config
3. ignore them
$ find -name cs.xml | xargs grep -ho '[^"]\+\.config' >> .gitignore
4. update your CV
March 2014 - lead designer of a connectionString policy
I'm baffled that anyone would ask about advice on managing a .gitignore file. This could indicate that I don't see the big picture. Would you kindly update your question with some background information? I'm curious about why this is a meaningful question, as I'm having a hard time grasping that there is a need for establishing best practices to append a string to a file.
I am looking for "easy button", where I can say run this app under medium trust.
Yes,
As per: http://blog.mahingupta.com/mahingupta/blog/post/2010/08/01/AspNet-Set-Medium-trust-in-local.aspx
<system.web>
<trust level="Medium" />
</system.web>
Just note that most hosts do modifications to their medium trust offerings. Usually give few more permissions for LINQ and cross-server calls, but it differs from one host to another.
You can configure medium trust - just add a configuration option.
To configure an application to run with medium trust, add the following element to either the application's specific Web.config file in the application's virtual root directory or to the machine-level Web.config file.
<trust level="Medium" originUrl="" />
I've been using config transforms in VS2010 quite a bit lately but am confused as to why some transforms are applied directly to the Web.config in the package but others are stored against a token in SetParameters.xml then applied on publish.
For example, take a Web.config with the following connection string and app setting:
<connectionStrings>
<add name="AutoDeployDb" connectionString="Data Source=(local);Initial Catalog=AutoDeploy;User ID=AutoDeployUser;Password=Passw0rd"/>
</connectionStrings>
<appSettings>
<add key="ChartImageHandler" value="storage=file;timeout=20;dir=c:\TempImageFiles\;" />
</appSettings>
Then here's the corresponding config transform for the current build configuration:
<connectionStrings>
<add xdt:Transform="Replace" xdt:Locator="Match(name)" name="AutoDeployDb" connectionString="Data Source=MyDevServer;Initial Catalog=AutoDeploy;User ID=AutoDeployUser;Password=s*##Kdsl" />
</connectionStrings>
<appSettings>
<add xdt:Transform="Replace" xdt:Locator="Match(key)" key="ChartImageHandler" value="storage=file;timeout=20;dir=d:\inetpub\AutoDeploy\TempImageFiles\"/>
</appSettings>
These are both "Replace" transforms and other than one being a connection string matching on "name" and the other being an app settings matching on "key", to my eye they're identical.
Now look inside the SetParameters.xml file in the resultant package and only the connection string has a setParameter node. In the Web.config of the PackagTmp folder, the app setting transform has already been applied while the connection string has a "$(ReplacableToken_AutoDeployDb-Web.config Connection String_0)" value which is applied only when the package is deployed.
Why is this? Is it something specific to connection strings (or conversely, to app settings)? I appreciate the rationale of this approach, I'm just not clear on why it's applied to some settings and not others.
Can anyone shed some light on this?
This actually has nothing to do with config transforms. I just posted a very detailed blog at http://sedodream.com/2010/11/11/ASPNETWebApplicationPublishPackageTokenizingParameters.aspx. But some info here for you.
In the Web Publishing Pipeline (WPP) we handle connection strings as special artifacts. We will automatically create parameters for you for all connection strings. This is because in many cases when you deploy your app you want to change the connection strings. We do not automatically create parameters for any appSettting value. Now back to your question why do we tokenize the connection strings? We are really doing this to make sure that you do not miss setting the value and then accidentally have your application updating the wrong DB. We do help you by creating those parameters for you. Also you can disable this behavior if you want. You can set the MSBuild property AutoParameterizationWebConfigConnectionStrings to false.
Regarding deployment, there's one significant difference between them. When you import web packages to IIS:
Connection strings will automatically be included in the wizard dialog for further parameterization.
App settings will not be there by default. If you really want to do that, please follow the steps in "Custom Parameterization - Application settings in the web.config file" section of Configuring Parameters for Web Package Deployment
The differentiation creates a responsibility boundary between dev and ops. On one hand, you put parameters of target environment (database, cache, AWS key/secret, etc.) in connection strings that ops needs to take care of. On the other hand, you put irrelevant options in app settings section so ops's burden over specific products and business logic can be relieved.
In my company, one ops guy is often responsible for multiple products. You really can't require them to know as much product knowledge as you do. The less thing they need to pay attention, the happier the life will be.
Is it possible for the session data of one war file to be shared by other war file
To the point, you just need to configure the server somehow to store the session in a cookie without a path. In case of Tomcat, you can just set emptySessionPath attribute of the <Connector> element to true in /conf/server.xml. Also see this Tomcat Configuration Reference.
<Connector ... emptySessionPath="true">
This however affects all webbaps deployed on the same server.
Update: as you are actually using Websphere (which uses Tomcat under the hoods), you need to alter the Tomcat connector in Websphere's config.xml to include the following attribute:
<attribute name="emptySessionPath">true</attribute>
Its not easy to do. but I have been able to do this using tomcat. Here is a link http://www.fwd.at/tomcat/sharing-session-data-howto.html I'm not sure what server you are using though. Also, why do you need to do this, there may another solution depending on what you need to do.
Tomcat has the Signle-Sign-On Valve:
The Single Sign On Vale is utilized when you wish to give users the ability to sign on to any one of the web applications associated with your virtual host, and then have their identity recognized by all other web applications on the same virtual host.
You may also try to implement single-sign-on using cookies (though this has security drawbacks).