Closed BrunoJuchli closed 9 years ago
I've pushed a 3.0.6 package to NuGet that supports internal interfaces if the InternalsVisibleToAttribute
has been set to DynamicProxyGenAssembly2.
If your assembly is strong named the attribute must include the PublicKey:
[assembly: InternalsVisibleTo("DynamicProxyGenAssembly2, PublicKey=0024000004800000940000000602000000240000525341310004000001000100c547cac37abd99c8db225ef2f6c8a3602f3b3606cc9891605d02baa56104f4cfc0734aa39b93bf7852f7d9266654753cc297e7d2edfe0bac1cdcf9f717241550e0a7b191195b7667bb4f64bcb8e2121380fd1d9d46ad2d92d2d15605093924cceaf74c4861eff62abf69b9291ed0a340e113be11e6a7d3113e92484cf7045cc7")]
that was fast. Thanks! :)
Cannot interface-propxy
internal
interface even though assembly is marked withas stated in the Documentation
Container Configuration
Exception
(Hint: Moq-ing
internal
interfaces from the same assembly works (=> in a different test assembly), so the attribute is set correctly).Issue-Analysis
RegistrationExtensions.EnsureInterfaceInterceptionApplies
contains a checkThis check is not in line with documentation, because
IsVisible
only returnstrue
if the type ispublic
, not when it'sinternal
combined withInternalsVisibleToAttribute
.I don't think that there's a possiblity to check for whether some
Type
is visible to anotherAssembly
due toInternalsVisibleToAttribute
, so i suggest just getting rid of theIsVisible
check.Comment: As the exception is occuring during resolving (not when building the container), the failure-case will still be detected at the exact same time. Only potential downside is, that Castle DynamicProxy's exception message might not be as verbose. In one part it's more verbose, however, because it states that you can fix it by adding an
InternalsVisibleToAttribute
...