I've recently had to look for a C# porting of the Protocol Buffers library originally developped by Google. And guess what, I found two projects owned both by two very well known persons here: protobuf-csharp-port, written by Jon Skeet and protobuf-net, written by Marc Gravell. My question is simple: which one do I have to choose ?
I quite like Marc's solution as it seems to me closer to C# philisophy (for instance, you can just add attributes to the properties of existing class) and it looks like it can support .NET built-in types such as System.Guid.
I am sure both of them are really great projects but what's your oppinion?
I agree with Jon's points; if you are coding over multiple environments, then his version gives you a similar API to the other "core" implementations. protobuf-net is much more similar to how most of the .NET serializers are implemented, so is more familiar (IMO) to .NET devs. And as Jon notes - the raw binary output should be identical so you can re-implement with a different API if you need to later.
Some points re protobuf-net that are specific to this implementation:
works with existing types (not just generated types from .proto)
works under things like WCF and memcached
can be used to implement ISerializable for existing types
supports inheritance* and serialization callback methods
supports common patterns such as ShouldSerialize[name]
works with existing decorated types (XmlType/XmlElement or DataContract/DataMember) - meaning (for example) that LINQ-to-SQL models serialize out-of-the-box (as long as serialization is enabled in the DBML)
in v2, works for POCO types without any attributes
in v2, works in .NET 1.1 (not sure this is a huge selling feature) and most other frameworks (including monotouch - yay!)
possibly (not yet implemented) v2 might support full-graph* serialization (not just tree serialization)
(*=these features use 100% valid protobuf binary, but which might be hard to consume from other languages)
Are you using other languages in your project as well? If so, my C# port will let you write similar code on all platforms. If not, Marc's port is probably more idiomatic C# to start with. (I've tried to make my code "feel" like normal C#, but the design is clearly based on the Java code to start with, deliberately so that it's familiar to those using Java as well.)
Of course one of the beauties of this is that you can change your mind later and be confident that all your data will still be valid via the other project - they should be absolutely binary compatible (in terms of serialized data), as far as I'm aware.
According to it's GitHub project site protobuf-csharp-port has now been folded into the main Google Protocol Buffers project, so it will be the official .NET implementation of protobuf 3. protobuf-net however was last updated in 2013, although there have been some commits recently in GitHub.
I just switched from protobuf-csharp-port to protobuf-net because:
protobuf-net is more ".net like", i.e. descriptors to serialise members instead of code generation.
If you want to compile protobuf-csharp-port .proto files you have to do a 2 step process, i.e. compile with protoc to .protobin and then compile that with protoGen. protobuf-net does this in one step.
In my case I want to use protocol buffers to replace an xml based communication model between a .net client and a j2ee backend. Since I'm already using code generation I'll go for Jon's implementation.
For projects not requiring java interop I'd choose Marc's implementation, especially since v2 allows working without annotations.
Related
When creating a new app in Xamarin Forms I see these two options:
Configure your Forms App
Shared Code:
Use .NET Standard
Use Shared Library
Can someone explain the difference? I looked at the help and I am still confused. I'd appreciate if someone can give me any advice on this. Not sure if it helps but this app is self contained and no code in the app will need to be shared with any other application.
In terms of what you can achieve with both, it is the same. So, in the end, it's mostly a matter of taste.
The biggest difference is that a shared project is compiled into the app itself. It is nothing more than it says on the tin: it's a shared folder that you can use in all platform projects. Using platform-specific code is done through compiler directives.
With a .NET Standard project, you will get a physical binary. It is a project of its own. You can reuse it in other .NET Standard projects, although you already mentioned you won't be using it for that. Executing platform-specific code requires a bit different approach, using the DependencyService.
Seeing that they made a choice to replace the PCL with .NET Standard but keep the shared project points out that the shared project is here to stay for a while. I tend to like the .NET Standard library more. It feels cleaner and forces you to write cleaner code. Also, .NET Standard isn't going anywhere soon and if you decide that code should be reused down the road, you have the ability to.
A good overview, together with pros and cons can be found in the Microsoft Docs: https://learn.microsoft.com/en-us/xamarin/cross-platform/app-fundamentals/code-sharing
Is it possible to use the 'DataTable' or 'DataSet' classes in ASP vNext Core 5.0?
When I try to use those classes, I am getting the error:
'The type or namespace name 'DataTable' could not be found'.
This question is a few months old but I see it coming up all the time so I'll post an answer.
As of beta 3, aspnetcore contains only a subset of the System.Data related members, which can be referenced in System.Data.SqlClient, and System.Data.Common. Among the more noticeable items missing from the data libraries are the following: DataTable, DataSet, IDbConnection, IDbCommand, IDbTransaction, and IDbDataParameter and IDataReader.
If you're looking to maintain some abstraction, you can reference the associated abstract classes like DbCommand, DbConnection, DbTransaction and DbDataReader. One thing to note, DbDataReader along with the SqlDbDataReader object no longer support the Close() method. Instead, you'll just call dispose.
I have not heard whether or not these members will be reintroduced in aspnetcore or not, but they don't appear to be in beta 4 either.
aspnetcore is subset of dnxcore and is considered deprecated, one should use dnxcore instead.
As for the DataTables and other related System.Data types, according to this issue they aren't going to include it soon, unfortunately.
Classes DataSet/DataTable/DataRow and everything related to them (DbCommandGenerator, DbDataAdapter etc) are not available in .NET Core 1.0 release (and in .NET Standards 1.3-1.6 specifications as well). This means that ADO.NET was reduced to minimalistic set of low-level interfaces and components (like IDbConnection, IDbCommand, IDbTransaction, DbProviderFactory). At this moment there are no confirmation that DataRow/DataTable will back in future .NET Core releases.
If you're looking for something between low-level .NET Core ADO interfaces and strongly-typed EF Core models - take a look to open-source NReco.Data library that provides alternative implementations for DbCommandGenerator and DbDataAdapter. I'm the author of this library, so you can ask me for details.
I am attempting to use Hammock as a library to enable easy access to a REST API.
When I add the package using nuget in Visual Studio 2010, it adds 2 references:
Hammock
Hammock.ClientProfile
However, when I attempt to use the hammock classes and methods, it tells me there are duplicate implementations of certain classes. Further, using full namespace scoping does not seem to help.
Is it possible that one should be using only Hammock -or- Hammock.ClientProfile - but never both at the same time?
If so, why?
I have contacted the the creator, and he stated that there is no difference between the libraries - he was at one time planning to implement a server-side library, but never followed through on it.
My personally, I am using Hammock (and not using Hammock.ClientProfile).
I'm working with Linq expression trees (from the db4o/Mainsoft/Mono port) on the Compact Framework. Since System.Reflection.Emit doesn't exist, I can't compile my LambdaExpressions into delegates, which I want to do for performance reasons.
I thought maybe I could transform my expression tree into IL and basically provide the missing Emit functionality that way, but then I realized that I'd have to either run a WinCE-based ILASM on it or write my own PE headers and assmebly metadata.
I'd much rather have ILASM available. Is it?
Apparently, I can compile Mono.Cecil for use under the Compact Framework, which will allow me to emit and load assemblies.
If you want use a Lambda-Expressions on CF you don't need ILASM or System.Reflection.Emit. The C# compiler for CF supports Lamba-Expressions but the CF base libraries does not have the Expressions classes. If you add reference to assembly with correct named (and correct implemented) classes for expressions, you enable Lambda-Expressions.
Thanks for god, there are this assembly already implemented ( http://evain.net/blog/articles/2008/09/22/linq-expression-trees-on-the-compact-framework ) - I use it with Db4O data access and for SqlCE wit LINQ IQueryableToolkit, and it works well.
My question isn't so much about use of interfaces but more of a project organization nature.
Note: I am using VisualStudio in a multi-layered application.
Should my Interface files live in a separate project from their implementations? My initial thought is that it would be useful to separate out all my service interfaces into their own project (and a project for my initial implementations) so that down the road the implementation/concrete project may be removed and replaced with a new one if necessary.
To clarify with an example: Suppose I have a business layer Interface called IBusinessService which lives in the MyApp.Business.Services namespace. My implementation FooBusinessService would exist in the same namespace, but a different project in VisualStudio. If later on the implementation needed to be reworked, a developer could remove the reference to the FooService.proj and replace it with a reference to BarService.proj.
This seems like it would declutter the app solution by allowing you to reference a project with only interfaces without also acquiring concrete implementations (which may be obsolete or of no use to you), but am I missing something?
I'm with you. I prefer to put my interfaces in a separate project AND in a different namespace. The classic example is with data access classes. You want to be able to code an MSSQL version and a MySQL version, both implementing the same interface. As such, I prefer that the interface definition be in a separate assembly/project. Here's an example of how I lay out assemblies and namespaces:
Elder.DataAccess.Core - contains the interfaces and common utilities
Elder.DataAccess.MSSQL - specific MSSQL implementations of the interfaces
Elder.DataAccess.MySQL - specific MySQL implementations of the interfaces
This allows me to modify the implementations without touching the project that contains the interface definitions. This helps me with version control and change tracking, too. There might be other ways to skin this cat, so I'll be eager to see other folks' answers.