Develop Reference

Instantiate different classes with the same name/namespace

I have an architecture consisting of two DLLs and one executable. Both DLLs define a class with the same name and namespace, but potentially different implementations. What I would like to do is to create an object of each of those classes, and have both of them coexist at the same time.
But as we know a picture says more than a thousand words, so here you go:
The surprising thing is: it actually seems to work!
I have implemented a small prototype using lots of reflection to load the DLLs and instantiate the objects.
Now my question is: Why does this work?
Shouldn't there be a problem having both of the classes in the same AppDomain?
Is it safe to do it this way, or did I just get lucky?

A type is more than its class name and namespace. It also includes assembly information to qualify it. You can compare the AssemblyQualifiedName property of any System.Type and see that they are different.

Inaccessible due to protection level -- between 2 different assemblies in C#

Okay, I have a solution I am working on that has 4 different projects in it. One of my projects (a console application) is trying to make reference to some of the classes defined in another project (a library); the only problem is, those called are defined as Internal in the library.
How can I use these Internal classes in other assemblies/projects in the same solution? I added references to the library, but that did not help. It is saying that the protection level is too high (because it is internal, it is only available in that assembly).

You generally shouldn't access something that's internal. That defeats the purpose of declaring it so in the first place. If, however, you do need to...
If you can change the assembly with internal things, either:
Make the classes public, or
Use the InternalsVisibleToAttribute to expose it to just the assemblies you want to.
If you cannot change it, or decide not to, then you can use reflection to access the internal classes. For some portions of what you then do with the class, you should be able to use the dynamic keyword to make access easier and faster than with reflection.

You must use reflection to access the internal classes in other assemblies, but it will be significantly slower and not generally optimizable by the compiler. It's also somewhat complicated.
It is recommended that you expose a public class that wraps your internal classes and methods from the other assembly, or simply switch the internal classes in the other assembly over to public.

Hide class members from everything except another specific assembly

I have two class libraries "MyLibrary.dll" and "MyLibraryEditor.dll" for a Unity runtime and editor extension. There are several class members inside "MyLibrary.dll" that are only intended for use by "MyLibraryEditor.dll".
My first thought was to use the internal keyword because I mistakenly thought that this constrained visibility to a namespace. Instead it is clear that this keyword limits visibility to the assembly.
What is the best way to constrain access to some class members to "MyLibrary.dll" and "MyLibraryEditor.dll" without hurting performance? Also, reflection is not an option.
I am happy to simply not document the functions, but unfortunately Intellisense (and MonoDevelop's equivalent) show these members.

If you want internals in one assembly to be visible from another assembly, you can use the InternalsVisibleTo attribute on the assembly containing the internals. See http://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.internalsvisibletoattribute.aspx:
[assembly:InternalsVisibleTo("MyLibraryEditor")]
That answered, you might want to rethink your architectural design so that you don't need to use it, since it will open up all internals to the other assembly, not only the ones that you want.

You could make the members internal but use [InternalsVisibleTo] to give access to those members to the other assembly. They'd still be visible within the same assembly as well, of course... there's no way of getting round that.
I primarily use InternalsVisibleToAttribute for giving access to internal members to test classes, and would try to avoid doing this for non-test purposes - but sometimes it can be useful.

This is not possible using pure C# concepts. You are two seperate assemblies, that is as far seperate as you can get, and there is no relationship between the two as far as .Net is concerned.
you could do some things with signing or validation to make it so it would be difficult to use one assembly without the other, but not something you can do to prevent visibility of the classes/members.

Can I avoid referencing assemblies from which existing references inherit?

I have an assembly that contains base objects for my Business Objects, and then another assembly that is automatically generated and populated with classes based off a database schema. The classes in the latter assembly all inherit from a class in the former.
The idea I had was that I could reference the generated assembly from other projects, and 'not' the assembly with the base objects thus hiding some of the implementation details and prohibiting people from using these objects.
Unfortunately, I am realizing that I cannot use any of the functionality built into the base unless I reference it as well. So my question is: Is there anyway around this, and if not then is there a design pattern that addresses this that I should be using?

Question sounds slightly backwards. You are hiding your business/domain layer with your data layer? Generally that would be the other way around.
Either way. The issue sounds like you have:
Assembly A
class Bar
Assembly B
class Foo : Bar
Assembly C must reference both A and B to use Foo.
The design principle to follow would be to favor composition over inheritance.
Rather than Foo inheriting from Bar, Foo could contain an instance of Bar and expose what methods make sense for Foo. This is all assuming that Foo is not actually a specialized version of Bar.

If you really don't want to expose the base classes to others (think extensibility), then you probably should move the bases into the same assembly as the concretes.
If you still need the assemblies separated, you can still make the bases internal, and then set the InternalVisiblesToAttribute on the base class assembly:
(In AssemblyInfo.cs)
using System.Runtime.CompilerServices;
[assembly:InternalsVisibleTo("ConcreteClassAssembly")]

Enforcing type visibility between namespaces in C#

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#?

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.

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.