The assembly name set as InternalsVisibleTo parameter is case insensitive.
If the assembly name is set to MyControlForms.iOS, the compiler compiles fine (it authorize the use of any internal property), but accessing any internal property crashes at runtime with
System.FieldAccessException: Field `MyControlForms:MyInternalProperty' is inaccessible from method `MyControlForms.iOS.MyControlRenderer...
It should not crash, or the compiler should fail to compile.
In Xamarin Studio 6.2.1 build 3, if the case of the assembly name does not match, I get a build failure saying that the member is inaccessible due to its protection level. If I correct the case of the assembly name the test application builds.
Can you provide a more specific example of some code (or ideally a pair of projects) where this failure occurs? I can't reproduce it.
Katelyn, I think that's the bug. The runtime loader treats the InternalsVisibleTo value as case sensitive which probably shouldn't (requires checking on .net)
So the intended behavior is not "It should not crash, or the compiler should fail to compile." but "it should work"? I'll see how this works on Windows.
I'm on vs2015 windows not xs.
Don't know what the c# spec directs here.
OK, I can confirm that in VS2015 on windows, the case of the argument to InternalsVisibleTo is ignored. It still fails as expected if the name is entirely incorrect. I assume this is done to make sure things still work if win32 case insensitivity causes the assembly name to get messed up.
So to match this behavior, I think the mono runtime would need to change, in addition to the mono compiler.
@softlion What version of Xamarin.iOS are you using?
I was using the beta version which is the stable version since a couple of days.
OK, 15.1? Thanks. I'll chase this down.
Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on GitHub
to continue tracking issues. Bugzilla will remain available for
reference in read-only mode. We will continue to work on open Bugzilla
bugs, copy them to the new locations as needed for follow-up, and add
the new items under Related Links.
Create a new report for Bug 54388 on Developer
Community or GitHub if you have new information to add and do not yet see a matching
In special cases on GitHub you might also want the comments:
GitHub Markdown with public comments
Our sincere thanks to everyone who has contributed on this bug tracker
over the years. Thanks also for your understanding as we make these
adjustments and improvements for the future.