[
https://issues.apache.org/jira/browse/LUCENENET-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shad Storhaug updated LUCENENET-574:
------------------------------------
Comment: was deleted
(was: Github user NightOwl888 commented on the issue:
https://github.com/apache/lucenenet/pull/203
@davhdavh
> 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](http://code972.com/blog/2014/04/68-ditching-strong-naming-for-lucene-net).
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](https://github.com/NightOwl888/Spatial4n/) 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](https://cwiki.apache.org/confluence/display/LUCENENET/Mailing+Lists) and
open an issue on
[JIRA](https://issues.apache.org/jira/browse/LUCENENET-574?jql=project%20%3D%20LUCENENET%20AND%20status%20%3D%20Open)
about it so we can see how many votes it gets.
> 2. The assembly version is 4.0.0.0. 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 4.0.0.0 is the right way to go. This is what the MVC team did - all
versions of MVC 4 were 4.0.0.0 (until a they found a security vulnerability so
severe that they had to force everyone to upgrade to it, then it incremented to
4.0.0.1). If you read the [SemVer](http://semver.org/) 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](https://github.com/apache/lucenenet/blob/master/global.json), the build
requires the `1.0.0-preview2-1-003177` SDK, which is the [current
one](https://github.com/dotnet/core/blob/master/release-notes/download-archive.md)
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 issues:
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: https://issues.apache.org/jira/browse/LUCENENET-574
> 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
(v6.4.14#64029)
