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/
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.
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.
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
I have installed sqlite-pcl, but there is also component for Xamarin sqlite-net.
What is the main difference between those references? And which of them has better performance?
As I know pcl doesn't support relationships (foreign key), but sqlite-net does. So I use [Indexed] attribute for better performance, does it make seance?
They are both based on the same Sqlite.Net library but the PCL project is a fork which tries to improve on the previous project:
This is a fork of the original sqlite-net library
(https://github.com/praeclarum/sqlite-net), which aims to improve the
code quality by using modern technologies such as PCL (portable class
library).
The project will avoid the use of #if-based conditional code and use
platform-specific code injection instead.
I welcome pull requests, but keep in mind that this library is in
heavy use and all changes must be:
Backwards-compatible (don't change database defaults). Well tested
(please add unit tests).
Both don't support foreign keys.
Performance-wise the PCL project supposed to be better, but that is untested as far as I know.
My company is building a Flex application that we may need to port to other platforms:
Silverlight (likely)
Mobile (maybe -- iPhone: Objective-C , Android: Java, etc.)
Desktop (maybe -- AIR, .NET, etc.)
TV sets (maybe eventually)
Currently, I’m looking into application frameworks to build upon and I’m torn between pureMVC and Swiz.
I LOVE swiz for its simplicity and how it just gives you a way to hook things up and then apply your own patterns. From a flex-only perspective, this is my 1st choice.
But, PureMVC is platform-independent and has already been ported over to most of the platforms that are mentioned above. How valuable is this portability? Will it really make our lives significantly easier when it comes to porting and developing/maintaining multiple applications? If so, then it seems like PureMVC is the way to go.
Alternatively, since Silverlight has the most definite business case for porting of our application, maybe we could port Swiz to Silverlight? I'm not too familiar with which AS3 language and Flex framework features Swiz depends on and whether they are available in C#/Silvelright. Would this actually be possible?
Thanks so much!
Karthik
The way I see it, if you used pureMVC you could port to a new language, without too much trouble (other than what the new language will give you) your commands, mediators and proxies, provided you program your mediators to an interface, instead of a concrete component implementation, and the proxies use a services layer to get the data from server. That way you'll only have to implement the components and the service layer in the new language.
A quick look at the Swiz framework:
uses the flash event model (see CentralDispatcher)
uses some flash.net, and mx.rpc classes (see net and rpc swiz packages)
PureMVC framework doesn't use the flash event model, and eventual flash.net/mx.rpc references would normally appear in the service layer. On the other hand Swiz seems to be aimed at taking full advantage of flex, and the mxml format, so it might get the job done faster there. So you might also want to consider using Swiz for flex and PureMVC for the other languages.
Any framework, including Swiz, can very easily be ported to just about any language. Actionscript is touring complete, so theoretically any code writen in actionscript can be transformed into another touring complete language. For example, we use the Swiz framework in our mobile apps, which get cross compiled to run in iOS. There are many other open source cross compilers for a variety of languages, as well as Adobe's Alchemy project.
The only thing that is not easily portable in Swiz the usage of runtime metadata tags. This can be solved by using an advanced search and replace utility, or a custom transformation framework to convert custom metadata tags to their native code implementation. Hopefully we will see some cool new open source tools for this soon, now that Flex 4.5 was released with custom compiler hooks.
In short, I wouldn't even take portability into consideration when deciding on a framework. Choose the one which is most comfortable for you or your developers to use. I personally prefer Swiz myself.
Cheers!