[jira] [Commented] (LUCENENET-480) Investigate what needs to happen to make both .NET 3.5 and 4.0 builds possible

["Prescott Nasser (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/LUCENENET-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13295135#comment-13295135 ] 

Prescott Nasser commented on LUCENENET-480:
-------------------------------------------

Attempting to compile the trunk in 3.5 yields 54 errors, however many of them are the same thing:

1. ISet doesn't exist in 3.5. I believe we can safely change all ISet to HashSet.
2. SortedSet doesn't exist in 3.5. There is no drop in replacement, we could either create a SortedSet class that inherits HashSet, we have to be careful how we implement this to avoid too big a penalty in sorting
3. Two internal Func<>'s will have to be turned into actual methods, not anonymous functions
4. ThreadLocal - Digy nicely included a class ThreadLocal that we could put compile flags around if compiling for version 3.5
5. Task in the parallelmultisearcher would need to be replaced, I'm not sure atm how to accomplish that - we could remove this searcher all together in the 3.5 binary.

Please provide further comments if you have any, otherwise I'm going to try and work on these this weekend

                
> Investigate what needs to happen to make both .NET 3.5 and 4.0 builds possible
> ------------------------------------------------------------------------------
>
>                 Key: LUCENENET-480
>                 URL: https://issues.apache.org/jira/browse/LUCENENET-480
>             Project: Lucene.Net
>          Issue Type: Task
>          Components: Lucene.Net Contrib, Lucene.Net Core, Lucene.Net Demo, Lucene.Net Test
>    Affects Versions: Lucene.Net 2.9.4, Lucene.Net 2.9.4g, Lucene.Net 3.0.3
>            Reporter: Christopher Currens
>
> We need to investigate what needs to be done with the source to be able to support both a .NET 3.5 and 4.0 build.  There was some concern from at least one member of the community ([see here|http://mail-archives.apache.org/mod_mbox/lucene-lucene-net-dev/201202.mbox/%3C004b01cce111$871f4990$955ddcb0$@fr%3E]) that we've alienated some of our user base by making such a heavy jump from 2.0 to 4.0.  There are major benefits to using 4.0 over the 2.0-based runtimes, specifically FAR superior memory management, particularly with the LOH, where Lucene.NET has had major trouble with in the past.
> Based on what has been done with Lucene.NET 3.0.3, we can't (easily) drop .NET 3.5/3.0 libraries and go back to 2.0.  HashSet<T> and ISet<T> is used extensively in the code, that would be a major blocker to get done.  I suppose it could be possible, but there hasn't been a whole lot of talk about what runtimes we intend to support.  The big change between lucene 2.x and 3.x for java was also a change in runtimes, that allowed generics and enums to be used in the base code.  We have a similar situation with the API (it's substantially different, with the addition of properties alone) for this next version of Lucene.NET, so I think it's reasonable to at least make a permanent move from 2.0 to 3.5, though that's only my opinion, hasn't been discussed with the committers.
> It seems that supporting 3.5 and 4.0 should be fairly easy, and is a decent compromise in supporting both a 2.0 and 4.0 runtime.  At the very least, we should try our best to support it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira