Github user NightOwl888 commented on the issue:
https://github.com/apache/lucenenet/pull/203
I also apologize for the delayed response.
> Is there anything I can help with?
Yes, there is. I have been working on cleaning the API up and making it
more .NET-like.
### CLS Compliance
Part of this process is making the whole project CLS compliant, so it can
be consumed by VB and other .NET languages.
1. Currently, there are only 8 remaining CLS-related warnings that need to
be addressed. But before we fix them, it would be nice if we could ensure that
the fixes don't cause any negative effects - in other words, we need as many
tests fixed as possible (namely in Lucene.Net.Core). If you could help with the
debugging efforts, that would be great.
2. In addition, there was a bit of a snag with icu-dotnet because *it* is
not marked CLS Compliant. Therefore, by default none of its types are CLS
Compliant and cannot be exposed publicly in Lucene.Net (including Enum types).
I would appreciate it if you mark the assembly with the CLSCompliant attribute.
I reverted the ThaiAnalyzer back to its previous state and adapted the
ICUBreakIterator to work with it - seems to work pretty well, for now (and it
is now CLS Compliant). Let me know if/when you have a rule-based break iterator
so I can ensure compatibility.
### Collation
Also, I ended up marking the Collation-related types CLSCompliant(false). I
am now pretty much convinced that there is no way we can get them working with
icu-dotnet, based on [this
documentation](https://github.com/apache/lucene-solr/blob/releases/lucene-solr/4.8.0/lucene/analysis/common/src/java/org/apache/lucene/collation/CollationAttributeFactory.java#L65-L68).
It also seems to indicate that the collation functionality in the Analysis.ICU
package is better (and it is based on ICU 4J, so it should work). Anyway, my
thought is to add `FEATURE_COLLATION` as an option and leave it out of the
compile, since it is pretty much useless unless we port over a large part of
the JDK to make it work. So, ignore those failing tests for the time being.
### Test Framework
I also reverted the changes to OLD_FORMAT_IMPERSONATION_IS_ACTIVE and made
it static again. There really doesn't seem to be a reasonable way to ensure
this flag is read from everywhere if it is non-static. This fixed more than a
dozen failing tests. I am working on finishing up the Codec functionality now -
specifically the randomizing of codecs and the IgnoreCodecs functionality.
But, I could use some help. The test framework has been a major source of
test failures. Many parts of it were not translated correctly or are still
unfinished. IMO, the test framework should be reviewed line-by-line to ensure
that the equivalent functionality is implemented.
### Documentation Comments
Also, as I [mentioned
above](https://github.com/apache/lucenenet/pull/203#issue-203023160), some of
the documentation comments need to be finished. Mostly, they are malformed so
they don't show up in Visual Studio, but there is also some documentation that
is either incorrect or has not been brought over from Lucene.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
