Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
Improve this question
I'm looking for a framework that supports JSON (de-)serialization on a low level OR is highly customizable.
Many of the types of the object model I have to serialize must be created in a specific way and not all of the information is avaiable to a generic parser.
Currently I'm using JSON.Net with JSONConverters for most of the types, but the instantiation of the types is tricky and not very clean (private constructor with JSONConstructor attribute + post-construction Initialize method that supplies remaining construction data).
In short, a OR-Mapper is not ideal for me because:
Objects are not POCOs (no default constructor, not all constructor information available in parser)
Certain types can be expressed far more compact and readable than what a OR-Mapper creates (e.g. a value-type pair can be stored as {"theType" : "theValue"} instead of {"type": "theType", "value" : "theValue"} – the difference here is mostly readability)
Changes to the domain model are difficult to support; i need to parse legacy data with an old parser to old POCOs, convert those to curernt POCOs and serialize with the current parser (at least I assume that's how it's done with OR-mappers)
When I wrote all the JSONConverters I realized that a framework that provides low-level serialization methods (WriteProperty, ReadValue, WriteObject) would be sufficient for me and also provides the flexibility to create more compact, readable JSON and allows me to
create migrators for different versions of the domain model with little overhead (compared to needing legacy domain objects for ORM parsing).
Are there any frameworks that support low-level / highly customized JSON parsing?
I would rather not write such a parser myself, even though I suppose it would not be that difficult since JSON is a simple format (though Date parsing etc. will likely be a headache).
The JsonReader/Writer types of JSON.Net are basically what I'm looking for, but I'm not sure if it'd be such a great idea to use these types in this way, resp. if there are other libraries that do a better job at providing this functionality – JSON.Net is after all intended to be used as ORM-parser.
We used this java library for JSON that is extremely configurable. We ported it to C# though. :)
To close this question I'll post an answer myself, although I'd accept Soundararajan's answer if he gets the chance to complete his plans and provide his implementation.
I ended up using the JsonReader/Writer types of JSON.Net for the time being.
Once / if performance becomes an issue, I'll switch to protobuf-net which supports SAX-like parsing.
If someone knows a better library for highly customizable / SAX-like JSON serialization, feel free to leave an answer, I'll still watch this question.
Related
I'm currently a researcher for AI company.
I require a serialization solution that is to store very similar structure wise , but vastly different types, interface/base class, and internal generic lists and arrays.
I'm working on CS(C#) due to unique requirements of my work, porting to Java for example isn't an option.
Suffice to say XML doesn't quite cut it - some Nuget packaged upgraded versions of the Microsoft default appear to be a a bit too static or their patterns seem 'clumsy'.
My next line of research Led to JSON (.net).
However I'm unsure if this is the best option - especially considering the complexity of the classes to saved - and the potential for a REST architecture distribution implementation soon.
Thanks for you time, and suggestions. Links to examples of your recommendations containing similarly complex class structures would be appreciated.
You should check out serialization and deserialization of dynamic objects. Your JSON could be as complex as possible. This should give you some idea.
https://thewayofcode.wordpress.com/2012/09/18/c-dynamic-object-and-json-serialization-with-json-net/
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Currently I am starting a project, which needs to serialize the data from .net application ( c# app) and pass it throug a network to a java based server application. Therefore I would like to know which serialization mechanism is most efficient and at the same time serilized objct must be desirialize by java aplication.
queries:
I have heard that protobuf is much more faster than any other serialization like xml. Is is possible to use protobuf to accomplish the above mentioned requirement ??
In java there is newly developed technology named "Kryo" framework for serialization, which is even more efficient than protobuf, so are there any such thing in .net enviornment which must be language independent.
Yes, protobuf is language independent. The java version is provided by google, with multiple C# implementations (I would recommend protobuf-csharp-port if you want very similar code at both ends, and protobuf-net if you prefer the .NET code to look like idiomatic .NET).
Re Kryo - I genuinely don't know enough to comment, but the only way to answer the "is it more efficient" question is to test it (also: define what efficiency means to you: is that serialization size? CPU time? resource usage? or...?). Personally, I'd be a little skeptical that it is going to be smaller, but: there's a sure fire way to find out: you try it.
I do not know whether Kryo is language agnostic, but I can only see Java mentioned.
Hessian is a highly efficient, binary but language independent serialization protocol.
Implementations are available for Java, C++, C#, Objective-C, PHP, Ruby, Javascript etc.
A comparison of the performance of various remote protocol can be found here:
Java Remoting: Protocol Benchmarks
Hmm..
It depends on the type of data you want to share between applications ofcourse.. Here's a brief overview of what I find to be pros & cons..
Can you maybe explain what type of data structures you'd want to share?
I'd advise to either use XML or JSON, to allow flexibility. Other binary based serialisation options will be difficult in the longer run, because,
it could interfere with unreadable/unrecoverable data..
the support could go missing & making your own implementation of reading out data will be harder
XML or JSON have a more clear syntax for which you can easily write your own wrapper, if, for whatever reason all tooling would disappear - because it's human readible
Json is an option
human readable/editable
can be parsed without knowing schema in advance
excellent browser support
less verbose than XML, but lacks "structure checking with schemas"
XML as well
human readable/editable
can be parsed without knowing schema in advance
standard for SOAP etc
good tooling support (xsd, xslt, sax, dom, etc)
pretty verbose vs JSON
And then,
Protobuf
very dense data (small output)
hard to robustly decode without knowing the schema (data format is internally ambiguous, and needs schema to clarify)
very fast processing
not intended for human eyes (dense binary)
Language independence of communication is achieved by the contract-first approach. Create a clear and simple specification of the interchange format and then find the best tool at either end to help you adhere to it.
There are two basic choices for the wire format: XML and JSON.
XML has the advantage of a widely understood Schema specification, which then allows tools to generate binding code.
JSON has the advantage of being a simpler format to "hack together" in any language.
Regarding any statements about the speed of a format, this is tightly bound to existing implementations on a specified platform. There is no language-independent speed rating of a protocol.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
I'm looking for a set of classes (preferably in the .net framework) that will parse C# code and return a list of functions with parameters, classes with their methods, properties etc. Ideally it would provide all that's needed to build my own intellisense.
I have a feeling something like this should be in the .net framework, given all the reflection stuff they offer, but if not then an open source alternative is good enough.
What I'm trying to build is basically something like Snippet Compiler, but with a twist. I'm trying to figure out how to get the code dom first.
I tried googling for this but I'm not sure what the correct term for this is so I came up empty.
Edit: Since I'm looking to use this for intellisense-like processing, actually compiling the code won't work since it will most likely be incomplete. Sorry I should have mentioned that first.
While .NET's CodeDom namespace provides the basic API for code language parsers, they are not implemented. Visual Studio does this through its own language services. These are not available in the redistributable framework.
You could either...
Compile the code then use reflection on the resulting assembly
Look at something like the Mono C# compiler which creates these syntax trees. It won't be a high-level API like CodeDom but maybe you can work with it.
There may be something on CodePlex or a similar site.
UPDATE
See this related post. Parser for C#
If you need it to work on incomplete code, or code with errors in it, then I believe you're pretty much on your own (that is, you won't be able to use the CSharpCodeCompiler class or anything like that).
There's tools like ReSharper which does its own parsing, but that's prorietary. You might be able to start with the Mono compiler, but in my experience, writing a parser that works on incomplete code is a whole different ballgame to writing one that's just supposed to spit out errors on incomplete code.
If you just need the names of classes and methods (metadata, basically) then you might be able to do the parsing "by hand", but I guess it depends on how accurate you need the results to be.
Mono project GMCS compiler contains a pretty reusable parser for C#4.0. And, it is relatively easy to write your own parser which will suite your specific needs. For example, you can reuse this: http://antlrcsharp.codeplex.com/
Have a look at CSharpCodeCompiler in Microsoft.CSharp namespace. You can compile using CSharpCodeCompiler and access the result assembly using CompilerResults.CompiledAssembly. Off that assembly you will be able to get the types and off the type you can get all property and method information using reflection.
The performance will be pretty average as you will need to compile all the source code whenever something changes. I am not aware of any methods that will let you incrementatlly compile snippets of code.
Have you tried using the Microsoft.CSharp.CSharpCodeProvider class? This is a full C# code provider that supports CodeDom. You would simply need to call .Parse() on a text stream, and you get a CodeCompileUnit back.
var codeStream = new StringReader(code);
var codeProvider = new CSharpCodeProvider();
var compileUnit = codeProvider.Parse(codeStream);
// compileUnit contains your code dom
Well, seeing as the above does not work (I just tested it), the following article might be of interest. I bookmarked it a good long time ago, so I believe it only supports C# 2.0, but it might still be worth it:
Generate Code-DOMs directly from C# or VB.NET
It might be a bit late for Blindy, but I recently released a C# parser that would be perfect for this sort of thing, as it's designed to handle code fragments and retains comments:
C# Parser and CodeDOM
It handles C# 4.0 and also the new 'async' feature. It's commercial, but is a small fraction of the cost of other commercial compilers.
I really think few people realize just how difficult parsing C# has become, especially if you need to resolve symbolic references properly (which is usually required, unless maybe you're just doing formatting). Just try to read and fully understand the Type Inference section of the 500+ page language specification. Then, meditate on the fact that the spec is not actually fully correct (as mentioned by Eric Lippert himself).
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
(Note: I have seen several questions regarding .NET logging frameworks, but haven't seen any which resembles our requirements. So please don't close this one as a duplicate.)
We will need a logging framework for a highly distributed and parallel .NET application with the following features:
It must be thread-safe, as log messages will be produced by many threads.
Each log messages will need to have a timestamp. If the framework would add this automatically, that would make it easier.
Besides a timestamps, there must at least be a severity/verbosity or something similar to attach to log messages, so that they can be filtered by it. More (orthogonal) predefined parameters (message source, intended audience, message kind, whatever...) to play with would be great.
However, we need to add our own parameters anyway. The more these are treated like first-class framework citizens (can do the same with them as with the predefined stuff), the better.
The framework should be able to filter messages based on at least the predefined parameters. We need to change filtering at whim during run-time.
We need to put objects through this, not strings. Strings might be made from those objects in the end, but log message parameters must not be put into a flat string right from the start.
Since some of the logging will be seen by customers, we might have to internationalize them. (Given that we want to log objects, not strings, this whouldn't be too hard, but the more support the better.)
We need to be able to write the log messages left after filtering into files and read those files back in. If the framework has the ability to stream the out and in, we don't have to implement this ourselves.
Each log message might be sent to several targets (file, window, remote machine) at the same time.
If log messages have to be sent over the network, it might be necessary to do so in a dedicated thread.
The thing will be used from C#.
OK, so we figure that it's nigh impossible to find something out there that does all of this out of the box. These are just too many requirements, and probably too many uncommon ones.
But is there anything worth to use as a foundation and build our stuff upon?
AFAIK log4net does almost all of these. It's mainly verbosity-level based for filtering, and though you can use Filters to filter using alternative criteria they're not necessarily "first-class citizens".
Also, re. "reading the files back in" - I presume you don't expect the logging framework to support this directly. Files are files, after all.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
Closed 9 years ago.
Improve this question
how to decode a json response in c#?
Check out the DataContractJsonSerializer. You'll have to target .NET 3.5, which means Visual Studio 2008 is pretty much required. Here's a good blog post about using the Json data contract serializer.
See here for info on the DataContractJsonSerializer
In addition to the 3.5 methods above, if you install the ASP.NET 2.0 AJAX Extensions 1.0 (2.0 is the framework version), you will gain the System.Web.Script.Serialization.JavaScriptSerializer class, which can encode/decode json.
The .NET integrated classes have their merits.
But they have their shortcomings.
For example, DataContractJsonSerializer is not available in .NET 2.0, System.Web.Extensions needs admin rights to install it (in NET 2.0 - you can localcopy it, if you don't have a WebSite project) plus it doesn't work in SilverLight and WindowsPhone.
If you have a WebSite project, you need to copy the System.Web.Extensions assemblies to your project, and remove them from GAC afterwards, else VisualStudio doesn't understand it has to localcopy them.
But more importantly, if you work with pretty much any JavaScript library, e.g. SlickGrid (AJAX grid), you will stumble upon this valid JavaScript object (but it's invalid JSON, because fnFormatDate_DE is a function call and not text, it lacks the quotation marks):
FormatterCallback :
{
name : "DateFormatter_DE"
func: fnFormatDate_DE(val)
}
No chance to serialize this with any of the .NET integrated classes (because it's invalid JSON). Also, they fall short in terms of performance, availability in SilverLight, Windows Phone and WindowsRT. They are neither OpenSource nor MIT license. They have no support for indentation (human readable JSON), and they can't serialize DataTables, and they have problems with circular references. You can't handle serialization errors with them, can't serialize enums to their names, and you can't switch the date format (OK, this is not really a problem, because the MS date format is the only date format the safari crap understands [it doesn't undestand ISO]), and they don't serialize neither nHibernate nor Entity...
But most importantly, you won't want to switch your library or adjust project references if you go from .NET 2.0 to 4.0, you don't want to rewrite your code if you want to use some code in SilverLight/Windows Phone, and you don't want to be write a function to beautify JSON if you want to look whether you got the class right, and you won't want to write your own method to strip out quotation marks just because Microsoft's libraries can't handle invalid JSON.
Also, Microsoft's libraries have a low performance, and they can't serialize to BSON (for use with NoSQL databases like MongoDB).
So for all these reasons, you better choose NewtonSoft JSON (JSON.NET).
It's free and OpenSource (MIT license, not GPL).
There is a nice comparison matrix here:
http://james.newtonking.com/pages/json-net.aspx