Monday, October 17, 2005

This time it's technical

Ok, long time no post. Here's one for .NET developers having issues with the old

"Microsoft.Practices.EnterpriseLibrary.Data.Instrumentation.DataConnectionFailedEvent"

and occassional

"System.Security.SecurityException: Requested registry access is not allowed."

We changed server in the end. I did find a solution on a blog page somewhere, but I can’t find it now – here’s what I wrote in an email to a colleague:

1. Go to: “C:\Documents and Settings\All Users\Start Menu\Programs\Microsoft patterns & practices\Enterprise Library\Quickstart Applications\Logging & Instrumentation Application Block” or (if you downloaded Enterprise Library circa June 2005): "C:\Documents and Settings\All Users\Start Menu\Programs\Microsoft patterns & practices\Enterprise Library - January 2006\QuickStart Applications\Logging Application Block"
2. Load: “CS Logging QuickStart”
3. In ‘Solution Explorer’ highlight ‘Common’ (this should be the top project)
4. Open the drop-down menu over the ‘Common’ project
5. Select ‘Properties’
6. In the left-hand menu select ‘Configuration Properties’
7. In the left-hand menu select ‘Build’
8. In the right-hand pane, change the value for ‘Conditional Compilation Constants’ to: DEBUG;TRACE
9. Click OK
10. Change the build mode to Release
11. Rebuild the entire solution
12. Copy the Common, Configuration and Logging DLL's from the "C:\Program Files\Microsoft Enterprise Library\QuickStarts\Logging\CS\LoggingQuickStart\bin\Release" (if you downloaded Enterprise Library circa June 2005): "C:\Program Files\Microsoft Enterprise Library June 2005\src\Logging\bin\Release" into your own project (as you did way before you started getting all these errores)
13. Rebuild your own project.

Rebuild and it should work; you’re basically changing the build options of the project so as not to use the logging mechanism (ie: leaving out the part which is throwing the error). This is safe (for me, at least) because I never look at the logged output in the system logging application anyway; if I want logged information I use my own log (or stop points).

I think the default MS .NET logging is a good idea, but in practice it falls down because not enough developers get so deep into manipulating the system’s properties and functions to make it worthwhile figuring out a solution than writing their own. The logging is exactly this, good in principle, but requires lots of permissions which are, stupidly, not assigned by default to the .NET system user (if you’ve had problems writing files to supposedly permitted directories you’ll understand what I mean).

Ok, so I've decided to start recording my discoveries and successes in C# land here because otherwise I'll never have anything interesting to write. And I'll simply lose all my own solutions if I don't.