lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zachary Gramana <>
Subject Re: Windows RT / WP8 Version
Date Wed, 21 Aug 2013 17:13:17 GMT

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.


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

View raw message