Enforcing type visibility between namespaces in C#

Question

I have the idea that it might be useful to enforce type visibility between namespaces rather than assemblies (internal) in C#.

It would seem that such a concept would assist developers working with a codebase, ensuring the correct types are used in places where another internal type supplying similar functionality is available, but would result in "architectural" disadvantages (unwanted dependencies etc).

Do others think this would be useful and is it currently possible? If not why not?

Also, would the concept of preclusions - the ability to specify negative constraints on references between namespaces and / or assemblies be a useful addition to C#?

Answer 1

A type is strongly bound to the assembly in which it is defined. A namespace is not, it can appear in multiple assemblies. System.Configuration for example.

Let's assume for a moment that the metadata format for an assembly would be changed (-1 billion points) to store attributes for a namespace. Those attributes would still have to be stored in an assembly because that's the storage unit for metadata. Now you have to deal with the possibility that the CLR loads another assembly and finds the same namespace but with conflicting attributes. How could it possibly resolve that?

More seriously, how would you prevent external code from simply using the same namespace and attributes to suddenly get access to implementation details that were meant to be private. This completely destroys the value of having the internal keyword.

Answer 2

You could make them public, tag them with a custom attribute, and then add a FxCop rule to check for accesses from the outside of the namespace.

This doesn't securely enforce the restriction and fails when the member is accessed with reflection, but if it's only about policy/codingstyle this should be enough.

I think there is also an existing attribute to hide members from Intellisense which you might use in conjunction with your custom attribute.