Flag Product

Tom Hollander's blog

Add to my list

Send to friend

Compare prices

Shop for it: (added from 1 site)

Buy itmsdn.com

See more products from this brand »

Added by 1 people

cabeleira added to Programming

0 Hearts

Description:

If you've played with Enterprise Library for .NET Framework 2.0, you may have wondered why the Data Access Application Block always shows up in the configuration tool when you open an application's configuration file, even if you... See more » If you've played with Enterprise Library for .NET Framework 2.0, you may have wondered why the Data Access Application Block always shows up in the configuration tool when you open an application's configuration file, even if you didn't ask for it - and that it seems to be impossible to get rid of: The behavior is indeed strange, and it wasn't a deliberate design decision - rather it was a consequence of a few other changes we made to better align Enterprise Library with new features in .NET Framework 2.0. First, Enterprise Library now uses System.Configuration to load and save configuration. That means that all of the features of System.Configuration can now work with Enterprise Library, even if some of these are somewhat unexpected. One of these features is that configuration data from machine.config is automatically merged into each application's view of configuration. You'll see in a moment why this is important. Second, the Data Access Application Block now uses .NET's new section to manage the connections used by the block - the same configuration section that is used by other .NET features. The DAAB does still have its own section it uses for more advanced features such as specifying a default database or custom provider mappings, but the block can work without these settings. Finally, by default, the machine.config file contains a section including one default connection, called LocalSqlServer - which points to (I'm sure this will be a shock to you), an instance of SQL Server on your local machine. Since I'm no Agatha Christie, you've probably solved the mystery by now. Whenever the Enterprise Library Configuration tool opens an application's configuration file, System.Configuration dutifully merges machine.config with the requested file, and gives the result back to the tool. In fact it doesn't even bother telling the tool which sections came from where, which is why we can't hide the LocalSqlServer section or show it as read only. As far as the tool (or you, until you learnt the awful truth) knows, this section is a part of the application's configuration file. However if you change or delete this connection string using the tool, System.Configuration won't actually persist the changes back to the file, since it's machine.config and you have no business messing with it (not that it will tell you this, of course!) Of course, if this behavior really bothers you, you can open up machine.config with notepad and remove this section, and it will bother you no more. However, the presence of this section doesn't cause any real harm - in fact you can indeed call DatabaseFactory.CreateDatabase("LocalSqlServer"), so arguably you should see it every time you open up an application's configuration file. Stay tuned next time as we unveil more Enterprise Library oddities... :-) See less »

Tags:

blog, enterprise library, microsoft

Comments (0)

Add a Comment:

Not a Kaboodler? Join Now, It's Free!

Email:

Screen Name:

Password:

Birthday:

Security Check
(Reload)

Enter Both Words

I have read and agree to the Terms of Service

Remember me on this computer.

Kaboodle will send you a newsletter and updates from your friends. You can unsubscribe at any time. Kaboodle does not sell or share your email address or personal information with anyone.

Cancel Already a Kaboodler? Sign in

Tom Hollander's blog

Comments (0)

Add a Comment:

Thanks for Hearting!

Not a Kaboodler? Join Now, It's Free!

Sign in to Kaboodle