Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
There are a few questions that address already how to store custom objects into the clipboard. This requires marking classes as [Serializable] and then using binary serialization to retrieve them from the clipboard. An example is here.
However, Microsoft issues the following warning about binary serialization:
"Binary serialization can be dangerous. Never deserialize data from an untrusted source and never round-trip serialized data to systems not under your control."
(here).
I tried to use the clipboard with [DataContract] instead of [Serializable] to avoid binary serialization, and this doesn't seem to be working, and classes that aren't marked as [Serializable] are retrieved as 'null'.
Thus, summing up:
Is it safe to use binary serialization in the specific scenario of
the clipboard? I cannot assume that I trust the information in the
clipboard -- the user may have copied it from anywhere.
Alternatively, is it possible to avoid binary serialization to store
and retrieve custom objects from the clipboard?
Edit: using "GetText" to store everything in text removes the ability to paste text only in text recipients (e.g. Notepad) versus pasting in other containers that are able to process the additional information.
There is no need for you to take the data from the clipboard and rely on binary serialization/deserializtion. You can take the data from the clipboard as string which is basically the type that contains the information that you need and how it is represented on the clipboard, then you can process it as you want.
Just use the GetText method and then use the data as you want.
string clipboardText = Clipboard.GetText(TextDataFormat.Text);
Then if there is really a type that you want to deserialize the data into, then you could use newtonsoft.json nuget package to deserialize the data.
var myObject = Json.DeserializeObject<MyType>(clipboardText);
Then you can work with your custom object. Just make sure to include the deserialization in a try catch block in order to treat the case when the data is not in the proper format.
If there is no need for you to stick to binary serialization, then I would not suggest you to go for it, especially because it is harder to follow and maintain if bugs occur.
Related
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 11 months ago.
Improve this question
We are trying to find a universal data model, which can be applied everywhere.
I think there is no doubt that protobuf is good in the microservice architecture as a protocol among processes of different platforms (Windows, Linux, etc.) and languages (Java, C#, C++, Python, etc.)
But how about using protobuf within the process?
To make it simple and easy to illustrate the problems, let say I am making a C# gRPC service and GUI (gRPC client).
After some study, it seems that it is not suitable from what I can see.
Stability: It looks like that protobuf is still in a changing phase. For example, removing Optional keyword in proto3, but adding it back again in proto release 3.15.
Data type: The data types in proto are not fully compatible with common data types. For example, decimal. We need to define another complex data type (What's the best way to represent System.Decimal in Protocol Buffers?) and doing the conversion.
Conversion: We need conversion before we can utilize it in the related language. You cannot add the self-defined proto decimal directly in c#.
Repeated conversion: Conversion is not one off, but back and forth. Let say we have this proto object passing through 5 functions and need to have some calculations on the decimal field at each function. That means, we will need to convert the decimal field in the proto object to C# decimal in each function, have the calculation to get the result, convert and assign the result back to the decimal field in the proto object, then pass the proto object to the next function.
GUI control binding: We cannot bind the proto field (for those without an matched type in C#). Even we can specify the conversion to do so in the control somehow, (Indeed, I am not sure if we can/it is good to do so) in simple control, like textbox. It may not be easy for complicated control like datagridview because there may be different built-in editors for different native data types. If we use proto data types, that means we need to write customized editors for them. And also, we may need to define other behaviors, like how to sort them.
Using the auto-generated proto class within the process seems not a good idea to me as the reasons listed above. The above case only focus on C# service and client. When it comes to different languages, the cases should be more complicated.
Although .net soap services are slow and wordy (if you look at the wsdl definition), one thing I appreciate very much is that both the service and the client are using the same object with native data types, which can be used directly without any issue. The conversion is done in the communication directly and automatically.
The way I can think of at the moment is that:
Using proto as a communication protocol only
Write a class (use native/built-in data types) for each proto message type and our own conversion logic. Doing so because I cannot find any framework/lib to do so.
After receiving the proto object, convert it directly to an object with native/built-in types before further processing. (the benefit here is that even there is a major change in proto spec, we only need to change the conversion logic only without affecting other layers).
Am I on the right track? What is common/best practice to resolve the problems listed above?
Any help is highly appreciated!!!
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I am working on a serialization system using Json, but I need to save events from Buttons (onClick, onHover, etc.) Is there a way about doing this efficiently? (NOTE: The events are all Actions)
Frankly, it is is terrible idea to try to serialize events.
JSON is usually used to serialize data; events are not data - they are implementation details. Most JSON serializers (or more broadly: most serializers) are not interested in delegates / events, because that isn't relevant to data, so: there's a good chance that anything you'd want to do here will need to be manual. Specifically, the problem here is that an event (or rather, the underlying multicast delegate) is effectively zero, one, or multiple pairs of "instance" (optional) and "method" (required).
The method here is a MethodInfo, and there aren't great ways to serialize a MethodInfo as text (although it is at least theoretically possible, although it would be very brittle vs changes to your code.
The instance, however, is an object - and most serializers hate that; in this case, it would combine object (reference) tracking, possibly of objects not otherwise inside the payload, of indeterminate types (so: possibly needing to store type metadata).
Also, deserializing an object model that allows you to point to arbitrary types and methods is a massive security hole, and is a well-known RCE weakness in serializers that (unwisely, IMO) allow this kind of thing (such as BinaryFormatter; for a longer discussion of this topic, see here).
As for what to do instead: whenever an implementation isn't a great fit for a given serializer, the most pragmatic option is to stop fighting the serializer, and work with it instead of against it. For example, it might be that you can create a model that looks kinda like your domain model, but instead of having events/delegates, it might just have a string[] / List<string> that represents the events you need to apply, and your code would worry about how to map between them (mapping methods to strings, and figuring out what the target instance should be, etc). This avoids all of the pain points above, and additionally means that your data is now platform independent, with the payload and the implementation details (your form layout) separate from each-other.
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 4 years ago.
Improve this question
Json is often used in web applications. I set a field in the database to text to store json strings. It may not be a good idea to design a database in this way, but my reason is that the composition of the data may be volatile and does not require external connections. Using Json serialization tools such as Newtonsoft can easily de-serialize a json string from a database into a JObject object, but in a static language program, it will definitely require some more concrete objects to express it, and now I'm facing some Optional options:
De-serialize the json string from the database to get JObject, then
use this object directly
continue to resolve JObject, instantiate a more specific object A, and then use the object A
Option 1 is very convenient for storage and initialization of the read, but when used to get the value string, error-prone. Scenario 2 requires an extra layer of conversion for storing and initializing reads, but it is more intuitive and convenient to use. I am very tangled about which scheme to use.
"More intuitive and convenient to use" is the key here. You should always try to write code in a readable and maintainable way, and if creating model objects for your JSON data helps you achieve this goal, and this doesn't impact performance beyond what's acceptable for your project, do it; the extra conversion layer will be worth it.
Unless there is a reason that you cannot, I would have a concrete dto that your JSON can be de-serialised into. This provides you compile time type safety for all usages (at least after the initial instantiating). I would normally go another step and have a business object class that can instantiate itself from that dto, but that obviously depends on your specific requirements.
On top of type safety, you get a whole bunch more benefits when using a concrete object, but I suspect that at this point I'm preaching to the choir.
One reason you may not be able to is where the content itself is dynamic in nature (and by extension your code expects nothing specific about the JSON string other than maybe that it is well formed). Very few problems are like this though.
So the downside is usually the overhead of the time and effort in writing those concrete classes. Once you have them defined, deserialising them is literally 1 line of code. The trick then is to use a tool to reverse engineer the necessary classes from the JSON string. Due to SO policies, I cannot recommend tools, but if you were to use a search engine that rhymes with frugal and search for something like JSON to c#, you are bound to find a quick way to create those dtos.
This question already has answers here:
What is the need of serialization of objects in Java? [closed]
(9 answers)
Closed 9 years ago.
I have been reading through all that I could find to understand what Serialization is. People often say that we need serialization so that we can convert the in-memory object into a form that is easy to transport over the network and persist on the disk.
My question is - What is so wrong with the in-memory object's structure that makes it difficult to be transported or stored?
Some people also say that the object is binary in form and needs to be serialized. AFAIK, everything in the computer storage or memory is binary. What is it that they want to convey?
Some technical details would be appreciated.
EDIT 1:
I have been looking into C# code samples but all of them use the "Serialization" available in the framework. Maybe I need to work with C++ to see the details and to experience the pain.
A simple and obvious example; a file object is a reference to a file in the file system, but in itself not very useful. Serializing it will at best pass a filename to the receiver, which may not have the file system to read the file from.
Instead, when you pass it over the network, you can serialize it to instead contain the contents of the file, which is usable by the receiver.
Serializing is basically just taking an object which in memory may not have very usable content (pointers/references to data stored elsewhere/...), and converting it to something that is actually usable by the receiver.
For instance, if you have an object of this class
public class myClass {
private String myString = null;
// getters and setters
}
The in memory representation will be the just a pointer to another object (the String). You cannot recall the original state of the object just by storing the binary form.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
Someone wants me to implement a server side data extraction service to extract data from Micorsoft Excel 2010 spreadsheet (xlsx). A spreadsheet must have data in the correct places in order for the extraction to work. Is there a better alternative to using spreadsheets as data collection ? I worry that users might produce a spreadsheet that can fail a parsing/extraction method even though the displayed spreadsheet is understandable to a human.
For example , a user needs to type out many items and each item will several detail lines following it. My program will need identify the boundary between each item and then collect the detail lines that follow it. If a extraction fails, a user will need clues to help them to fix the problem and then re-submit the xlsx file again.
Is there a better way ? Is there something as portable as a Excel spreadsheet but has structured data that can be easily extracted ?
Or perhaps can a Excel spreadsheet to prepare data into structured data such as a JSON representation and then store it as part of the open xml package ?
You can improve data collection using Excel by using Named Ranges and adding Validation code that runs on data entry to the spreadsheet. The Validation code could also add metadata tags to the workbook. Then your extraction program can use the Named ranges (and metadata) to find the data.
I would use an Access DB, very portable but allows you to password protect the structure or only allow insert via a form.
Also an access DB can be read easily via the Jet engine so extracting data automatically in C# is fairly straight forward.
If I understood you question right - you want to store some custom XML describing your data inside you OpenXml Excel file. I think you could use Custom XML Parts for that.