lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (LUCENENET-574) [Serializable] Classes
Date Wed, 26 Apr 2017 06:56:04 GMT


ASF GitHub Bot commented on LUCENENET-574:

Github user NightOwl888 commented on the issue:
    > 1. The assemblies are not strong-named in either debug or release build.
    Per Itamar (the project manager), [Lucene.Net will not be strong-named going forward](
I don't agree with all of his points, but for now I am just going to see how many people complain.
I did strong-name the [`spatial4n` dependency](
just in case we need to do it. He might be right that it is time to ditch it as some other
open-source projects have. Personally, I don't need it - do you? If so, I suggest you complain
loudly about it on the [dev mailing list](
and open an issue on [JIRA](
about it so we can see how many votes it gets.
    > 2. The assembly version is I believe the right thing to do would be to set
[assembly: AssemblyVersion("4.8.*")] and [assembly: AssemblyInformationalVersion("4.8-apiwork-ci")]
    In case we do strong-name because of popular demand, setting the assembly version to
is the right way to go. This is what the MVC team did - all versions of MVC 4 were
(until a they found a security vulnerability so severe that they had to force everyone to
upgrade to it, then it incremented to If you read the [SemVer](
document, the behavior of strong-naming acts exactly like changing the major version, since
whenever it is changed it breaks binary compatibility. Therefore, it should never change unless
the major version is changed.
    > After trying to get strong names on, I can say that the entire build system is broken
on latest version of dotnet sdk. 1. Restore needs a specific sln, since there are two, ie:
& dotnet.exe restore $base_directory\Lucene.Net.sln 2. build command no longer accepts
a project.json, but instead uses the csproj files.
    If you look at the [`global.json` file](,
the build requires the `1.0.0-preview2-1-003177` SDK, which is the [current one](
that supports `project.json` (but now that you mention it, the README needs to state the prerequisites).
The `global.json` file ensures the right SDK is used even if a newer one is installed.
    I made an attempt to unify to one solution and upgrade to `.csproj`, but ran into many
    1. The NUnit test adapter doesn't yet support `.csproj` on .NET Core, so no debugging
in VS2017 on .NET Core unless you fire off the tests manually or with NUnitLite.
    2. Some of the tests would not complete after the switch.
    3. With `.csproj`, versioning is still broken with respect to what I mentioned above about
the assembly version (which I plan to file an issue about) - when you specify an AssemblyVersion,
it always uses the same version for the AssemblyFileVersion, meaning they cannot differ. Also,
it is broken in respect to using a non SemVer scheme (which I don't see an alternative for
a port, since we will almost certainly have multiple production releases that correspond to
Lucene 4.8.0). You cannot pass a version number to the `dotnet pack` command, only a version
suffix (which always assumes there will be a `-` before it and always assumes there will be
a version prefix). In addition, when generating the NuGet packages for a pre-release, it doesn't
update the project dependency version numbers to pre-release (which gives you compile warnings).
    These issues can probably be overcome and I much prefer the new format, but I didn't want
to delay the release any longer. I think it would be best to wait until Microsoft announces
they are feature-complete  and NUnit Test Adapter has .NET Core support rather than trading
one broken build system for another.
    I wouldn't object if you want to contribute a build option to turn on strong-naming (provided
it doesn't break the build in TeamCity). But keep in mind, many of the assemblies are using
`InternalsVisibleTo` so we will need a conditional compilation symbol (`FEATURE_STRONGNAME`)
to toggle them between the standard and strong-named form. The strong-name option would not
necessarily need to extend to the `Lucene.Net.sln` solution or its projects, since they are
not used for the build.

> [Serializable] Classes
> ----------------------
>                 Key: LUCENENET-574
>                 URL:
>             Project: Lucene.Net
>          Issue Type: Improvement
>    Affects Versions: Lucene.Net 4.8.0
>            Reporter: Shad Storhaug
>            Priority: Minor
> In Lucene.Net 3.0.3 several classes were marked with the [Serializable] attribute. The
same has been done to several of the classes in the Lucene.Net (core), but most of the classes
in the sub-projects are still not serializable.
> Some of the legacy tests that were carried over required certain classes to be serializable
(LUCENENET-170 and LUCENENET-338), which is how this issue was first discovered. 
> At the very least, all Queries, Filters, and Analyzers should be marked [Serializable],
but it is unclear what criteria version 3.0.3 used to determine which other classes should
be serializable. We need a clear strategy for this as well as the task to be done.

This message was sent by Atlassian JIRA

View raw message