Logging currently is done by calling the static DevExpress.CodeRush.Diagnostics.ToolWindows.Log and DevExpress.CodeRush.Diagnostics.Menus.Log objects. It would be better if we could abstract ourselves away from that by logging to our own logger.

It looks like those static objects use the DevExpress.CodeRush.Diagnostics.LogObject under the covers and construct it by passing a string category corresponding to the namespace, like:

new LogObject("ToolWindows");

Can we create our own category?

As it turns out, logging in DXCore is not multi-threaded. I opened issue B32053 with DevExpress due to a one-time exception I got as DXCore was shutting down and it looks like the problem was due to the mini web server's request handling thread trying to log something from a different thread.

Their proposed solution is to use their SynchronizationManager to log data instead of logging things directly. Here is some sample code:

using DevExpress.DXCore.Threading; ..... delegate void LogHandler(string title, string text); void LogSomething(string title, string text) { Log.SendMsgData(title, text); }

LogHandler handler = new LogHandler(LogSomething); SynchronizationManager.BeginInvoke(handler, new object[] { someTitle, someText });

When the logging gets abstracted out to our own logger, we should also implement this so the logging is done in a thread-safe fashion.

I've started doing this but it turns out to be difficult to test code that uses the SynchronizationManager class. For example, this passes:

public delegate void WriteLogMessageHandler(string message);

[TestMethod] public void Enter_EntersLog() { string changed = null; WriteLogMessageHandler del = delegate(string s) { changed = s; }; IAsyncResult result = del.BeginInvoke("changed", null, null); result.AsyncWaitHandle.WaitOne(); Assert.AreEqual("changed", changed); }

However, if you switch the IAsyncResult line to...

IAsyncResult result = SynchronizationManager.BeginInvoke(del, new object[] { "changed" });

...then the test never finishes. It's like the method never actually got invoked.

I will submit a question to DevExpress and see what they have to say.

The question has been posed to DevExpress here: http://www.devexpress.com/Support/Center/p/Q204445.aspx

It turns out I'm doing the right thing using SynchronizationManager, but SynchronizationManager can't be used outside of a Visual Studio environment. I've figured out some test code that allows me to use Typemock Isolator to mock calls to SynchronizationManager so the tests will properly run and simulate what would actually happen in a real environment.

Using Typemock Isolator's "DynamicReturnValue" functionality, I can set up a method that I'd rather call instead of SynchronizationManager.BeginInvoke like this:

// The SynchronizationManager static class in DXCore can't run outside a // DXCore environment. This DynamicReturnValue method can be used to swap // calls to the SynchronizationManager for unit testing purposes. // // Note that in our version we are blocking on the wait handle so the call // finishes. This doesn't happen in real SynchronizationManager calls, but // since we're trying to test the results of the call and we don't want // to Thread.Sleep in every test while we wait, we'll just make the call // synchronously. private delegate object SynchronizationManagerMethodCall(object[] parameters);

private static IAsyncResult SynchronizationManagerBeginInvoke(object[] parameters, object context) { Delegate exec = parameters[0] as Delegate; SynchronizationManagerMethodCall call = delegate(object[] callParams) { return exec.DynamicInvoke(callParams); }; object[] paramArray = parameters[1] as object[]; IAsyncResult result = call.BeginInvoke(paramArray, null, null); result.AsyncWaitHandle.WaitOne(); return result; }

Then in the test setup method, we can tell Typemock Isolator to always substitute calls to SynchronizationManager.BeginInvoke with our static method:

[TestInitialize] public void TestInitialize() { DynamicReturnValue beginInvoke = new DynamicReturnValue(SynchronizationManagerBeginInvoke); using (RecordExpectations recorder = RecorderManager.StartRecording()) { IAsyncResult dummyResult = SynchronizationManager.BeginInvoke(null, null); recorder.Return(beginInvoke); recorder.RepeatAlways(); } }

Doing that allows us to get around the runtime requirements of SynchronizationManager and test the code that consumes it.

Logging is now abstracted behind classes in the CR_Documentor.Logging namespace. Thread safety has been added via SynchronizationManager calls so logging should work regardless of the thread it's called from.

Upgraded to Typemock Isolator 5.3 during the fix.