Open bongohrtech opened 7 years ago
It turns out that per Microsoft, binary serialization is not meant for new applications, but only for helping with the transition from .NET Framework to .NET Core (https://github.com/dotnet/corefx/issues/23584)
It's crucial that we state as often as possible that binary serialization is not intended to be used for new applications but to make porting from Desktop to Core easier. There are tons of security concerns that are introduced by binary serialization, one of it is reading from a stream that could be compromised (network transferred date, e.g. in remoting).
So, it looks like the best "strategy" for this will be to leave the attribute off of ALL of the classes (including exceptions) except for those that explicitly require it in order for Lucene.Net to function. All legacy tests that verify serialization support should be disabled/removed.
by nightowl888
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-170andLUCENENET-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.
JIRA link - [LUCENENET-574] created by nightowl888