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.