Fix TypeLoadException in StaticProxyFactory when class has not visible interfaces

[hazzik]

Fixes #1643

[fredericDelaporte]

Shouldn't it emit a warning there?
It is not the dynamic proxy (which should be removed once lazy properties are handled by static proxies).

Something like "Interface {0} is not accessible, its members may not be proxified for entity {1}. If they are explicitly implemented and access directly some internal state of the entity, unexpected outcome may occur.".

Due to the way NHibernate's proxies work, it could even be considered that trying to proxify entities implementing some internal interfaces is an error. But since the old proxies were not detecting the case and were letting silently these members unproxified, it would be a breaking change doable only for 6.0.

(It is an error because if some proxy instance is given back to some methods of the assembly holding the internal interfaces, it may call those methods. If they access directly internal or private state, they will then access the inherited proxy state instead of the delegated entity state handled by the proxy.)

[fredericDelaporte]

Well, the error case would also require, for actually being an error, to have these methods explicitly implemented. So unless this additional condition can be reliably detected, it should not be rejected as an error.

(Proposed warning message updated.)

[hazzik]

I don't think we need any warnings here.

[hazzik]

There is a possibility to improve that behaviour in a future major or minor version.

1. Detect that assembly has InternalsVisibleToAttribute pointing to the assembly containing static proxy (it will require to settle the assembly name, as now it's dynamic).
2. The problem with nested classes and interfaces - it is hard to properly identify if the class would be actually visible if InternalsVisibleToAttribute applies. To properly detect that it would require to traverse the nesting tree.
3. Emit warning once per proxy type suggesting to make interfaces public or apply InternalsVisibleToAttribute.

[fredericDelaporte]

I am not really convinced it is worth bothering with InternalsVisibleToAttribute. It works only if both assemblies are signed, or both unsigned.

And well, the interface being internal is not a trouble if none of its members is declared explicitly: they will then be proxified as public virtual members of the class. It is only if the interface is internal and if some of its members are explicitly implemented that a trouble can occur, because those members will not be proxified. (But if their implementations only use other visible members, proxified, then it will still not cause any trouble.)

[hazzik]

Agree

It works only if both assemblies are signed, or both unsigned.

We could build either signed (with known key) or unsigned assembly depending on the circumstances, it should not be a problem.