I will probably do that tomorrow. I have it running and decided on a...slightly different solution than before, but it limits the project to only have the capability to be build using the .NET 4 tool chain. I don't foresee this as being an issue, since VS2010 Express and the .NET 4 SDK are available and would allow it to build just fine. The benefit of doing it this way is that there are no added project or solution files, the build chain doesn't have to be modified *too* much, and you can switch between build 3.5 and 4.0 in visual studio by just changing the build configuration (though it doesn't show the change in the project properties, for some reason).
I'll get the updated code, build scripts and dependencies committed to SVN tomorrow (okay, or Monday, but I'll try for tomorrow). On Sat, Jul 14, 2012 at 11:41 AM, Prescott Nasser (JIRA) <j...@apache.org>wrote: > > [ > https://issues.apache.org/jira/browse/LUCENENET-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13414471#comment-13414471] > > Prescott Nasser commented on LUCENENET-480: > ------------------------------------------- > > Chris if you have the code running, is there any harm in integrating it > back into the branch? > > > 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 > > Assignee: Christopher Currens > > Attachments: SortedSet.cs > > > > > > 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 > > >
