lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mherndon michael <>
Subject Re: Windows RT / WP8 Version
Date Wed, 21 Aug 2013 22:52:57 GMT
@Chris, thanks for updating the site.  How long did it take for the update
to the site to complete?


To my knowledge, one would not use conditional compilation symbols or
pragma statements to support target platforms in a PCL, Portable Class
Library, project.

One would code against the subset of shared APIs that exist for the lowest
common denominator of the various profiles that are selected and then
implement things as needed.



A first pass at using PCL would most likely be done by splitting the core.
 Place all the interfaces and classes that use the shared APIs in one

The second assembly could just target the full framework for classes that
would take too long to implement right now.

>From there we could go a couple of ways.  Work towards getting everything
into a core PCL library, or just get enough of it to work in the PCL core
to provide a limited number of scenarios for other platforms.


One of the biggest advantages of moving the project to git was to take
advantages of branching and merging.  Rather than have another long chain
of debate, let people work on things that keeps them motivated and excited
which will keep the project moving forward.

I suggest we create two branches.

fast_port_4x  -
experimental_4x  -

The fast port would be for paul's contribution to date.  As previously
noted, it currently lacks the tests, documentation, and testing from the
release audit tool to put it directly into trunk at the moment, but we
should probably get that into the official repo sooner rather than later.

The experimental_4x could be the targeted approach to attempting PCL,
Tasked-based Asynchronous Programming, and .NET 4.5 without impeding the
rest of the project.


We need to request infra to update the apache github mirror to point to the
working git repo.

suggestions, comments, constructive criticisms are welcome.


On Wed, Aug 21, 2013 at 1:13 PM, Zachary Gramana <> wrote:

> Christopher,
> To add to this discussion, I now work at Xamarin and we are not shipping
> PCL support just yet. In addition, PCL has 22 different client profile
> levels. You would have to decide which profile Lucene.Net would support. My
> guess is Profile18 would be the best starting point from a compatibility
> perspective, but that's limiting consumers to SL4 + .NET 4.0. I agree that
> there appeal in a PCL version, but at this point, you're not likely to get
> the payoff that you are hoping for.
> For a porting to Xamarin.iOS, Xamarin.Android, and Xamarin.Mac, I would
> recommend other strategies. For example, our Component system will let you
> ship a version of your assembly that doesn't link against monotouch.dll but
> is otherwise compliant to subset of .NET we provide. This is sort of an
> ersatz PCL, if you will. I suspect that this can be done without littering
> up the codebase with a lot of pragmas.
> Packaging and getting it on our store has been on my todo list
> for a while, so if you want some assistance, let me know.
> Cheers,
> Zack
> On Aug 20, 2013, at 10:49 PM, Christopher Currens <>
> wrote:
> > Hey guys,
> >
> > I've been thinking lately of doing a real push to have Lucene.Net support
> > more platforms, specifically Windows RT and Windows Phone 8.  There are
> two
> > ways I can think of doing it, and each has its own specific advantages
> and
> > disadvantages.
> >
> > One way, would be to utilize the Portable Class Libraries in VS 2012, and
> > target .NET Framework and Windows Phone (this would also give us
> > Silverlight).  We could leave the core pieces of Lucene.Net in that
> > library, and then have platform specific libraries that will share the
> > code.  This has a convenience advantage at the cost of fragmenting our
> code
> > base a little bit, since some parts will be spread across different
> > assemblies.  We'd probably need to make a platform abstraction layer
> which
> > might involve changing some core types to have abstract base classes that
> > could be implemented by each platform assembly.
> >
> > Another way, would be to manage it ourselves using different projects.
>  The
> > source code could stay in it's existing place, and we'd add links to each
> > source file in the project (instead of having it copy to each directory).
> > Then, each edit we make to a file would work against all of the projects
> > that link that file at the same time.  For platforms that don't support
> > certain features (one current example is ParallelSearcher only working on
> > 4.0+ and not 3.5), they just don't link that file.  However, we still
> have
> > to make sure that the files we do link are cross-platform.
> >
> > I actually don't know which one I prefer, I either need to give it more
> > thought or just choose one, see if I hate it, and switch.  The problem
> with
> > the Portable Class Library projects is that they aren't supported in
> > express editions of Visual Studio.
> >
> >
> > Comments?
> >
> >
> > Thanks,
> > Christopher

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message