We can clean those up, once we archive a port status such that we can port patches over vs. a whole release. This is because a whole release port depends heavily on deltas between releases. Thus, any extra code changes will make a whole port harder.
-- George -----Original Message----- From: Eric Nicholson [mailto:[email protected]] Sent: Tuesday, October 13, 2009 11:24 AM To: [email protected] Subject: CLS Compliance and Compiler Warnings I apologize if this has been asked already, but is there any effort underway or interest in getting Lucene.NET to compile as a CLS-Compliant assembly? What about reducing or eliminating the compiler warnings? I know both of these would make my build environment a little saner. Looking at the code it looks like there is not much involved in getting it to compile clean. I noticed a few things in particular: * unused variables - warning * protected internal fields with different case than a public property or class - non-cls compliant * public consts that start with underscore - non-cls compliant Is there some reason the code needs to stay exactly the way it is (like maintaining parity with the Java project)? It seems like a pretty small amount of work, I'd be happy to submit a patch if anyone thinks it would be helpful. Best Regards, Eric Nicholson
