Unify namespaces in Kentico.Kontent.Delivery.Abstractions

[Simply007]

Motivation

Unify all namespaces in Kentico.Kontent.Delivery.Abstractions assembly to the same namespace.

Based on #300 (comment)

Related to #287

Checklist

• Code follows coding conventions held in this repo
• Automated tests have been added
• Tests are passing
• Docs have been updated (if applicable)
• Temporary settings (e.g. variables used during development and testing) have been reverted to defaults

How to test

If manual testing is required, what are the steps?

[Simply007]

@petrsvihlik - I have bad news - I have found one class - DeliveryOptionsExtensions - that used sub-namespace Kentico.Kontent.Delivery.Abstractions.Extensions.

I wanted to fix single namespace requirement and cover this rule in tests.

For now, I have fixed this, but I would like to hear your opinion on this first.

[petrsvihlik]

Yeah, it makes sense to unify this one and have it covered by a unit test - a good idea btw.

Regarding the prevention of problems caused by referencing multiple versions of the same package (e.g. through nested dependencies). The only good solution is to be 100% backwards compatible with older versions of the same package. This requires extreme diligence when designing the APIs and ideally a very thorough review process.

Just for the sake of completeness - there is another way to prevent assembly conflicts and that's called strong-naming. I even wrote an article on that a couple of years ago. Even MSFT says that "Strong-names are leftover from previous eras of .NET" and acknowledges that "the majority of third-party assemblies do not need strong names". Even though, MSFT says that publicly published .NET libraries should be strong-named as not strong-naming a .NET library excludes anyone who does need to strong-name their application or library from using it. But even if you decide to start strong-naming the assemblies, you have no control over other publishers of libraries that depend on your library. You can't force them to reference strong-named assembly.
In other words, it might be a good idea to start signing the assemblies in case someone wants to use them in an application they have 100% control of. But it's not a solution to this problem in general.