Implicit dependencies

When you work on a C# solution, sometimes it's quite easy to find dependencies between parts of the solution. For example, to find all uses of a class, in Visual Studio you just have to right-click on its name and select "Find all references". But sometimes dependencies and relationships are not that easy to find. Here i decided to list cases which may require special attention when you are refactoring your code and don't want to introduce breaking changes. This is based on my personal work experience.

1.Unity framework may introduce implicit dependencies. Once I was investigating a class and was trying to locate the place in the code where constructor of the class was being called. However, the Find all references feature did not yield ANY results. Which puzzled me much, because I knew the class WAS working and therefore its constructor had to be called somewhere. It turned out eventually that the constructor, even though it wasn't parameterless, was being called implicitly by the Unity framework. This was made possible by registering all types used as parameters of the constructor with Unity prior to use of the class.

So, if you use Unity (or may be some other IoCC), check if types of all parameters of the constructor are registered with Unity. If this is the case, the constructor might be called implicitly from inside the Unity framework.

2.Consider the scenario where you are refactoring your code by simply renaming classes, methods or properties. You are pretty sure you have accounted for all places where those names are used. Otherwise the project would simply not build, right? Wrong. A class may be used in a serialization/deserialization procedures when communicating with external parties, e.g. in WCF or RESTful service scenarios. In this case, the solution WILL compile, but at runtime you will get an error (or even worse, silent bug) when your code tries to deserialize a message received from an external party where they did not do the matching renamings.

So, when you rename anything, make sure it is not used in serialization/deserialization. If it's not, you are free to rename. If it is, you'll have to coordinate your refactoring with the party or perties that send you or receive from you serialized messages.

I will be adding more things like these here as soon as I discover or get to know about them.