Avoiding Circular Dependencies

NathanZaugg — Mon, 09 Jun 2008 21:45:06 GMT

The term "circular dependency" may be foreign to some programmers (especially if you do Java as it is a pretty common practice). However, anyone who has done some scripting for a referential database knows that you have to run scripts in a certain order. Running scripts out of order causes errors when you run. The interesting trick is that if you run that same incorrectly-ordered DDL script again and again you will eventually get it to run without errors. If you were unaware of the order being incorrect and thought to yourself in that moment "Stupid database!" then this blog post is for you!

What is a circular dependency?

It is simply two libraries that use each other (either directly or indirectly) as shown below:

Figure 1: Circular Dependency

Figure 2: Complex Circular Dependency

The complexity of a circular dependency may vary. If you are using Visual Studio and have all of your projects loaded into a single solution AND you add Project References (Right click on project -> Add Reference -> Projects Tab -> {Project Name}) then the IDE will not allow you to create Circular Dependencies. In fact, this is a good practice as Visual Studio will ensure the correct build order.

Why are circular dependencies bad?

Just like our Database example above, a circular dependency makes it so you can not guarantee that your application has the latest code. That is a big deal! Here is why:

I make changes to Application 1 (in Figure 2)
I build my project, The changes I made in Application 1 may or may not have gotten into Application 2 (depending on build order). It may have taken a copy of the compiled code that was left over from the last time I built.
Application 2 depends on this new functionality to provide services to Application 3; This functionality will not work correctly with this build.
Application 3 may or may not depend on these same services to provide back to Application 1

As you can see in this scenario, there is no such thing as a "correct" build order when there are these circular dependencies. The only way you can arrive at the correct version of the code is to build it as many times as there are nodes in our circle. That would mean for Figure 1 that we would need to build twice and three times for Figure 3. Some of these dependencies can get really ugly! Here is some actual code running in an actual company that I did analysis on some time ago using a tool called Structure 101.

How do I fix circular dependencies?

There are some steps to take to solve even the most complex tangles! They all involve refactoring your code though.

Refactor common code into a "base" dependency; I usually call this "Common" (figure 3). BEST SOLUTION
Remove code that is unused. In the tangles shown above many of them are using deprecated/unused code.
Duplicate the sections of code used. This should be seen as a last resort but given the choice between code duplication and circular dependencies, I take code duplication ever time!

Figure 3: Refactor a Common

Summary

There are two kinds of design concepts for nTier (and other types of architectures as well) called Logical Layout Design and Physical Layout Design. The Logical Layout is simply that your software occupies the same project/package but leverage different classes. In contrast Physical Layout Design forces each tier to be separated into different Projects/Packages. So long as we are careful to manage the dependencies between these packages from the start this is the preferable way to code. While the logical layout does not suffer from the dependency problem eventually you may wish to break these classes apart and find that there are a lot of inner-dependency that should not exist simply because they occupied the same project. Remember to keep it clean!

Debugging with Process Monitor

NathanZaugg — Wed, 05 Dec 2007 21:45:35 GMT

Now I am not much of a low-level debugger type. I've seen people use WinDbg like it was an extension of their hand! I am not one of those people but I would sure like to be. Lately I have been working on a project that does some pretty tricky code hooking of some User Mode API calls in Kernal32.dll. Specifically I was hooking calls to CreateFileA, CreateFileW, DeleteFileA, and DeleteFileW in Kernel32.dll. Everything was working as expected but when I drag a file in Windows Explorer I can see the CreateFile call being made in the Kernel, but I was not trapping those calls.

Of course, I looked in the call stack in Process Monitor, but without debug symbols, this information is pretty much useless. All I could see is that Kernal32.dll called down to a lower kernel call and was eventually caught as CreateFile. Well, I recently tried to get the symbols to work in Process Monitor and ran into some difficulty. First, I needed the latest version of WinDbg installed as it uses the latest version of DbgHelp.dll. Secondly the symbol path (as unusual as it is already in WinDbg) is slightly different. For some reason Process Monitor needs to know not only where the symbols are but also the path to the executables that match those symbols. I had to use the path: srv*E:\Symbols\*http://msdl.microsoft.com/download/symbols;E:\Windows\;E:\Windows\system32;E:\Windows\system32\Drivers

My Symbol Settings

My Stack Trace now shows with symbols

So my problem was that it is really making a call to CopyFileExW which uses the Kernel's CreateFile function as part of the work it is doing. Process Monitor doesn't really know what the "parent" call for the stack is in the User Mode as it is a kernel level hook. So while it looks like the call to CreateFileW in Kernel32.dll should have hooked this call, Kernal32.dll is actually a user mode dll and is just a shim to pass the call back to the Kernel to do the work.

Fun Stuff!

Search results matching tags 'Tools' and 'Debugging'