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.
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.
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.
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
I am developing an application in ServiceStack and am trying to sort out deployment on AppHarbor, however for some reason my web.config transforms are not being applied.
I had originally a Web.AppHarbor.config file and changed the Environment Setting to "AppHarbor" - once this failed to work after several updates, I gave up and changed the Environment setting to "Release" and copied the desired transformations into the Web.Release.Config file.
App gets deployed OK but config settings do not reflect the values in the transform file (I verify this by login on with twitter and seeing the callback url for Twitter Auth still tries to redirect me to localhost, which is one of the settings I change in my transform file)
I have also tried the transform tester tool and all works as expected.
Manually publishing the web application to a local folder correctly applies the transformations according to the selected configuration
Does anyone have this working? Is there something obvious I'm missing?
Thanks
It sounds like the Web.Release.config file is not included in the build output. You need to set the Build Action attribute to Content to include it in the build output.
You can confirm whether the file is included in the output by downloading the build from the log page.
I stumbled across this post because I was seeing the same lack of action myself. Upon closer inspection (about 15 times that is) of my Web.Release.config I realized one of the nodes in my config file was not marked xdt:Transform="Replace". Unsurprisingly it did nothing when deployed.
I'm currently editing my portal_normal.vm (server/tomcat/webapps/mytheme-theme/templates) testing if I can write on the file and see it on my browser. I tried putting a test comment "<!-- test -->" just to see if I can really write on the file. So I refreshed the file and hope I can see the comment I've added, but there we're none. So I continued refreshing (ctrl+r),\ and viewing the source code for almost an twenty minutes. After a while when I tried viewing it again it reflected in my source code. So I thought it was cached by either Liferay or my browser.
So I tried tweaking the comment adding version on it ("<!-- test v2 -->"), hoping to see changes. I checked it on another browser and the comment didn't update or include my added version. So I think Liferay is responsible for the issue.
this is what my portal-ext.properties contain:
auth.token.check.enabled=false
# Database settings
jdbc.default.jndi.name=jdbc/LiferayPool
#For removing captch
captcha.check.portal.create_account=false
session.enable.phishing.protection=false
default.regular.theme.id=my_site_WAR_my_theme
#Delete cookies while deleting session
session.enable.persistent.cookies=false
#redirecting null problem.
redirect.url.security.mode=mysite.com
journal.template.velocity.restricted.variables=
admin.email.from.name=Market.Travel Team
admin.email.from.address=admin#mysite.com
# Added because of the Error - No Hibernate Session bound to thread, and configuration does not allow creation of non-transactional one here
hibernate.current_session_context_class=thread
session.enable.url.with.session.id=false
and my portal-developer.properties
theme.css.fast.load=false
theme.images.fast.load=false
javascript.fast.load=true
javascript.log.enabled=true
layout.template.cache.enabled=false
browser.launcher.url=
combo.check.timestamp=true
freemarker.engine.cache.storage=soft:1
freemarker.engine.modification.check.interval=0
openoffice.cache.enabled=false
velocity.engine.resource.manager.cache.enabled=false
com.liferay.portal.servlet.filters.cache.CacheFilter=false
com.liferay.portal.servlet.filters.themepreview.ThemePreviewFilter=true
Addition: When I tried editing the css files I can see the changes fast. Just one reload the the changes appear. I think it is just in my velocity template that take some time or there's something wrong.
Liferay version: Liferay Portal Community Edition 6.0.6 CE
Thank You!
There is really no need to define your own portal-developer.properties. By adding -Dexternal-properties=portal-developer.properties to your JAVA_OPTS in tomcat/bin/setenv.(sh|bat) Liferay will use it's default developer settings, which are almost identical to what you have provided. However, I do not believe this is contributes to (or could resolve) your problem. More details here.
The developer properties do allow you to make live changes to the templates provided you are changing the right file. Due to the default context.xml Liferay provides to the deployed webapps, the webapps are copied/cached in tomcat/temp/{id}-webapp-name. This means if you change the template in webapp/mytheme then it may take tomcat a while to pick up on the change, if it notices the change at all (this will depend on the tomcat configuration). On the other hand, if you make a change in temp/1-mytheme it will show up immediately. Editing the files in the temp folder is probably not ideal, so...
How to fix this: (no specific order)
Prevent Tomcat from using the temp directory for your theme. Create a context.xml file for your theme.
<Context cachingAllowed="false"/>
This file should be placed in the META-INF folder of your
theme. If you are using the Liferay auto-deploy feature the
context.xml file may be clobbered, here, and here. If this
is the case you will need to find a work around that best suits your
needs, such as modifying the context.xml after the theme is deployed.
If you are using the Liferay Plugin-SDK the you can follow the fast plugin development guide for setting up your development environment.