I integrated active directory with sitecore and it works perfect, now i am trying to write patches for the config changes. Sections <membership defaultProvider="sitecore" hashAlgorithmType="SHA1"> and <roleManager defaultProvider="sitecore" enabled="true"> are changed for connection setting to AD. When i try to write config patch for this section, this section is not built at run time. But the domains section works, i mean the patch i created for this section works and writes to web.config at runtime. I observed a difference here Domains section is under <Sitecore>, <membership> and <roleManager > are in <system.web> section. Is this the reason that these are not included in web.config? can we write patches for those sections only under <sitecore>?
Any ideas are appreciated.
Thanks.
You can only patch elements within the /configuration/sitecore element.
Refer this post:
http://www.sitecore.net/Learn/Blogs/Technical-Blogs/John-West-Sitecore-Blog/Posts/2011/05/All-About-Web-config-Include-Files-with-the-Sitecore-ASPNET-CMS.aspx
I think you have to use config transforms as mentioned by leandro.
I assumming you are using Visual Studio ¿? You must specify in what are you working.
If so, you need create a transform file for the build configuration that you need, for example, one config for every environment or publish type.
Try a look at this:
http://msdn.microsoft.com/en-us/library/vstudio/dd465318%28v=vs.100%29.aspx
Related
We're trying to leverage Azures deployment slots for an Umbraco site we've built.
By default Umbraco uses a DSN defined in the connectionStrings sections of the web.config and we want it to use the connection string for the deployment slot it's sitting in.
What we've tried
Azure deployment slots put all defined app settings (and connection strings) into environment variables and to access them we can use Environment.GetEnvironmentVariable() which works but there doesn't seem to be a way to tell Umbraco to do this.
So in OnApplicationInitialized() (in /App_Code/Core/UmbracoAppStart.cs) we loaded the connectionstring section from the web.config, grabbed the connstr from env vars, added the DSN to the connectionstring section and saved.
The correct connection string is grabbed and stored but this seems to recycle the app (due to a web.config change) and thus we just get timeouts. (Or Umbraco XML cache errors, or it takes 20 mins to load the page).
I know you can store the appsettings and connectionstrings sections in separate files. But the file attribute (that doesn't cause a recycle if the referenced file is changed) doesn't work on the connectionStrings section - only the configSource attribute and that DOES recycle if changed.
(from: ASP.NET web.config: configSource vs. file attributes)
Help
Has anyone found a way around this?
We simply need to get Umbraco to use the deployment slot connection string - not the one in webconfig.
I'm even willing to copy and paste blindly at the moment without understanding how it works - and I hate doing that :). But that's what happens when people agree when the client wants to go live just before Christmas...
You don't need to do any code to use Azure connection string or the app settings. Just give them the same keys/names as you have on your web.config and they will be used instead.
So if you have this on your web config:
<add name="umbracoDbDSN" connectionString="Server={server};Initial Catalog={db};Persist Security Info=False;User ID={user};Password={password};MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=300;" providerName="System.Data.SqlClient" />
Your slot configuration should be this:
To replace an app setting just use the same key. So for this:
<add key="umbracoUseSSL" value="false" />
You'd use this:
If you want the setting to be slot specific you have to activate the Slot setting checkbox.
Is there a way to see TeamCity configurations that override parameter defined in template?
I don't think so. What's worked for me in the past was to search through the project files on the filesystem. If you have many build configs, this will be faster than opening each of them in the GUI.
Search for something like this:
<param name="myParamInheritedFromTemplate" value="myOverrideValue" />
in <TeamCity data directory>/config/projects/**/*.xml. If it's absent in an XML file, that build config just inherits the value. If it's present, it overrides it.
It's hacky but it's quick.
There is a feature request https://youtrack.jetbrains.com/issue/TW-21212, please vote. Current workaround are to either search the raw XML files with the settings stored under TeamCity Data Directory on the server as #sferencik suggested, or use REST API to get settings of all the build configurations and search for the parameter there. Let me know if you need help on any of these.
No answer required - experience documented for others
I wasted significant time and hope to save others the trouble
TLDR;
If you are trying to use Microsoft Dynamics CRM with an ASP.NET 5 MVC 6 (dnx / vnext) application, don't overthink it - just use the existing web.config file!
Personally, I got so wrapped up in the new configuration paradigm that the now obvious approach of just using the good 'ol web.config file to store the required configuration settings did not occur to me.
I was trying to connect to Microsoft Dynamics CRM; everything compiled and executed until I hit code that tries to create a CRM context generated using CrmSvcUtil.exe.
var xrm = new XrmServiceContext("Xrm");
The runtime error I got was, "A configuration element with the name 'Xrm' under the 'contexts' collection does not exist."
This simply means that there is something wrong with the configuration file. Now, I had an existing console application with the proper (working) configuration settings and I was trying to simply port them over to this vNext solution:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
<section name="microsoft.xrm.client" type="Microsoft.Xrm.Client.Configuration.CrmSection, Microsoft.Xrm.Client"/>
</configSections>
<connectionStrings>
<add name="Xrm" connectionString="Server=https://myserver.crm.dynamics.com; Domain=; Username=myUsername#domain.com;Password=myPassword"/>
</connectionStrings>
<microsoft.xrm.client>
<contexts default="Xrm">
<add name="Xrm" type="Xrm.XrmServiceContext, Xrm" connectionStringName="Xrm"/>
</contexts>
</microsoft.xrm.client>
</configuration>
My mistake, however, was a misguided attempt to use the new configuration paradigm and import the "Microsoft.Framework.Configuration.Xml" NuGet package. Then, I added the configuration file containing the necessary settings during Startup(): Again, this isn't the right approach; use web.config instead:
var builder = new ConfigurationBuilder(env.WebRootPath)
.AddXmlFile("config.xml")
.AddEnvironmentVariables();
It took me writing out the speculation here that the CRM dll's have no clue about the new IConfigurationSource approach. I knew there had to be another way and then my Friday night tired brain finally clicked..."Hey, I see a web.config file...I wonder if that would work." Yes, it does.
With some custom logic I have added a template for my web config in my Asp Mvc 4 application. When I need to modify the web.config file I am editing the template file for it and the changes are replaced in the web config file when I run the application. The problem is that when I add a package via nuget which needs to modify the web config file I am losing those settings as everything is overriden from my template file. Is there a way to somehow force the nuget packages to modify some custom xml file instead of the original web config file. For example, to modify mytemplate.xml instead of web.config.xml.
I am very new in this area and couldn't find a solution for my problem. As far as I understand packages that need to modify the web.config file come with web.config.transform file that merges the required fields and my only solutions is to manually replace the settings added to my web config file by the package into the template file. Is there another solution ? Thanks!
You are using your web.config file to do two different things:
Static configuration for nuget packages
Dynamic configuration for your site
web.config files allow you to define some of your settings in an external file and import them - e.g.
<configuration>
...
<appSettings configSource="appSettings.config" />
...
</configuration>
This is appSettings.config:
<appSettings>
<add key="umbracoDbDSN" value="..."/>
<add key="DefaultInstanceName" value="..."/>
<add key="aspnet:MaxHttpCollectionKeys" value="..."/>
</appSettings>
It's unlikely that you need to completely re-generate your web.config every build, probably only specific sections - if these don't clash with your installed packages then this approach would give you the flexibility your application needs.
OR PLAN B
packages.config lists all of the active packages in your solution
Packages store their web.config settings in a local file:
/packages/package/content/Web.config.transform
Can you extend the process that builds your web.config file to:
Enumerate the active packages
Check for a content/Web.config.transform file
Merge those files into your web.config build pipeline
I can't see any way of re-configuring nuget to push the configuration into a different file.
I am fairly green at ASP.NET coding, even though I have done very basic tasks for a while.
Recently, I have been assigned our company's website, so I am learning more of the details.
I downloaded the project from Source Safe, and I am making changes in the code.
A co-worker and I were looking at the Web.config file, and noticed this under the <configuration> section:
<appSettings>
<add key="HR_EMAIL" value="myEmailAddress#work.com"/>
<add key="APP_MODE" value="TEST"/>
<!-- PROD is the production value for ssl pages -->
<add key="HR_EMAIL_SITE_A" value="myEmailAddress#work.com"/>
<add key="HR_EMAIL_SITE_B" value="myEmailAddress#work.com"/>
</appSettings>
where myEmailAddress#work.com used to list my actual email address.
My co-worker said, "Oh, you've changed it and removed my email address."
Uh, no I have not! I could care less if these people email me!
I'm guessing something configured on my local machine (maybe in machine.config) went in and updated these values whenever I rebuilt the project.
I have used a walkthrough recently published by Microsoft (Walkthrough: Creating a Web Site with Membership and User Login), but it was in a different project.
What changed these values? Surely I did not do this in my sleep!
Chances are that someone committed these values to source control.
You got the latest value - possibly your workmate has not updated this file in a while.
Take a look at the file history in Source Safe to see what happened with this value.
section, as the name suggests, is specific to application to store custom settings. Before ASP .NET 2, this section was used to store things like connection string used by the web application.
In you case, I am guessing that, you have an admin site/system that is writing out your email adress to app.config.
I have seen another scenario, where setting will be updated by the build/release script.
You'll likely find that due to differences in enviroments, in most cases you don't deploy a web.config from enviroment to enviroment. You wouldn't want test settings, like connection strings, emails, etc getting propigated to production.
When you're likely finiding is the config in VSS is a local testing copy and the production copy has different values.