I can set up protected properties, I can set up internal properties, and I can set up protected internal properties. However, I cannot set up properties which are the strict intersection of protected and internal (in C# called "private protected"). As a reminder, "protected internal" is the union of protected and internal.
Since protected and internal both work, I see no reason why "private protected" shouldn't work as well.
internalvirtualstringInternal=>thrownewNotImplementedException("Internal not mocked");
protectedvirtualstringProtected=>thrownewNotImplementedException("Protected not mocked");
protectedinternalvirtualstringProtectedInternal=>thrownewNotImplementedException("ProtectedInternal not mocked");
privateprotectedvirtualstringPrivateProtected=>thrownewNotImplementedException("PrivateProtected not mocked");
// These work.Console.WriteLine(mock.Object.PropValue_Internal);
// This will throw a NotImplementedException with the message "PrivateProtected Not mocked".Console.WriteLine(mock.Object.PropValue_PrivateProtected);
The text was updated successfully, but these errors were encountered:
Like you said, protected internal is the union of the two: protected OR internal. private protected on the other hand is the conjunction: protected AND internal. You only have access to such members from inside their own assembly, and only from their declaring type or a subtype or (IIRC) a nested type.
Outside the assembly where such members are declared, they're essentially the same as private members... and you're probably not surprised why you cannot set up those.
If I have a private protected member in assembly A, and assembly B is a friend, then that member is in fact accessible to derived types in assembly B, is it not? This is much different than private.
How is this any different for Moq? If I've got the InternalsVisibleTo("DynamicProxyGenAssembly2...") attribute on the assembly, thereby giving Moq access to the internals in my assembly, that's explicitly saying that I want Moq to be able to access (and thereby potentially override) internal members.
So really, private protected shouldn't be any less visible than internal from the perspective of Moq. The only difference between private protected and internal is that we've got the extra protected restriction. However, Moq already clearly wants to address the protected situation, which is the whole reason for the Moq.Protected namespace.
Ah yes, I believe you're correct. And, come to think of it, I suspect the reason why this currently doesn't work is a different one: support for intercepting private protected methods was added only recently to DynamicProxy (upon which Moq v4 is built); see castleproject/Core#535. This enhancement will be released in DynamicProxy v5, once we update our dependency in Moq, such methods should be supported, too.
Thanks @stakx . Can you provide any idea of when DynamicProxy v5 will be released? Seems like there's hasn't been much activity there since March, and there aren't any open issues in the 5.0.0 milestone.