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="" />
Related
We are running OD 1.6.
I'd like to use OD variables to change values such as Session State Provider that aren't in the app settings section.
I know I can use a transform for this, but as a company we prefer to use OD variables as opposed to transforms as it allows our ops team to change settings without changing our codebase.
Is there a way to inject variables into arbitrary places into the web.config?
Something like:
<sessionState mode="Custom" customProvider="#{MyODVariable.SessionStore}">
<providers>
<add name="MySessionStateStore" type="Microsoft.Web.Redis.RedisSessionStateProvider" host="#{MyODVariable.Host}"
accessKey="#{MyODVariable.AccessKey}" ssl="#{MyODVariable.SSL}" />
</providers>
</sessionState>
In 2.4+ There is a feature for that but in 1.6 the only way to resolve this would be to write a PowerShell script and do a replace in the file. If you are looking for an example a good place to start would be the PowerShell code found on this library page: http://library.octopusdeploy.com/#!/step-template/actiontemplate-file-system-find-and-replace
Clearly the question was written a long time ago, for what is now an old version. In case anyone with a more recent version arrives here...
You can use a transform file containing Octopus variables. Choose Configure Features to enable replacing variables in that file (you have to tell it which file), and to enable applying the transform (use the naming convention, or tell it what you want).
You can then add the community-contributed steps to find unreplaced variables (tick the box to Treat as an error, so the deployment fails if a variable has been missed) and remove transform files.
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 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" ... />
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.
I have an AUTHORING machine, a FAILOVER machine, and a PUBLIC machine. AUTHORING points to both FAILOVER and PUBLIC as remote publishing targets.
When publishing to all targets the content is immediately visible on FAILOVER. However, I am forced to manually clear the cache on PUBLIC to have the new content viewable by visitors.
I'm hopeful this is a simple configuration issue that someone can point me to an answer for.
Many thanks!
Probably, the cache clearing configuration is different on FAILOVER and PUBLIC. It's difficult to say exactly based on the info you provided, but the links below might help you or give a hint:
Problem with publishing items and not seeing it until hours later
Clear Cache on Publish
Clear cache on publishing target - without staging module
Instead of Failover and Public why not have the single Web database with the two servers sharing it? With a load balancer in front you'd not only have redundancy but also increased performance.
Check the staging module logs to make sure the cache clear is successful on both servers following a publish. They can be found at:
\sitecore modules\staging\workdir
Perhaps there is a network or security error that is preventing the cache clear from working properly on PUBLIC?
You might need to check your config to see if the history engine is setup/configured. E.g.
<sitecore><configuration>...
<database id="webtarget">
...
<Engines.HistoryEngine.Storage>
<obj type="Sitecore.Data.$(database).$(database)HistoryStorage, Sitecore.Kernel">
<param connectionStringName="$(id)" />
<EntryLifeTime>30.00:00:00</EntryLifeTime>
</obj>
</Engines.HistoryEngine.Storage>
</database>
...
<hooks>
<hook type="Sitecore.Modules.Staging.InitializeEngines, Staging.Kernel" />
</hooks>
...
</configuration></sitecore>
Review the staging module documentation.