Some of you may read the title of this post and think to yoursefl “Duh”!, but this sneaky little feature caught up to me. I have my library developed in C#, and I have 2 layers of base classes for all ASP.NET Pages as well as user controls, so every page and user control in my app will have certain properties and functionality. I wrap a template around the content of every page. To do this I have a <div /> with id of “pageContent”. I reference this from the base classes. I expose this HtmlGenericControl with a property named “PageContent”. Works great and is self-documenting. Made a page with J# and it works great. Made a page with VB (see my IIS reinstall post), and I get this wierd compilation error. Doh! PageContent is referenced, and VB sees pageContent first, tries to write to that protected member and bombs on compilation. HELLO!! That’s a capital P, not a lowercase p!! So now I have to change the property or the member name. No biggie. Besides, it’s not a good practice to have member names vary only by case, but this one had slipped past me.
I’ve learned an important lesson. Just by writing .Net code, I can’t ensure that all .Net languages will be able to use it. In this case, only case-sensitive languages would be able to use it, and case-insensitive languages (like VB) would bomb out. I’ll have to do some more testing with VB to ensure that my project can reliably be extended with VB.
I did learn something rather interesting about the code interoperability feature and IL. The library is C#. The page is VB inheriting from a base class written in C#. Actually the VB page is just inheriting from IL code. Where the PageContent property was referenced was actually in C#, and the property and protected member are declared in C#, but since the VB page was executing, the IL library of mine was compiling according to VB’s rules. Very interesting.