SynchronizationLockException on Logging Block

Topics: Logging Application Block
Dec 22, 2011 at 7:19 PM

I'm using the Enterprise Library 5.0 with Optional Update 1 and I've run into this SynchronizationLockException trying to instantiate a new logger in a Unit Test.

I've read around and saw people with similar exceptions where they saw this issue and either disabled exception warning completely and/or limited it to hiding that exception.  Here is the code I have written (some taken from the Logging Block test code).  I am trying to debug this code from the context of a Unit Test.

Am I doing anything wrong here?  Is this still an issue?  I am trying to do some demos with the library to get buy in to adopt it in our applications and would like to avoid having to disable exceptions in visual studio.

			lock (sync)
			{
				if (writer == null)
				{
					try
					{
						writer = EnterpriseLibraryContainer.Current.GetInstance<LogWriter>();

					}
					catch (ActivationException configurationException)
					{
						//TryLogConfigurationFailure(configurationException);

						//throw;
					}
				}
			}

Thanks - Greg.

Dec 22, 2011 at 7:45 PM

I believe this is still an open issue.  It is actually tracked under Unity.  See here for the issue and a workaround.

Also, see this Stack Overflow answer for a solution that does not require a rebuild.

--
Randy Levy
Enterprise Library support engineer
entlib.support@live.com

Dec 22, 2011 at 9:07 PM

Thanks Randy.

So the code example here - http://unity.codeplex.com/workitem/7206

Do you know where I drop this code into?

Is it directly into the logger project as an extension method?  Or would it go into the common library?

Thanks.

Dec 22, 2011 at 10:04 PM

The sample code would be applied to the SynchronizedLifetimeManager.cs file for the Unity 2.1 Source.  Then you would have to rebuild Unity.  Also, since the Logging Block is dependent on Unity you would have to rebuild Enterprise Library to use the new custom built Unity assemblies.

I would take a look at the other solution since you would not have to rebuild Unity.

Just a note that I haven't tried these approaches so I can't vouch for them.  Hopefully it helps.

 

--
Randy Levy
Enterprise Library support engineer
entlib.support@live.com