I am working on a .NET Core project and I am trying to parse my List<T> to byte[].
Using the .NET Framework, we could have achieved the same by using BinaryFormatter, but at the time of writing this question it looks like Microsoft does not yet support it in .NET Core and no upcoming releases seem to do that.
Can anybody tell how to perform this serialization in .NET Core?
Also, is binary serialization platform-dependent, and for such reason been deprecated in .NET Core?
You can use Binaron.Serializer - https://github.com/zachsaw/Binaron.Serializer
There's no need to decorate your class with any attributes.
Disclaimer: I'm the author of Binaron.Serializer.
You can use MessagePack. The package is chosen as Package of the week in .Net blog.
Nuget command:
Install-Package MessagePack
You can also take a look into their source code and see how it is implemented in .net core.
.NET Core 2.1 now includes a BinaryFormatter you can use for this.
You can find more details in this answer.
BinaryFormatter is getting obsoleted in the upcoming .NET versions due to its security flaws.
It is basically safe only if both serialization and deserialization happens in the same process (which is not the case in most scenarios) so it has been decided to remove it from future versions.
Though the obsoletion document says that in .NET 8 the complete binary serialization infrastructure will be removed I still hope this can be somewhat influenced. I recently opened an issue to discuss the possible ways of making binary serialization (and any polymorphic serialization) safe: https://github.com/dotnet/runtime/issues/50909
But as the other answers also illustrate, there are many custom binary serializers you can choose from. #ZachSaw's Binarion or MessagePack are equally popular, and I also made my binary serializer public a few years ago (NuGet). It tries to address the security aspects and good performance (meaning both speed and size).
But frankly, when communicating between remote entities (including file and database sources), a vulnerable binary serializer never should be used. And even the speed of the slower text-based serializers will be still much faster than any network communication so their speed barely can be real bottleneck.
For payload size and performance you can try BOIS which focuses on packed data size and provides the best packing so far. It also supports .Net Core
https://github.com/salarcode/Bois
Related
I'm having trouble getting a overview of the different SQLite libraries to be used with .Net Core and/or Standard.
It seems there are primarily two:
MS: Microsoft.EntityFrameworkCore.Sqlite
sqlite.org: System.Data.SQLite
Is the MS library completely independent of the sqlite.org's libraries? And if so, which one is recommended to use?
I prefer simplicity....it seems I just need two dll's if using sqlite.org.
There are two main SQLite packages for .NET Core/Standard. They are independent and use separate native binaries.
Microsoft.Data.Sqlite
System.Data.SQLite
The former is provided by Microsoft, the latter by SQLite.org. I prefer the Microsoft one but unless you're looking for specific functionality (SQLite.org's supports encryption, Microsoft's supports fts5, etc) either one will probably work fine. They both implement System.Data.Common and so the APIs are almost identical. SQLite.org's can load arbitrary extensions which Microsoft's cannot (though with the latest release it was looking like SQLite.org's couldn't load fts5 which I know worked with previous releases).
I would recommend using Entity Framework Core or another similar third-party database abstraction package unless you absolutely can't use modelling for some reason (EFCore still lets you run the occasional low level query if you need to). It's quicker to develop, and easier to maintain the code.
Microsoft.EntityFrameworkCore.Sqlite provides support for Sqlite in EFCore, using Microsoft.Data.Sqlite. So you would want to use that in this case. The internet says you can also use System.Data.SQLite but it looks like Microsoft.EntityFrameworkCore.Sqlite still tries to load the underlying native binary from Microsoft.Data.Sqlite for some purpose, though it does appear to use System.Data.SQLite for the actual database operations. Not sure exactly what's going on there.
Microsoft.EntityFrameworkCore.Sqlite is for Entity Framework Core ORM is more complete but heavier.
The System.Data.SQLite.Core can use with Dapper ORM SQLite and Dapper but I use the Microsoft.Data.Sqlite.Core with SQLitePCLRaw.bundle_e_sqlite3 and Dapper ORM, I think I had problems with System.Data.SQLite.Core.
Use without is hard and I not recommend.
Is there any reason to mark a .NET Standard or a .NET Core library as CLS compliant?
As I understand it:
If I build a .NET Framework library with C-sharp and make it totally CLS-compliant all the types/members can be used and called from a .NET Framework library or application written in VB-net, F-sharp etc. (don't know all the CLR-languages), referencing my library.
Is this not relevant anymore when using .NET Standard and .NET Core? What languages other than C-sharp can reference a .NET Standard library?
However, if there are several languages and you want to make the library CLS compliant, it will be hard because many of the .NET Standard types are not CLS compliant.
Some non CLS-compliant types:
Microsoft.Extensions.FileProviders.IFileProvider
Microsoft.Extensions.Logging.ILogger
Microsoft.Extensions.Logging.ILoggerFactory
There are issues about this on GitHub:
https://github.com/aspnet/Logging/issues/500
https://github.com/aspnet/AspNetCore/issues/2689
But as I understand it, there will be no change:
https://github.com/aspnet/AspNetCore/issues/2689#issuecomment-354693946
Whether you want to build CLS compliant libraries is up to you. We cannot decide that for you.
Please note that the analyzer only requires you to properly mark your assembly. It does not say whether it should be marked as compliant or not. It only says you should be explicit about whether it is compliant, that can be an explicit "no, it's not".
Is there an option to calculate SHA3-256 hashes in .NET Core? The goal is to recreate the isChecksumAddress util function in web3.js
No, there is no way of doing that now with pure dotnet core.
It's been on the watch list since it was announced. Since we don't implement cryptographic algorithms within .NET we're waiting on support from the underlying platforms (Windows CNG, Apple Security.framework, and OpenSSL).
See this issue.
But you might have a better luck with BouncyCastle. It has an implementation here but I don't know if it is out yet (in nuget).
FIPS-202 SHA3-256 (and all other SHA3 variants, e.g. SHA3-512, SHA3-SHAKE256) are implemented here, in pure .NET, with no dependencies on external APIs like BouncyCastle.
GitHub
https://github.com/series0ne/CORE/tree/master/Core/Security/Cryptography
Nuget
https://www.nuget.org/packages/SeriesOne.Core/
You can use SHA3.Net that is a SHA3 wrapper of the BouncyCastle implementation, implementing System.Security.Cryptography.HashAlgorithm
https://www.nuget.org/packages/SHA3.Net/
I've read some things about .NET Standard and .NET Core, and generally they seem to say something like "This is the new way to do things, and here are the advantages and disadvantages."
What I haven't seen is a good, clear explanation of what was wrong with the status quo, such as .NET Standard and .NET Core were even necessarily. To really judge what I should use these for, it would be helpful to know why they exist at all.
Can someone give a clear (and not necessarily concise!) explanation of (a) what problem .NET Standard and .NET Core are intended to solve, and (b) how they solve it?
.NET Standard is a set of library contracts. Each version includes all the contracts of the previous version - so everything in netstandard1.4 is in netstandard1.5 for example.
.NET Core is an implementation of .NET Standard (and some extra functionality) which runs on Windows, Linux and OSX.
Biggest problems they solve:
Not having a Microsoft-provided/supported toolchain and runtime on Linux/MacOSX. Saying that you could only run .NET-based server code on Windows or Mono was simply untenable.
The Portable Class Library mess with hundreds of different profiles giving partially-overlapping API surfaces to target.
PCLs in particular were very hard to work with for class library authors such as myself. The mess came about because there were multiple efforts to bring a .NET runtime to different devices without enough coordination to provide a coherent API surface to target.
Now multiple vendors can target particular versions of .NET Standard, and anything targeted to that version or higher should work. For example, my Noda Time library targets netstandard1.3. Suppose a new mobile phone vendor comes out with a completely new implementation of .NET, with a completely new kind of application - but says they support netstandard2.0. That's fine - a user of that new platform will still be able to install the Noda Time NuGet package and (implementation bugs aside, of course) they'll be able to use it. I don't need to know that the platform even exists.
So begins from 0.75.1, Rebus no longer supports ASP.NET 4?
My question will be:
Is 0.75 a stable release for .NET 4 project?
Are we going to continue get bug fixes (if any) for .NET 4 target project?
Thanks
As of 0.75 Rebus has targeted .NET 4.5, which was a requirement to support the usage of async/await in the library.
I'm not an expert on ASP.NET and whether the version follow the versions of .NET, but Rebus will work as long as your host process targets (at least) version 4.5 of the framework. If ASP.NET 4 is only available for projects that target .NET 4, then that implies that you cannot use versions > 0.72 of Rebus.
And then an answer to your questions:
You should pick the latest version of Rebus, but that requires that you target (at least) .NET 4.5. If that is not an option, you should pick Rebus 0.72 (which is the last version available that targets .NET 4).
No (*)
As for the (*) above, I'd like to make the following fairly long and elaborate point: Generally, you can't count on getting bug fixes for the free, open-source software you have downloaded and are using, freely, without having paid a cent - at all!
If you want to be able to reliably count on getting bug fixes for your free software, I suggest you get a support contract with a company that is willing to provide that service. My employer provides that service for Rebus in case you're interested.
With that said, I'll add that I am a pretty helpful person, and I do a lot for people to have a nice experience with Rebus, but I am sure that you can understand that I cannot promise to provide bug fixes for the old versions.
I will be around for helpful advice if you run into something, but - as I am developing Rebus mostly in my spare time - you can probably understand why I need to concentrate my efforts on the current version.