That makes more sense now - rock and hard place. When instantiating a descendant class, the base class methods / contructors need to be called directly by the descendant..since you're not in control of these that makes this even more difficult to solve.
Oh the joys of OO. Good luck.
- Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
- Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!
Reply to: .NET 2.0 Detecting deserialization
Collapse
You are not logged in or you do not have permission to access this page. This could be due to one of several reasons:
- You are not logged in. If you are already registered, fill in the form below to log in, or follow the "Sign Up" link to register a new account.
- You may not have sufficient privileges to access this page. Are you trying to edit someone else's post, access administrative features or some other privileged system?
- If you are trying to post, the administrator may have disabled your account, or it may be awaiting activation.
Logging in...
Previously on ".NET 2.0 Detecting deserialization"
Collapse
-
Yes, that fine. But sadly is not the situation I am in.
The class does not implement ISerializable and I am trying to avoid having to do so because it a base class which is inherited all over the place. ISerializable would need to be implemented in all the derived classes - and I am not in control of these. [aiui the serializer won't call the base implementation of the method - but I need to check this further; I couldn't get it to work yesterday]
The properties in question are a few properties in the base class.
Leave a comment:
-
Sorry I don't get it. Below is some sample code to show the method I'm thinking of and it demonstrates that the serialization constructor is called ONLY when the class is being instantiated by the deserialization process. Client classes attempting to instantiate this class directly cannot use the serialization constructor because it has the protected access modifier.
So as mentioned earlier you can set your flag in the serialization constructor to enable the prop setters if you need to, but clients directly instantiating the class can never do this and this means if the flag is not set and a client attempts to call one of the prop setters you are able to throw your exception. Then if you also implement IDeserializationCallback.OnDeserialization you can switch the flag off at the end of the deserialization process if you need to.
Perhaps you're attempting to avoid doing something like this..or it's just too ugly..but I can't see why it doesn't work.
using System;
using System.Runtime.Serialization;
namespace ClassLibrary
{
[Serializable]
publicclassSerializableClass: ISerializable
{
///<summary>
/// Initializes a new instance of the <see cref="SerializableClass"/> class.
///</summary>
public SerializableClass ()
{
//Regular constructor for client classes
}
///<summary>
/// Initializes a new instance of the <see cref="SerializableClass"/> class.
///</summary>
///<param name="info">The info.</param>
///<param name="context">The context.</param>
protected SerializableClass(
SerializationInfo info,
StreamingContext context)
{
//Serialization constructor
//note this is a protected constructor therefore is only callable by the serialization process
//and not by client classes attempting to instantiate this thing directly
}
#region ISerializable Members
publicvoid GetObjectData(SerializationInfo info, StreamingContext context)
{
//do your custom stuff in here if you need to..
}
#endregion
}
publicclassClientClass
{
public ClientClass()
{
SerializableClass aclass = newSerializableClass();
}
}
}
Leave a comment:
-
Originally posted by TheRefactornator View PostCan you reverse the logic? i.e. The prop setters are disabled by default and only enabled in the serialization constructor? It seems like this will work because if an empty class instance is created locally then all prop setters are auto-disabled for that instance, and they are only enabled when serialization is underway. It seems a simple solution but perhaps I'm missing something.
The calls are:-
New, optional OnDeserialised, any other calls into the object. Whether or not the object is being deserialised (which is the only place the setting will be valid) is always indeterminate.
Of course I could easily enough add logic into the other methods to detect the properties were set and the object was not deserialised (thus the sets are invalid) but this cannot happen until the client next does something with the object. Equally I could add a method for the client to call after construction to denote whether it was deserilized or not. But I want to be able to tell the client it's been naughty at the point it is.
The workaround is to save the data locally in some local variables and populate the actual variables underlying the properties at the point OnDeserialized is called (as implied by yourself and DP). This gives a workaround but means I can't throw an IllegalOperation exception at the time a client populates said properties when it shouldn't.
Hence I do really want to know "being deserialized", followed by "been deserialized".
It does look as though the only viable choice in to add the OnDeserializing and OnDeserialized attributes to an apporpritate method to control it.
Leave a comment:
-
Originally posted by DimPrawn View PostSurely you can set an internal bool once the serialization has been completed (IDesiralizationCallback) so that every public setter is then prevented from changing the data?
So during deserialization the flag _readOnly is false and the properties are set and once deserialization is complete the flag is set the true and every property setter is guarded?
Originally posted by ASB View PostI thought that initially, but I don't think I can make it work.
In the case where the object is deserialized the contructor will be invoked, thus I can set _readonly to false, the properties set and the deserialization callback made then I can set _readonly to true.
However in the case where the object is created in my application the deserialization callback will not be made, thus I can't tell it is being actively deserialized. Granted I can get over this in a number of ways. It still leaves a situation where a client application can simply create an empty one and will have writable versions of the properites though.
Leave a comment:
-
Originally posted by DimPrawn View PostCan you customise the serialization/deserialization code:
http://www.hanselman.com/blog/HOWTOD...dAssembly.aspx
Capture the code generated and then include it in your project. Modify to set the properties internally, set the actual properties to readonly. Use this code directly to serialize and deserialize.
Any good?
Leave a comment:
-
Can you customise the serialization/deserialization code:
http://www.hanselman.com/blog/HOWTOD...dAssembly.aspx
Capture the code generated and then include it in your project. Modify to set the properties internally, set the actual properties to readonly. Use this code directly to serialize and deserialize.
Any good?Last edited by DimPrawn; 11 June 2009, 10:12.
Leave a comment:
-
Originally posted by DimPrawn View PostSurely you can set an internal bool once the serialization has been completed (IDesiralizationCallback) so that every public setter is then prevented from changing the data?
So during deserialization the flag _readOnly is false and the properties are set and once deserialization is complete the flag is set the true and every property setter is guarded?
In the case where the object is deserialized the contructor will be invoked, thus I can set _readonly to false, the properties set and the deserialization callback made then I can set _readonly to true.
However in the case where the object is created in my application the deserialization callback will not be made, thus I can't tell it is being actively deserialized. Granted I can get over this in a number of ways. It still leaves a situation where a client application can simply create an empty one and will have writable versions of the properites though.
I suppose I could still do something with CallContext though.
Overall it doesn't seem there is much of a solution, though I'll investigate Customer serialization with OnDeserializingAttribute/OnDerserializedAttribute. It lookas as though this might give me what I need.
/
Leave a comment:
-
Surely you can set an internal bool once the serialization has been completed (IDesiralizationCallback) so that every public setter is then prevented from changing the data?
So during deserialization the flag _readOnly is false and the properties are set and once deserialization is complete the flag is set the true and every property setter is guarded?
Leave a comment:
-
Originally posted by TheRefactornator View PostOr perhaps implement the IDeserializationCallback interface on your bog standard Serializable class and prevent the class property set{} methods from setting the private member variables in IDeserializationCallback.OnDeserialization using a bool flag.
My requirement is to allow them to be set when deserializing but not otherwise (except locally).
I could probably implement ISerializable but this seems a huge faff. [In an ideal world the 'set' would remain private. But this would mandate ISerializable. Write once properties are a right pain when it comes to serialization.
Leave a comment:
-
Originally posted by DimPrawn View PostCan you use the DataContractSerializer instead?
http://msdn.microsoft.com/en-us/libr...erializer.aspx
This can work with private fields which means you can make the public properties read-only using the DataMemberAttribute
Leave a comment:
-
Or perhaps implement the IDeserializationCallback interface on your bog standard Serializable class and prevent the class property set{} methods from setting the private member variables in IDeserializationCallback.OnDeserialization using a bool flag.
Leave a comment:
-
Can you use the DataContractSerializer instead?
http://msdn.microsoft.com/en-us/libr...erializer.aspx
This can work with private fields which means you can make the public properties read-only using the DataMemberAttribute
Leave a comment:
-
.NET 2.0 Detecting deserialization
I have on object which a client wishes to serialize and deserialize - specifically via XML.
The problem is this means I have to ensure that the properties are read write. But I don't really want to do this since the data is "set once". So, how can I detect that an object is currently being deserialized by the XML deserializer.
Basically what I need to do isonly allow the property to be set during deserialization, IDeserializationCallback doesn't help since that only has OnDeserialization called after completion of deserialization.
I think OnDeserializingAttribute/OnDerserializedAttribute might to appropriate so that I can detect deserialization is in progress. Anybody tried this ??Tags: None
- Home
- News & Features
- First Timers
- IR35 / S660 / BN66
- Employee Benefit Trusts
- Agency Workers Regulations
- MSC Legislation
- Limited Companies
- Dividends
- Umbrella Company
- VAT / Flat Rate VAT
- Job News & Guides
- Money News & Guides
- Guide to Contracts
- Successful Contracting
- Contracting Overseas
- Contractor Calculators
- MVL
- Contractor Expenses
Advertisers
Contractor Services
CUK News
- Streamline Your Retirement with iSIPP: A Solution for Contractor Pensions Sep 1 09:13
- Making the most of pension lump sums: overview for contractors Sep 1 08:36
- Umbrella company tribunal cases are opening up; are your wages subject to unlawful deductions, too? Aug 31 08:38
- Contractors, relabelling 'labour' as 'services' to appear 'fully contracted out' won't dupe IR35 inspectors Aug 31 08:30
- How often does HMRC check tax returns? Aug 30 08:27
- Work-life balance as an IT contractor: 5 top tips from a tech recruiter Aug 30 08:20
- Autumn Statement 2023 tipped to prioritise mental health, in a boost for UK workplaces Aug 29 08:33
- Final reminder for contractors to respond to the umbrella consultation (closing today) Aug 29 08:09
- Top 5 most in demand cyber security contract roles Aug 25 08:38
- Changes to the right to request flexible working are incoming, but how will contractors be affected? Aug 24 08:25
Leave a comment: