CustomLineCap does not have the SerializableAttribute applied to it.
I want to add a property of this type to an object graph that is currently being serialized/deserialized with a BinaryFormatter.
I tried switching to XML serialization but it has a bunch of extra requirements and I don't want to fool with that esp. since it's not my code; it's some open source I downloaded.
If there's a way to get BinaryFormatter to ignore the property, that might work.
I'd rather subclass it; I just don't know if that will work either.
You aren't going to be able to serialize an instance of the CustomLineCap class directly. It derives from the MarshalByRefObject class, and while that's not an indicator that it can't be serialized, it's almost always the case.
The reason being that the MarshalByRefObject class is usually an indicator that the object that derives from it only has context in the application domain in which the instance lives. In this case, you the CustomLineCap instance is a GDI object which only has any meaning in the process that it lives in (it's tied explicitly to a handle).
That said, I'd recommend using the adapter pattern to create a wrapper that captures the properties of the CustomLineCap instance that you wish to serialize and then expose and serialize that.
This is generally the approach you'd want to take with any class that has a context that is tied to a specific domain that when serialized to be persisted outside of that domain, doesn't make sense anymore.
Note that subclassing won't work in this scenario either, in that applying the SerializableAttribute to your subclass means that all of the fields (even the private ones that you don't have access to) will be serialized, including any handles which only have context in the application domain they are created in.
Related
I have 3-rd party dll. From that I receive an object of some type (I know its interface, but not all the object). That object is not marked as serializable and I'm not related to that libruary development at all.
I want to serialize it to some storage and then receive it from storage with the same state later (public/private, references etc.). I got here one option - make my own serialization mechanism that will act the same as .NET serializers with the only difference - it won't revise serialization attributes.
Is that the best way?
Thanks.
You can use XmlSerializer or DataContractSerializer to serialize types not marked with SerializableAttribute.
There may be other options. And can always go ahead with custom implementation if nothing works for you.
You can make your own class inheriting from that object and serialize it.
OR you can make your own replica of that class and make some explicit (or implicit, but not recommended) conversion methods.
I would like to control object creation of a type that is not usually serializable during deserialization using a NetDataContractSerializer (or any serializer I guess). Using a custom SerializationBinder I can control the type that is constructed and using a custom ISurrogateSelector and ISerializationSurrogate to control how state is set on the object.
What I cannot do is actually create the object myself to allow the use of dependency injection or something. The object that is causing problems is inside the object graph so I cannot edit it before serialization.
Is there a way to allow my code to construct the deserialized object?
(For background, I am writing a custom WF4 persistence instance store based upon the XmlWorkflowInstanceStore in the WF samples. I want to author workflows that have variables that are interfaces... and the concrete types cannot be constructed directly. The XmlWorkflowInstanceStore is the only example I can find of custom persistence and it uses a NetDataContractSerializer to serialize the workflow state.)
I run into this problem all the time. I normaly implement ISerializable myself and set all the dependencies with an method (named for example SetDependencies) - this is not truly the way you might want (because you have to call it after deserialization) but I didn't find a better way yet (tried AOP but it went to nasty)
I know this question is old, but were you looking for GetSafeUninitializedObject?
It's ok if the answer to this is "it's impossible." I won't be upset. But I'm wondering, in making a game using C#, if there's any way to mimic the functionality of the "save state" feature of console emulators. From what I understand, emulators have it somewhat easy, they just dump the entire contents of the virtualized memory, instruction pointers and all. So they can resume exactly the same way, in the exact same spot in the game code as before. I know I won't be able to resume from the same line of code, but is there any way I can maintain the entire state of the game without manually saving every single variable? I'd like a way that doesn't need to be extended or modified every single time I add something to my game.
I'm guessing that if there is any possible way to do this, it would use a p/invoke...
Well, in C# you can do the same, in principle. It's called serialization. Agreed, it's not the exact same thing as a memory dump but comes close enough.
To mark a class as serializable just add the Serializable attribute to it:
[Serializable]
class GameState
Additional information regarding classes that might change:
If new members are added to a serializable class, they can be tagged with the OptionalField attribute to allow previous versions of the object to be deserialized without error. This attribute affects only deserialization, and prevents the runtime from throwing an exception if a member is missing from the serialized stream. A member can also be marked with the NonSerialized attribute to indicate that it should not be serialized. This will allow the details of those members to be kept secret.
To modify the default deserialization (for example, to automatically initialize a member marked NonSerialized), the class must implement the IDeserializationCallback interface and define the IDeserializationCallback.OnDeserialization method.
Objects may be serialized in binary format for deserialization by other .NET applications. The framework also provides the SoapFormatter and XmlSerializer objects to support serialization in human-readable, cross-platform XML.
—Wikipedia: Serialization, .NET Framework
If you make every single one of your "state" classes Serializable then you can literally serialize the objects to a file. You can then load them all up again from this file when you need to resume.
See ISerializable
I agree with the other posters that making your game state classes Serializable is probably the way you want to go. Others have covered basic serialization; for a high end alternative you could look into NHibernate which will persist objects to a database. You can find some good info on NHibernate at these links:
http://www.codeproject.com/KB/database/Nhibernate_Made_Simple.aspx
http://nhibernate.info/doc/burrow/faq
How can I use an interface (from which classes implement) in an XML web service?
When I do so, I get a YSOD claiming the interface is not serializable. If I add the Serializable attribute to the interface's class, there's another error which hampers progress (can't remember which).
For the most part interfaces are not serializable without some work. Usually this error is encountered when the class being serialized contains an object that is using an interface as a variable, or some variation of this. For instance, a property like this would throw an error:
[Serializable]
public class TestClass
{
private ICustomInterface _iCustomInterfaceObject;
public ICustomInterface CustomInterfaceProperty
{
get { return _iCustomInterfaceObject; }
set { _iCustomInterfaceObject = value; }
}
}
For the sake of the argument (and not making me type additional validation code), let's say that you always are assigning CustomInterfaceProperty to an object that inherits from ICustomInterface (as is required when using interface types like this). Even if it is 100% sure to always be populated, it won't allow you to serialize the TestClass.
To get around this, you need to make sure the interface you are using, the one that is throwing the error, also inherits from ISerializable. That way you are promising that all of the objects inheriting from ICustomInterface also have serialization methods implemented.
Unfortunately, this is not the case when using xml serialization. If you are using the serializers found in System.Xml.Serialization then this method won't work, since, as Robert Harvey pointed out, an interface does not contain a parameterless constructor (which is required when using the xml serializers). My suggestion for now, if you are set on this method of serialization, attach the attribute [XmlIgnore] to the section in question and move on from there.
My advice is to treat the objects that go over the wire as basic data transfer objects and nothing more. You're tempted to just use your domain objects and serialize them, but as you're already seeing, normal in-memory objects can have far more complexity than can be serialized without a lot of work, and sometimes not at all.
You can also end up limiting functionality of your domain classes just to keep them serializable.
Finally, a more subtle bug to avoid, and a reason to have separate DTO's, is that you otherwise are tightly coupling your domain objects to a publicly published interface i.e. the web service itself. Versioning a web service can be a hassle, and it's easier if your service interface isn't tightly coupled to your domain classes.
I'm guessing that the other message is that you can't serialize the interface because it doesn't contain a default (parameterless) constructor.
If the underlying classes are framework classes, you might be hosed. Some of them are not marked serializable, and some of them do not have parameterless constructors.
Also, you may be getting confused between runtime serialization and XML serialization. XML Serialization is what the old ASMX web services use. It does not pay much attention to the [Serializable] attribute, but mostly just serializes the public read/write properties of public classes which have a default constructor.
What is a proxy object in the Inversion of Control / Aspect-Oriented sense?
Any good articles on what a proxy object is ?
Why you would want to use one ?
And how to write one in C# ?
In general, a Proxy object is an object (instance of a class) that exposes the exact same public interface as a "real class" but simply forwards all calls made to it's members to the other real class. Proxy objects are used for a variety of reasons...
One purpose is to "pretend" to be the real class so a client component (or object) can "believe" it's talking to the "real" object, but inside the proxy, other stuff, (like logging, transactional support, etc.) is being done at the same time... Secondly, a proxy can be very cheap in comparson to the real object,. and often is used so that the real objects can be conserved (turned off or released to a pool to be used by other clients) when the client is not using them... The proxy stays "alive" and the client thinks it still has a connection to the real object, but whenever it "calls" the object, it is actually calling the proxy, which goes and gets another real object just to handle the call, and then releases the real object when the call is done.
As to Inversion of Control (IOC).. That refers to a common pattern (also referred to as Dependency Injection), where dependant objects inside of a class are "injected" into an instance of the class, from client code, to control which version of a dependant object the instance will use... IOC can be used to inject a "Proxy" object into a class where it thinks it is using the real object... The phrase Inversion of Control refers to the fact that when using this pattern, the decision as to which actual implementation is called is no longer under the control of the class making the call, but to the client of that class, when it injects an instance of a dependant object into the class to be used for this call.
Generally the term IOC is used with what is called an IOC Container, which is a class specifically designed to be responsible for creating instances of dependant classes based on loosely coupled information about those classes (Types) which it gets from some source other than hard-wired dependencies (most often, from some kind of configuration file). Generally, when you use an IOC container, you create an instance of it when the application starts, and then (by reading config data or whatever), you "register" each of the classes (types) that the IOC container will be responsible for, with a key value. The key is often the abstract type or interface that all instances of this registration must implement). Then, in the normal operations of your application, where you might otherwise have new'd up an instance of one of these types, you call the IOC Container, and ask it for an instance instead, using the abstract type/Interface as the key. The IOC container then uses reflection or dynamic loading, (or whatever), to create an instance of whatever type has been "registered" with that key. In this way, simply by changing configuration data, you can control the actual types used by the application, changing them in one environment or deployment location from those used in another.
A very good resource about this is the old "Gang of Four" design patterns book. This book is very usefull for anyone developing object-oriented software.
I'm personally using proxy objects for lazy loading with NHibernate. I don't use proxies with inversion of control because I resolve interfaced types only with my IoC.
Charles Bretana's explanation is very good.
I can't imagine the relation between proxy and AoP. Could someone explain that here?