Migrate Dynamics CRM Configuration File Settings for use with ASPNet5 / MVC6 - dynamics-crm

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.

Related

generate web.config at run time - sitecore

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

Scaffolding controller doesn't work with visual studio 2013 update 2

PROBLEM:
I have updated to Visual Studio 2013 update 2 and now I cannot scaffold controllers.
The problem is not project specific: when I try to scaffold a controller, I get the following error in ALL and ANY project:
There was an error running the selected code generator:
'Exception has been thrown by the target of an invocation.'
It was working before updating to Visual Studio 2013 update 2.
Have googled the issue to death, but none of the various suggestions work
Eg:
Commenting out OnModelCreating in my context;
Removing packages such as MvcScaffolding, etc (I have none installed and it doesn't work with ANY project);
I have modified/customised some of the templates, but it was working after the changes.
EDIT:
I uninstalled Visual Studio 2013 Update 2 and thereby reverted to Visual Studio version 12.0.21005.1 REL.
The problem has disappeared. Therefore, the problem is quite definitely with Update 2.
QUESTION:
Does anyone (including Microsoft) know of a fix?
EDIT 2:
Farruk Subhani's answer does not address the question: The question clearly states that removing references to MVCScaffolding does not solve the issue.
I have added a 200 point bounty, please address the question as clearly stated.
Hey for all of you that nothing works, the real answer is you need to remove ANYTHING that has a configSource on the web.config and the connection string needs to be inlined.
EDIT:
Someone pointed out that it needs to be only <configSettings>, <appSettings>, and <connectionStrings> tags NOT using a configSource attribute. And that he was still able to use configSource attributes elsewhere, such as the rewriter tag.
I think it's that the tooling cannot follow configSource locations for the stuff it uses like connection strings and application settings.
Microsoft should be on this issue if not fixed yet.
EDIT 2:
Even thought #awrigley has marked his answer as correct it's a known Visual Studio bug. I've managed to tell then and I think it will get some attention soon.
https://github.com/aspnet/Tooling/issues/169#issuecomment-144197015
A combination of things have worked for me:
Upgrade to Visual Studio 2013 Update 3.
Upgrade Entity Framework to 6.1.1
Modify the context configuration to use IDbSet<...> instead of DbSet<...> (I have heard that this can affect using async actions, but not apparently in my case, as I use this in my login actions, etc, as supplied by ASP.NET Identity 2 sample Nuget package).
Quite why this combination works, I have no idea. But then given the thundering silence from MS, I am probably not alone. I guess update 2 just didn't work...
Solution
Make sure section
<connectionStrings>..</connectionStrings>
is after
<configSections>..</configSections>
Please run the following command in the Package Manager Console:
Uninstall-Package EntityFramework -Force
Install-Package EntityFramework
Uninstall-Package MvcScaffolding
Install-Package MvcScaffolding
I had the very same issue with Visual Studio 2013 Update 3, but only for the scaffolders working with Entity Framework.
The issue is seemingly caused by the incompatibility between Entity Framework 6.1.0 and the scaffolders in Visual Studio 2013 Update 2 and above.
To upgrade EF do the following:
Uninstall-Package EntityFramework -Force
Install-Package EntityFramework
This answer is borrowed from here
After the upgrade the scaffolders are working fine for me. Make sure to install the new version in every project where Entity Framework is required.
n my case, I solved the issue with the connection string in the web.config.
Previuos the issue I has
<connectionStrings configSource="Configs\ConnectionString.config"/>
and I doesnt know why, but vs cant connect to the database and fail.
after the change
<connectionStrings>
<add name="UIBuilderContext" connectionString="metadata=res:/ ..... " />
</connectionStrings>
and it works
I'll explain here a little bit more in English, so anyone can understand. Hope this helps anyone out there This occurs because Visual Studio fails to connect to the database model .
This happens when you change the name and/or the path in the class that extends DbContext and didn't change it in the Web.config file (at the outermost part of your project: the root).
Example:
Imagine you scaffolded the DbContext code:
a) You right clicked a folder in your project and added a "ADO.NET Entity Data Model", and you named it "Model1"
You get the following code:
public class Model1 : DbContext
{
// Your context has been configured to use a 'Model1' connection string from your application's
// configuration file (App.config or Web.config). By default, this connection string targets the
// 'Skelleton.Models.Model1' database on your LocalDb instance.
//
// If you wish to target a different database and/or database provider, modify the 'Model1'
// connection string in the application configuration file.
public Model1()
: base("name=Model1")
{
}
// Add a DbSet for each entity type that you want to include in your model. For more information
// on configuring and using a Code First model, see http://go.microsoft.com/fwlink/?LinkId=390109.
// public virtual DbSet<MyEntity> MyEntities { get; set; }
}
b) Now, you have decided that the name you've just written is plain bad, so you change it to AppContext
Your code now looks like this:
public class AppContext : DbContext
{
// Your context has been configured to use a 'AppContext' connection string from your application's
// configuration file (App.config or Web.config). By default, this connection string targets the
// 'Skelleton.Models.AppContext' database on your LocalDb instance.
//
// If you wish to target a different database and/or database provider, modify the 'AppContext'
// connection string in the application configuration file.
public AppContext()
: base("name=AppContext")
{
}
// Add a DbSet for each entity type that you want to include in your model. For more information
// on configuring and using a Code First model, see http://go.microsoft.com/fwlink/?LinkId=390109.
// public virtual DbSet<MyEntity> MyEntities { get; set; }
}
Then, you try to Scaffold the CRUD (Create, Read, Update, Delete) operations with views and it fails!
Why is that?
Well, if we go to the web.config file, we can see the following string:
<add name="Model1" connectionString="data source=(LocalDb)\v11.0;initial catalog=Skelleton.Models.Model1;integrated security=True;MultipleActiveResultSets=True;App=EntityFramework" providerName="System.Data.SqlClient" />
(This line is usually below <add name="DefaultConnection" )
And there is where the problem lies. You need to change Model1 for the name you've given out!
In this case, it should say "AppContext" instead of "Model1"
And where it says:
initial catalog=Skelleton.Models.Model1;
Verify that:
It's the name of the .cs file that has the class
The namespace (or the series of names (dot-separated) that comes before the name of your class) is the correct one. It's important to notice that you do not append to the end the ".cs" extension; just the name of your file.
It should look like this:
Because I changed the name of the class, both internally and externally (inside it and it's file name), and did not change its location, I just rename it to AppContext
After this has been done. You can scaffold normally ;)
Hope this helps!
For me, I had to ensure <configSettings>, <appSettings>, & <connectionStrings> tags were NOT using a configSource attribute.
I was still able to use configSource attributes else where, such as the rewriter tag.
I think, the problem is due to bad configuration in web.config file.
In my case I had multiple
<entityFramework> sections in web.config, and the problem resolved after I changed the configurations.
I'm on VS 2013 Update 4 and have exactly same issue. It works for me when moving connection string from external file into web.config. So I guess you could try to make sure not using configureSource attribute for connectionString when scaffolding.
My web.config before and after the change
Before:
<connectionStrings configureSource="connectionStrings.config/>
After:
<configuration>
<configSections>
<!-- For more information on Entity Framework configuration, visit http://go.microsoft.com/fwlink/?LinkID=237468 -->
<section name="entityFramework" type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
<section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
</configSections>
<log4net configSource="log4net.config" />
<connectionStrings>
<clear/>
<add name="DefaultConnection" connectionString="Data Source=.;Initial Catalog=YourDb;Integrated Security=False;User ID=sa;Password=YourPassword!#;MultipleActiveResultSets=True" providerName="System.Data.SqlClient" />
</connectionStrings>
This can be useful for people who haven't installed any scaffolding nuget packages in their solution.
In fact I don't have mvcscaffolding or t4scaffolding installed and got the same error message.
In my case the problem/bug was caused by changing the connection string.
Here what I had/steps to reproduce.
Installed Visual Studio 2013 Community Edition
Created MVC project
Created code first model
Edited connection string to connect to a real server, like this:
<add name="DefaultConnection"
connectionString="server=myserv;database=MyCustomerDB;user id=myuser;password=mypass"
providerName="System.Data.SqlClient" />
Then I enabled migrations via nuget, like this:
Enable-Migrations
Add-Migration InitialCreate
Update-Database
I started the website and I could register a user. All tables were created correctly.
Then I created a controller by using the scaffolding option:
right click on "Controllers" > "Add" > Controller... > MVC 5 Controller with views, using Entity Framework > selected my context and a class to be used. It worked.
Then I decided to do more code first changes and begin from scratch:
I changed the connection string as follows, to use localdb:
<add name="DefaultConnection"
connectionString="Data Source=(LocalDb)\v11.0;AttachDbFilename=|DataDirectory|\aspnet-Test-20141126094523.mdf;Initial Catalog=aspnet-Test-20141126094523;Integrated Security=True"
providerName="System.Data.SqlClient" />
Then I went on:
deleted the migrations folder
re-enabled migrations using the same commands as above, in the nuget console
started thw website and registered a user
checked the mdf db. All tables are there, so the connection string works.
right click on "Controllers" > "Add" > Controller... > MVC 5 Controller with views, using Entity Framework. Selected my context and a class to be used. It did not work and this popup error appeared:
There was an error running the selected code generator: 'Exception has
been thrown by the target of an invocation.'
SOLUTION:
After some investigation, what I did, is changing back the connection string in the web.config to the initial one to the "real server" (instead of localdb). I tried again to generate the controller with views. It worked!
So it seems to me a connection string problem/bug or a localdb problem... can't explain it. Maybe Visual Studio doesn't like what I did, I had to keep my old connection string...
Anyway, so now when I need scaffolding I just change the connection string to the one that works. Then to test my website I change it back to the localdb one.
I have performed following to solve this issue:
In Package Manager check if you have MVCScffolding or T4Scaffolding (Core or pre release for vs2013)
Uninstall all packaged that depend on any of MVCScaffolding or T4Scaffolding
Copy CodeTemplates Folder in full (Do not replace your custom templates but make sure you have rest of the files from root of this folder. I take that you have done that part as you have customised some templates so you know where this folder is)
Build Your project and close it.
Restart Visual Studio under admin mode
Open Package Manager Console (it should not have any errors and you can see PM> without errors.
Right Click on Controller folder and choose Add->New Scaffolding Item or Choose Add->Controller both should ask which one you want and then choose MVC5 scaffold or which ever appears in list.
You will then get to select your parameters if its controller you might need to choose DBContext or repository etc.
This produced the controller and relevant views for me.
I added a custom partial view called QuickView in that folder however this scaffolding procedure did not consider that and only generated views that it was doing by default. I am not sure if you need to add these custom views in a file to tell Scaffolder to generate those as well.
For me what worked was to make sure the <configSections> node in the web.config file was the first node immediately after <configuration> node.
Initially, when I added my connectionStrings, I had actually placed it before the configSections, which made the Scaffold tool break.
Seems like when the scaffolding runs and tries to grab connection info, it expects the config section for the entityFramework node to be there already so it know what DB provider to use, but when I had the connection string before configSections, it didn't know to use LocalDB (which is what my conn string was using).
I'm running VS 2015RC the last one before final cut. Not to discount any of the solutions here. My solution was under nugget package manager and updated my Microsoft.Aspnet.Mvc 5.2.3 package and that fix my issue.
I hope that helps anyone using VS 2015.
i used Initializer and when remove/comment Initializer from myDbContext constructer , scaffolding work fine
public myDbContext () : base("name=DefaultConnection")
{
//Database.SetInitializer(new DropCreateDatabaseIfModelChanges<DastanakDbContext>());
//Database.Initialize(true);
}
I have been having this same problem in update 4. I found that the problem came from the <configSections></configSections> not having a section name defined. The fix I put in between the tags is as follows and all the errors were fixed:
<section name="entityFramework"
type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection,
EntityFramework, Version=6.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089" requirePermission="false" />
Build the project and everything should work. Cheers!

Common settings file for multiple projects in a solution

Visual Studio project structure - https://www.box.com/s/np59x20f939n3z1g5dvc
I have multiple projects A, B, etc. that have load tests (which in turn call respective web tests) and a settings file separately for each one of them. I am using these settings files to store the info about web servers.
[Settings.xml]
<?xml version="1.0" encoding="utf-8" ?>
<AppSettings>
<WebServer>www.abc.com</WebServer>
<Proxy></Proxy>
</AppSettings>
I am adding this xml file as a data source in the web test as shown here https://www.box.com/s/53vy0ryvye53m76abuun
Project C has a load test that calls upon web tests from other projects (I am only referring to the projects A, B, etc. here). The setting file for project C looks like this.
<?xml version="1.0" encoding="utf-8" ?>
<AppSettings>
<WebServer>www.SomeOtherWebsite.com</WebServer>
<Proxy></Proxy>
</AppSettings>
I want this settings file to be used for running the Loadtest-C i.e. this settings file has to override the individual settings file from each project.
I want to run LoadTest-C sometimes and LoadTest-A or LoadTest-B sometimes. So, I don’t want to change the individual settings files everytime.
Is there a way I can achieve this?
I found using xml files to be the simpler way. But, please do suggest me if there is a better way.
I have searched online and the only thing I found relevant was this - common Settings.settings file for entire solution. I have a lot of projects similar to A, B, etc. and I don’t want to change the links in each and every project as suggested in the answer there.
[I have never tried coded web tests. So I am not sure if that approach works.]
[and i am relatively new to performance testing]
I have found a solution for this. Instead of using the Settings.xml file, I am adding the entries in that xml file as context parameters to the load test and eliminating the use of data source in individual web tests. So when I run the web test, the parameter it has for web server name is being supplied by the context parameter in the load test.
This might not be the best solution, but this seems to work for me.

Using the same DbCompiledModel to create contexts against different types of database servers is not supported

I am learning ASP.NET MVC from tutorials of Microsoft :
http://www.asp.net/mvc/tutorials/getting-started-with-aspnet-mvc3/cs/accessing-your-model's-https://stackoverflow.com/editing-helpdata-from-a-controller
At the link above mentioned, while adding a controller named "MoviesController" , i am getting this error
"Unable to retreive metadata for 'MvcMovie.Models.Movie'. Using the same DbCompiledModel to create contexts against different types of database servers is not supported. Instead, create a separate DbCompiledModel for each type of server being used"
How can i fix that?
I had the same issue.
I switched providerName="System.Data.SqlServerCe.4.0" with providerName="System.Data.SqlClient", and it created the Controller and Views.
I found this: http://msdn.microsoft.com/en-US/library/ms171861.aspx
I followed the directions and added a reference to SQL Server Compact, but it still doesn't work.
I also tried commenting out the default SQL Server Express connection, but it still gave the same error when trying to add the controller.
I'm just going to use SQL Server Express. I will let you know if I have any issues.
I've found that using the following works:
(Assuming that you've got SQL Server Express or higher installed)
<add name="MovieDBContext" providerName="System.Data.SqlClient" connectionString="Data Source=(LocalDb)\v11.0;AttachDBFilename=|DataDirectory|MovieDB.sdf"/>
I think the reason of this error is because the VS is having some difficult to reuse your existing DBContext, while scaffolding. The VS try to use a property in DBContext with similar name of the Domain (like trying the Domain name concatenating "s"). If it cant find the property and your context already has a DBSet with you Domain class, it generates that error.
My solution was to create a new DBContext named "DeleteContext". After creating with success the controller and views, I have replaced the "DeleteContext" in my Controller to my existing one. Finally I deleted the "DeleteContext" class.
It works really fine.
That solution was not working for me, it blows on return View(db.Movies.ToList());
Instead use this :
<add name="MovieDBContext" connectionString="Data Source=|DataDirectory|Movie.sdf" providerName="System.Data.SqlServerCe.4.0"/>
and this:
public class MovieDBContext : DbContext
{
public MovieDBContext() : base("Movie") { }
public DbSet<Movie> Movies { get; set; }
}
I ran into the same error on another Microsoft ASP.NET MVC tutorial while using Visual Studio 2012 (http://www.asp.net/mvc/tutorials/mvc-music-store/mvc-music-store-part-5).
I decided that for the sake of completing the tutorial, it was easier to just use SQL Express in place of SQL CE.
What I did to resolve the issue was delete MvcMusicStore.sdf from Server Explorer, then deleted the same database file from App_Data in Solution Explorer.
I updated the connection strings section in the Web.config to use a Sql Express database (.mdf) in place of Sql CE (.sdf). For this particular tutorial, MusicStoreEntities is the name of the class that extends DbContext:
<connectionStrings>
<add name="MusicStoreEntities" connectionString="Data Source=(LocalDB)\v11.0;AttachDbFilename=|DataDirectory|\MvcMusicStore.mdf;Integrated Security=True" providerName="System.Data.SqlClient"/>
</connectionStrings>
I built the solution, ran the site, and the database was regenerated for me. To add the database file back to the solution, click the "Show All Files" button in Solution Explorer, right-click the .mdf file in App_Data, and select "Include in Project."
Hi there's one solution that worked fine to me. In your Web.config, the tutorial told you to add the following line in the connectionStrings section:
<add name="SchoolContext" connectionString="Data Source=|DataDirectory|School.sdf" providerName="System.Data.SqlServerCe.4.0"/>
Do not delete it or change it!
When you're adding a new controller you can make this to avoid the error that is presenting:
Comment the line above.
Add the following line:
<'add name="SchoolContext" connectionString="Data Source=|DataDirectory|School.sdf" providerName="System.Data.SqlClient"/>
Save your solution
Add the controller
Before you run your app, uncomment the line you have commented (1), and comment the line you added (the one with the providerName="System.Data.SqlClient") (2).
This worked very fine to me, when adding the controllers.
Hope this could help you.
I just tryed a bit around and found the problem.
In the tutorial you are adding the following line in your web.config
<add name="MovieDBContext" connectionString="Data Source=|DataDirectory|Movies.sdf" providerName="System.Data.SqlServerCe.4.0"/>
It seems that there is a problem with it.. i just commented it out and used the SqlServer and it works for me. If you still want to use the SqlServerCe you need to take a look how to fix that problem.
If you're using VS 2012, you will need to also tell EF to use SQL Compact instead of localDb.
<entityFramework>
<defaultConnectionFactory type="System.Data.Entity.Infrastructure.SqlCeConnectionFactory, EntityFramework">
<parameters>
<parameter value="System.Data.SqlServerCe.4.0" />
</parameters>
</defaultConnectionFactory>
An easier way is to install the EF SQL Compact Nuget package.
For more details, check out this blog entry.
I ran into this same problem while working through the Contoso University asp.net MVC tutorial. It appears that the problem comes from mixing the SQL Server Compact connection strings with the Membership provider Sql Server connection.
I initially used hyperGeoMetric's fix, and that did work. Then I looked at the downloadable code's web.config and noticed some additional configuration.
If you add/replace the default parameter of entityFramework with this:
<parameters>
<parameter value="Data Source=(localdb)\v11.0; Integrated Security=True; MultipleActiveResultSets=True" />
</parameters>
add a system.data section like this:
<system.data>
<DbProviderFactories>
<remove invariant="System.Data.SqlServerCe.4.0" />
<add name="Microsoft SQL Server Compact Data Provider 4.0" invariant="System.Data.SqlServerCe.4.0" description=".NET Framework Data Provider for Microsoft SQL Server Compact" type="System.Data.SqlServerCe.SqlCeProviderFactory, System.Data.SqlServerCe, Version=4.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91" />
</DbProviderFactories>
</system.data>
and modify the existing (default) DefaultConnection to look like this:
<add name="DefaultConnection" providerName="System.Data.SqlServerCe.4.0" connectionString="Data Source=|DataDirectory|aspnet-membership.sdf" />
After these modification, I was able to continue the tutorial using the Sql Server Compact edition.
Sam
I followed that tutorial too, and got the same issue. I deleted the connection string, then I was able to add the controller, and it created the other files. Then I added the same connection string again to the Web.config file, inserted it ecxactly to the same place where it was before. It solved my problem.
I'm learning this tutorial:http://mvcmusicstore.codeplex.com/. and got the same error. I found a item name "EntityFramework.SqlServerCompact" in the NuGet packages list, and install it, all things go fine! note, the packages dependent entityframework, you can view all the version here:https://www.nuget.org/packages/EntityFramework.SqlServerCompact. GOOD LUCK!
the path of data source is wrong , you can add a "\" before "Movie.sdf".
like this:
<add name="MovieDBContext" connectionString="Data Source=|DataDirectory|\Movie.sdf" providerName="System.Data.SqlServerCe.4.0"/>
I ran into the same problem in another solution. It appeared just after I introduced a parametrized call to the base constructor, like the one included in the default UsersContext class.
This fails
public class MovieDBContext : DbContext
{
public MovieDBContext() : base("DefaultConnection")
{
}
...
}
This works
public class MovieDBContext : DbContext
{
// No constructor here
...
}
It seems that naming the connection string in the constructor creates the error. I only have one connection string in my web.config, so DefaultConnection is still used, although I don't name it explicitly.

What creates a Web.config appSettings entry?

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.

Resources