Details

    • Type: Task Task
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: Lucene.Net 2.9.2, Lucene.Net 2.9.4, Lucene.Net 3.0.3
    • Fix Version/s: Lucene.Net 2.9.4
    • Component/s: Lucene.Net Core
    • Labels:

      Description

      VS2005 is quite out of date now and there are many new improvements in VS2010. You can still leave the framework support at .NET 2.0 if you like.

      1. lucene.zip
        2.54 MB
        Wyatt Barnett

        Activity

        Hide
        Prescott Nasser added a comment -

        In Branch LuceneNet_2_9_4g

        Show
        Prescott Nasser added a comment - In Branch LuceneNet_2_9_4g
        Hide
        Prescott Nasser added a comment -

        probably should wipe out the vs2010 branch in all honesty...

        Show
        Prescott Nasser added a comment - probably should wipe out the vs2010 branch in all honesty...
        Hide
        michael herndon added a comment -

        I would suggestion just creating the 2008 solution files.

        The project files (unless it has version specific msbuild targets like in web projects) are generally compatible for both solutions.

        If they do have version specific msbuild targets: its not terribly hard to do conditionals so that the project files work for both vs 2008 & vs 2010 solution files.

        Show
        michael herndon added a comment - I would suggestion just creating the 2008 solution files. The project files (unless it has version specific msbuild targets like in web projects) are generally compatible for both solutions. If they do have version specific msbuild targets: its not terribly hard to do conditionals so that the project files work for both vs 2008 & vs 2010 solution files.
        Hide
        Troy Howard added a comment -

        I did another version of this for the 2.9.2-incubating-RC2 build.

        Have a look at:

        https://svn.apache.org/repos/asf/incubator/lucene.net/tags/Lucene.Net_2_9_2_RC2

        I placed all .sln files, as VS2010 format, in a ~/build/ directory, and updated the Release profiles to build to a ~/bin/ and ~/doc/ directories. This makes for better releases packaging structure and consolidates all solution files to a single directory (no more hunting them down).

        I made my changes on that branch, but could merge them in somewhere (vs2010 branch or trunk) if we like this layout/design. We also really need to address naming and namespaces. They are all over the place. I had to update a lot of things to make it all make sense. Test.dll is really inadequate naming!! I'll say more on namespaces later, in another context...

        Regarding VS2010 files in general, Neal brings up an interesting problem case: MsBuild 2.0 or 3.5 pre SP1 can't build a VS2010 file (even if it's target version is set to 2.0). We either need to set our standard high for end users (require .NET 3.5 SP1 or higher, and/or Visual Studio 2010), or provide VS2008 compatible versions of the solution and project files.

        Show
        Troy Howard added a comment - I did another version of this for the 2.9.2-incubating-RC2 build. Have a look at: https://svn.apache.org/repos/asf/incubator/lucene.net/tags/Lucene.Net_2_9_2_RC2 I placed all .sln files, as VS2010 format, in a ~/build/ directory, and updated the Release profiles to build to a ~/bin/ and ~/doc/ directories. This makes for better releases packaging structure and consolidates all solution files to a single directory (no more hunting them down). I made my changes on that branch, but could merge them in somewhere (vs2010 branch or trunk) if we like this layout/design. We also really need to address naming and namespaces. They are all over the place. I had to update a lot of things to make it all make sense. Test.dll is really inadequate naming!! I'll say more on namespaces later, in another context... Regarding VS2010 files in general, Neal brings up an interesting problem case: MsBuild 2.0 or 3.5 pre SP1 can't build a VS2010 file (even if it's target version is set to 2.0). We either need to set our standard high for end users (require .NET 3.5 SP1 or higher, and/or Visual Studio 2010), or provide VS2008 compatible versions of the solution and project files.
        Hide
        Troy Howard added a comment -

        Pushing this out to 2.9.4 release because it will require a commit that will put us beyond the existing 2.9.2 tag. The 2.9.2 release should be made from that tag with no further modifications.

        Show
        Troy Howard added a comment - Pushing this out to 2.9.4 release because it will require a commit that will put us beyond the existing 2.9.2 tag. The 2.9.2 release should be made from that tag with no further modifications.
        Hide
        Prescott Nasser added a comment -

        I have to agree with Paul on this one. It's a relatively minor addition that lowers the barrier to entry. There are a number of other demo / samples that I think we should be building and including to lower the barrier even further - but they are low priority at the moment for sure.

        From Paul Hadfield:

        "I'm not sure sure, as a relative newbie to Open Source projects (in using) I'm amazed at how difficult the learning curve is when downloading projects. Just to build things you have to install 'x' other things, stand on one leg and press enter with your elbow from the other side of the room.

        In light of everything else that appears to be needed you may be right that it's not a number one priority, but making people's lives easier will always aid adoption and may in fact help gain more developers giving input"

        Show
        Prescott Nasser added a comment - I have to agree with Paul on this one. It's a relatively minor addition that lowers the barrier to entry. There are a number of other demo / samples that I think we should be building and including to lower the barrier even further - but they are low priority at the moment for sure. From Paul Hadfield: "I'm not sure sure, as a relative newbie to Open Source projects (in using) I'm amazed at how difficult the learning curve is when downloading projects. Just to build things you have to install 'x' other things, stand on one leg and press enter with your elbow from the other side of the room. In light of everything else that appears to be needed you may be right that it's not a number one priority, but making people's lives easier will always aid adoption and may in fact help gain more developers giving input"
        Hide
        Neal Granroth added a comment -

        I vote to cancel this item. We should not burden the source tree with a VS2010 solution file. Those that want one should create and use a local solution file on their build machine.

        Show
        Neal Granroth added a comment - I vote to cancel this item. We should not burden the source tree with a VS2010 solution file. Those that want one should create and use a local solution file on their build machine.
        Hide
        Wyatt Barnett added a comment -

        Definitely agree there is alot more we could do with the layout – this was a case of a light touch/proof of concept. I spent perhaps a half hour putting this together, and most of that was testing to ensure it was backwards compatible.

        I'd generally vote we get that whole automated conversion bit sorted then structure the project around that since that is the proverbial tall pole in the tent.

        Show
        Wyatt Barnett added a comment - Definitely agree there is alot more we could do with the layout – this was a case of a light touch/proof of concept. I spent perhaps a half hour putting this together, and most of that was testing to ensure it was backwards compatible. I'd generally vote we get that whole automated conversion bit sorted then structure the project around that since that is the proverbial tall pole in the tent.
        Hide
        Aaron Powell added a comment -

        Looks good, fired it up on my machine under vs2010 and it works no worries.

        Small point - would it be a good idea to put the BUILD.txt file in the root?

        Show
        Aaron Powell added a comment - Looks good, fired it up on my machine under vs2010 and it works no worries. Small point - would it be a good idea to put the BUILD.txt file in the root?
        Hide
        Wyatt Barnett added a comment - - edited

        I took a run at re-organizing the project a bit to make it a bit more user-friendly. You can now:

        1) open the project in the visual studio version of your choice – 2005, 2008 and 2010.
        2) update and commit in said version
        3) debug the tests from within visual studio
        4) build project easily from the command line, at least in windows/.NET 2.0. Should work for mono as well, but I have no idea how to path that right.

        Results are attached.

        What I did [layout/.sln-wise]:

        a) pulled the .sln files from the "main" bits being the vestigal demos, the tests and the main Lucene.Net project.
        b) created a new master .sln file to encompass all the core projects.
        c) created 3 versions of master .sln file for each version of visual studio listed.
        d) tested said slns in appropriate versions before and after upgrades – you can still build from 2005 after doing things in 2010.
        e) added nunit binaries to the project in the /lib/nunit-2.4.8 folder
        f) removed the magic SHARP-ZIP-LIB compiler switch so that we could move on without csharpziplib.

        Also, for the build cause:

        i) created new build.proj file to provide a visual studio independent way to build this thing.
        ii) added a batch file which will call said build script to build, all output goes to .\Artifiacts.

        Show
        Wyatt Barnett added a comment - - edited I took a run at re-organizing the project a bit to make it a bit more user-friendly. You can now: 1) open the project in the visual studio version of your choice – 2005, 2008 and 2010. 2) update and commit in said version 3) debug the tests from within visual studio 4) build project easily from the command line, at least in windows/.NET 2.0. Should work for mono as well, but I have no idea how to path that right. Results are attached. What I did [layout/.sln-wise] : a) pulled the .sln files from the "main" bits being the vestigal demos, the tests and the main Lucene.Net project. b) created a new master .sln file to encompass all the core projects. c) created 3 versions of master .sln file for each version of visual studio listed. d) tested said slns in appropriate versions before and after upgrades – you can still build from 2005 after doing things in 2010. e) added nunit binaries to the project in the /lib/nunit-2.4.8 folder f) removed the magic SHARP-ZIP-LIB compiler switch so that we could move on without csharpziplib. Also, for the build cause: i) created new build.proj file to provide a visual studio independent way to build this thing. ii) added a batch file which will call said build script to build, all output goes to .\Artifiacts.

          People

          • Assignee:
            Prescott Nasser
            Reporter:
            Jeffrey Cameron
          • Votes:
            3 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Due:
              Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 10m
              10m
              Remaining:
              Remaining Estimate - 10m
              10m
              Logged:
              Time Spent - Not Specified
              Not Specified

                Development