Some things will always suck in .Net, I guess
-
MS is only moving forward, everybody hype about LINQ, Workflow Foundation (another sucker technology that is to be matured around year 2014.), should I use var or not var, class initializers...but okay, will somebody explain me why I can not serialize my object without making a few hundred lines of code? I want to be able to serialize any object and to be able to deserialize it any time I want to, regardless of the assembly version I will be using later, I do not want to make custom serializers or to skip or include this or that field with attributes...I just want to have serialization working! There are zillion issues with serialization, and even more are emerging. Why don't somebody just fix this, then we can go wow about Lambda expression and other nonsense. I know MS freaks like Nishant would probably be crying by now, if they could have keep reading up to this point at all, but this post is for the folks who look at things from the perspective anyways. Cheers.
-
MS is only moving forward, everybody hype about LINQ, Workflow Foundation (another sucker technology that is to be matured around year 2014.), should I use var or not var, class initializers...but okay, will somebody explain me why I can not serialize my object without making a few hundred lines of code? I want to be able to serialize any object and to be able to deserialize it any time I want to, regardless of the assembly version I will be using later, I do not want to make custom serializers or to skip or include this or that field with attributes...I just want to have serialization working! There are zillion issues with serialization, and even more are emerging. Why don't somebody just fix this, then we can go wow about Lambda expression and other nonsense. I know MS freaks like Nishant would probably be crying by now, if they could have keep reading up to this point at all, but this post is for the folks who look at things from the perspective anyways. Cheers.
Well, not to defend MS, but think about a few things. Serialization is an amazing thing to begin with. Prior to .NET, serialization was all custom coding to begin with! Serialization needs a lot of help. It cannot read your mind. Translating a class to a generic format needs your help, which is why we have these attributes, to give .NET some clue as to what we want serialized and how. Be happy that MS provided you with the ability to completely control the serialization process! Yes, the BinaryFormatter sucks for any heavy duty lifting. [plug] Which is why I wrote some articles on more compact serialization. [/plug] On the other hand, keep in mind that the serialization in .NET works very well for small packets of data and ties in well with web services, SOAP, etc. It's a general purpose technology that fits a particular niche, and beyond that, you can easily customize it to your requirements. Sometimes it really is awesome that I can serialize a DataTable without thinking about it, and other times, I feed it through my serializer because I know the BinaryFormatter won't handle it, and isn't a real stream anyways. So, pick the right tool for the job. OMG. What have I said!?!?! :rolleyes: Marc
-
MS is only moving forward, everybody hype about LINQ, Workflow Foundation (another sucker technology that is to be matured around year 2014.), should I use var or not var, class initializers...but okay, will somebody explain me why I can not serialize my object without making a few hundred lines of code? I want to be able to serialize any object and to be able to deserialize it any time I want to, regardless of the assembly version I will be using later, I do not want to make custom serializers or to skip or include this or that field with attributes...I just want to have serialization working! There are zillion issues with serialization, and even more are emerging. Why don't somebody just fix this, then we can go wow about Lambda expression and other nonsense. I know MS freaks like Nishant would probably be crying by now, if they could have keep reading up to this point at all, but this post is for the folks who look at things from the perspective anyways. Cheers.
damir_tk wrote:
I know MS freaks like Nishant
*busy doing MS-freakish task* *pause* Uh - er, what was that? Oh hello! *continues doing MS-freakish task*
Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
My latest book : C++/CLI in Action / Amazon.com link -
damir_tk wrote:
I know MS freaks like Nishant
*busy doing MS-freakish task* *pause* Uh - er, what was that? Oh hello! *continues doing MS-freakish task*
Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
My latest book : C++/CLI in Action / Amazon.com link[Paul reads post] [Paul replies to post] [Paul goes back to doing Ms-freak stuff before going out of town]
"The clue train passed his station without stopping." - John Simmons / outlaw programmer "Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
-
Well, not to defend MS, but think about a few things. Serialization is an amazing thing to begin with. Prior to .NET, serialization was all custom coding to begin with! Serialization needs a lot of help. It cannot read your mind. Translating a class to a generic format needs your help, which is why we have these attributes, to give .NET some clue as to what we want serialized and how. Be happy that MS provided you with the ability to completely control the serialization process! Yes, the BinaryFormatter sucks for any heavy duty lifting. [plug] Which is why I wrote some articles on more compact serialization. [/plug] On the other hand, keep in mind that the serialization in .NET works very well for small packets of data and ties in well with web services, SOAP, etc. It's a general purpose technology that fits a particular niche, and beyond that, you can easily customize it to your requirements. Sometimes it really is awesome that I can serialize a DataTable without thinking about it, and other times, I feed it through my serializer because I know the BinaryFormatter won't handle it, and isn't a real stream anyways. So, pick the right tool for the job. OMG. What have I said!?!?! :rolleyes: Marc
Dangit, where's that
10button ?! -
MS is only moving forward, everybody hype about LINQ, Workflow Foundation (another sucker technology that is to be matured around year 2014.), should I use var or not var, class initializers...but okay, will somebody explain me why I can not serialize my object without making a few hundred lines of code? I want to be able to serialize any object and to be able to deserialize it any time I want to, regardless of the assembly version I will be using later, I do not want to make custom serializers or to skip or include this or that field with attributes...I just want to have serialization working! There are zillion issues with serialization, and even more are emerging. Why don't somebody just fix this, then we can go wow about Lambda expression and other nonsense. I know MS freaks like Nishant would probably be crying by now, if they could have keep reading up to this point at all, but this post is for the folks who look at things from the perspective anyways. Cheers.
I second everything Marc said. Plus I never use the built-in serialization for my classes; I always write custom serialization. There is no substitute for the right way.
-
Dangit, where's that
10button ?!Between 1 and 3? Anyway, seconded!
-
MS is only moving forward, everybody hype about LINQ, Workflow Foundation (another sucker technology that is to be matured around year 2014.), should I use var or not var, class initializers...but okay, will somebody explain me why I can not serialize my object without making a few hundred lines of code? I want to be able to serialize any object and to be able to deserialize it any time I want to, regardless of the assembly version I will be using later, I do not want to make custom serializers or to skip or include this or that field with attributes...I just want to have serialization working! There are zillion issues with serialization, and even more are emerging. Why don't somebody just fix this, then we can go wow about Lambda expression and other nonsense. I know MS freaks like Nishant would probably be crying by now, if they could have keep reading up to this point at all, but this post is for the folks who look at things from the perspective anyways. Cheers.
damir_tk wrote:
Why don't somebody just fix this
Go ahead. I'll be over here not using .NET serialization and not really caring.
damir_tk wrote:
There are zillion issues with serialization
And most originate between the keyboard and the chair.
damir_tk wrote:
[...] I do not want to make custom serializers or to skip or include this or that field with attributes...I just want to have serialization working!
Ah! So you want a data transfer format that's flexible, reasonably efficient, forwards and backwards compatible... and you want to put no effort into designing it, and minimal effort into implementing it? Yeah. Good luck with that. And you wonder why you have issues... :rolleyes:
Citizen 20.1.01
'The question is,' said Humpty Dumpty, 'which is to be master - that's all.'
-
MS is only moving forward, everybody hype about LINQ, Workflow Foundation (another sucker technology that is to be matured around year 2014.), should I use var or not var, class initializers...but okay, will somebody explain me why I can not serialize my object without making a few hundred lines of code? I want to be able to serialize any object and to be able to deserialize it any time I want to, regardless of the assembly version I will be using later, I do not want to make custom serializers or to skip or include this or that field with attributes...I just want to have serialization working! There are zillion issues with serialization, and even more are emerging. Why don't somebody just fix this, then we can go wow about Lambda expression and other nonsense. I know MS freaks like Nishant would probably be crying by now, if they could have keep reading up to this point at all, but this post is for the folks who look at things from the perspective anyways. Cheers.
I agree so I wrote a generic De
SerializationBinderthat strips assembly version info and just deserializes the object dagnamit. I was thinking about writing it up as an article ??? The thing that gets to me about the latest round of new technologies is comparing WPF and LINQ to SQL. The point of L2S is to get rid of magic strings that are opaque to the compiler, yet WPF introduced XAML which is full of magic strings that are opaque to the compiler :wtf:---------------------------------- Be excellent to each other :)
-
damir_tk wrote:
Why don't somebody just fix this
Go ahead. I'll be over here not using .NET serialization and not really caring.
damir_tk wrote:
There are zillion issues with serialization
And most originate between the keyboard and the chair.
damir_tk wrote:
[...] I do not want to make custom serializers or to skip or include this or that field with attributes...I just want to have serialization working!
Ah! So you want a data transfer format that's flexible, reasonably efficient, forwards and backwards compatible... and you want to put no effort into designing it, and minimal effort into implementing it? Yeah. Good luck with that. And you wonder why you have issues... :rolleyes:
Citizen 20.1.01
'The question is,' said Humpty Dumpty, 'which is to be master - that's all.'
Shog9 wrote:
want to put no effort into designing it, and minimal effort into implementing it? Yeah. Good luck with that.
A little effort doesn't hurt anything. Talk about being lazy.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer "Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
-
Shog9 wrote:
want to put no effort into designing it, and minimal effort into implementing it? Yeah. Good luck with that.
A little effort doesn't hurt anything. Talk about being lazy.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer "Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
Paul Conrad wrote:
Talk about being lazy.
Looks like another peas halp do it for me, eh?
Beauty is only a light switch away.
-
MS is only moving forward, everybody hype about LINQ, Workflow Foundation (another sucker technology that is to be matured around year 2014.), should I use var or not var, class initializers...but okay, will somebody explain me why I can not serialize my object without making a few hundred lines of code? I want to be able to serialize any object and to be able to deserialize it any time I want to, regardless of the assembly version I will be using later, I do not want to make custom serializers or to skip or include this or that field with attributes...I just want to have serialization working! There are zillion issues with serialization, and even more are emerging. Why don't somebody just fix this, then we can go wow about Lambda expression and other nonsense. I know MS freaks like Nishant would probably be crying by now, if they could have keep reading up to this point at all, but this post is for the folks who look at things from the perspective anyways. Cheers.
Ever since the horrors of MFC's CArchive I've stayed away from built in serialization routines for anything except inter-process transfer of object state where both sides of conversation are guaranteed to agree on object versioning and layout. IMHO using some platform dependent mechanism, especially one that persists an opaque binary data structure, to persist object state ties you to that platform for the life of the application or means some messy translation code to migrate stored objects to the next platform, or even the next version of your objects. My $0.02: if you're going to persist an object to a database or file system, do it in such a way that you'll be able to deserialize that object 2-3 years from now with some completely other technology than the one you're using today; i.e. if it ain't Xml don't persist it. :-O
-
MS is only moving forward, everybody hype about LINQ, Workflow Foundation (another sucker technology that is to be matured around year 2014.), should I use var or not var, class initializers...but okay, will somebody explain me why I can not serialize my object without making a few hundred lines of code? I want to be able to serialize any object and to be able to deserialize it any time I want to, regardless of the assembly version I will be using later, I do not want to make custom serializers or to skip or include this or that field with attributes...I just want to have serialization working! There are zillion issues with serialization, and even more are emerging. Why don't somebody just fix this, then we can go wow about Lambda expression and other nonsense. I know MS freaks like Nishant would probably be crying by now, if they could have keep reading up to this point at all, but this post is for the folks who look at things from the perspective anyways. Cheers.
I just do it manually most of the time. Originally this was because I wanted to create a mobile version of something and it turned out the compact framework didn't support serialization, and I just ended up sticking to using my own code as it seemed easier. Plus I know what every byte is used for and I'm not bitten by something I might misinterpret with the standard .NET serialization. That's for serializing to disk anyway, I still use .NET serialization for some other things such as web services, remoting etc.
-
damir_tk wrote:
I know MS freaks like Nishant
*busy doing MS-freakish task* *pause* Uh - er, what was that? Oh hello! *continues doing MS-freakish task*
Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
My latest book : C++/CLI in Action / Amazon.com link -
I am sure this was supposed to be funny...just don't get if it's only Bangalore funny or worldwide funny.
It's Nish; he makes Bangalore funny into worldwide funny.
Software Zen:
delete this;
Fold With Us![^] -
Well, not to defend MS, but think about a few things. Serialization is an amazing thing to begin with. Prior to .NET, serialization was all custom coding to begin with! Serialization needs a lot of help. It cannot read your mind. Translating a class to a generic format needs your help, which is why we have these attributes, to give .NET some clue as to what we want serialized and how. Be happy that MS provided you with the ability to completely control the serialization process! Yes, the BinaryFormatter sucks for any heavy duty lifting. [plug] Which is why I wrote some articles on more compact serialization. [/plug] On the other hand, keep in mind that the serialization in .NET works very well for small packets of data and ties in well with web services, SOAP, etc. It's a general purpose technology that fits a particular niche, and beyond that, you can easily customize it to your requirements. Sometimes it really is awesome that I can serialize a DataTable without thinking about it, and other times, I feed it through my serializer because I know the BinaryFormatter won't handle it, and isn't a real stream anyways. So, pick the right tool for the job. OMG. What have I said!?!?! :rolleyes: Marc
I agree with you to the most part. But tell me - why do we have all new emerging technologies and fancy stuff, when even this what we have is not working properly? If serialization is for small object, then why the whole Workflows in WF are getting serialized, and with their state as well? I had to write an extensive plugin architecture a year ago, now I resolved all the issues this way or another, but the painful parts: Why shadow folders are not working? If it was spotted in framework version 1.0, why it hasn't been fixed by now? Why can't I load an assembly from anywhere on the disk, if we are beyond "dll hell", but only below the current executing folder? If I serialize an object, why can't I use it later on if I change the version of my assembly? I have to go custom serialization each and every time, and many of my classes are HUGE! Why is it possible to load multiple instances of the same dll any number of times into the app domain? Why does an assembly gets locked the moment I touch it? Why can't it ever be unloaded from that or any other app domain? Why I can only serialize objects of classes that only have public constructors, and no other flavors? How to use serialization when it will break the moment I change the name of my class, or use strong name for the assembly? Why should I use a process that is relying internally on CodeDom, and will turn the execution order of my constructors upside down after deserialization? Create an assembly and try to load some plugins for it. Designate a folder for plugins, those plugin assemblies have some references, compile it, everything works. Check it to TFS, get somebody else on your team to pull the latest version and to compile it on his computer, drop those assemblies into the very same folder, and it will throw an exception. Why is that? Everybody says something underlying buried deep down in .Net framework. How to solve it? Why the code compiles at all even on my machine? Apparently, you have to add an empty event for AppDomain.CurrentDomain.AssemblyResolve, and nobody knows why this resolves the problem, when it does nothing in it just exists as an event. Somebody may even like this mystery and net framework being so full of surprises (this is why people use Linux in the first place, cause they like to suffer and have time for that), but I need an environment that is working and that I can rely on 100%, at least in the major features. Otherwise I get in the situation where production goes crazy and is stating how much
-
damir_tk wrote:
Why don't somebody just fix this
Go ahead. I'll be over here not using .NET serialization and not really caring.
damir_tk wrote:
There are zillion issues with serialization
And most originate between the keyboard and the chair.
damir_tk wrote:
[...] I do not want to make custom serializers or to skip or include this or that field with attributes...I just want to have serialization working!
Ah! So you want a data transfer format that's flexible, reasonably efficient, forwards and backwards compatible... and you want to put no effort into designing it, and minimal effort into implementing it? Yeah. Good luck with that. And you wonder why you have issues... :rolleyes:
Citizen 20.1.01
'The question is,' said Humpty Dumpty, 'which is to be master - that's all.'
-
I am sure this was supposed to be funny...just don't get if it's only Bangalore funny or worldwide funny.
I think it is funny and I'm from Scotland.
Recent blog posts: *SQL Server / Visual Studio install order *Installing SQL Server 2005 on Vista *Tip of the Day - SysInternals * Meme My Blog
-
I agree with you to the most part. But tell me - why do we have all new emerging technologies and fancy stuff, when even this what we have is not working properly? If serialization is for small object, then why the whole Workflows in WF are getting serialized, and with their state as well? I had to write an extensive plugin architecture a year ago, now I resolved all the issues this way or another, but the painful parts: Why shadow folders are not working? If it was spotted in framework version 1.0, why it hasn't been fixed by now? Why can't I load an assembly from anywhere on the disk, if we are beyond "dll hell", but only below the current executing folder? If I serialize an object, why can't I use it later on if I change the version of my assembly? I have to go custom serialization each and every time, and many of my classes are HUGE! Why is it possible to load multiple instances of the same dll any number of times into the app domain? Why does an assembly gets locked the moment I touch it? Why can't it ever be unloaded from that or any other app domain? Why I can only serialize objects of classes that only have public constructors, and no other flavors? How to use serialization when it will break the moment I change the name of my class, or use strong name for the assembly? Why should I use a process that is relying internally on CodeDom, and will turn the execution order of my constructors upside down after deserialization? Create an assembly and try to load some plugins for it. Designate a folder for plugins, those plugin assemblies have some references, compile it, everything works. Check it to TFS, get somebody else on your team to pull the latest version and to compile it on his computer, drop those assemblies into the very same folder, and it will throw an exception. Why is that? Everybody says something underlying buried deep down in .Net framework. How to solve it? Why the code compiles at all even on my machine? Apparently, you have to add an empty event for AppDomain.CurrentDomain.AssemblyResolve, and nobody knows why this resolves the problem, when it does nothing in it just exists as an event. Somebody may even like this mystery and net framework being so full of surprises (this is why people use Linux in the first place, cause they like to suffer and have time for that), but I need an environment that is working and that I can rely on 100%, at least in the major features. Otherwise I get in the situation where production goes crazy and is stating how much
(note, things I haven't addressed are things I don't know much about)
damir_tk wrote:
I agree with you to the most part. But tell me - why do we have all new emerging technologies and fancy stuff, when even this what we have is not working properly?
Ah, well, that's a good question, and frankly that's the reason I haven't touched WF or Entity Framework. Lack of trust, because I agree with you--a lot of what's coming out of MS is half-baked, even after the RTM.
damir_tk wrote:
If serialization is for small object, then why the whole Workflows in WF are getting serialized, and with their state as well?
Because other programmers at MS use the tools/technologies available, without much thought? I see this even in non-MS devs: they reach for the "simple" solution because it's there, without thinking.
damir_tk wrote:
Why can't I load an assembly from anywhere on the disk, if we are beyond "dll hell", but only below the current executing folder?
You can. You have to provide the fully qualified path. And there's a nifty event that fires that lets you resolve an assembly when .NET can't. I use it a lot. Very useful.
damir_tk wrote:
If I serialize an object, why can't I use it later on if I change the version of my assembly?
How are you serializing? If I serialize a class to XML, it works fine. Otherwise, I think it's a good thing, sort of, because the serializer doesn't know what has changed in your assembly, it only knows that something HAS changed. I guess it's a safeguard.
damir_tk wrote:
and many of my classes are HUGE!
Erm...that's an indication you are not controlling the serialization correctly. Sounds like you're relying on the automation too much.
damir_tk wrote:
Why is it possible to load multiple instances of the same dll any number of times into the app domain?
IIRC, you can't. Once it's loaded in memory, you can load it again, but it knows and doesn't reload it. Are your experiences different?
damir_tk wrote:
Why can't it ever be unloaded from that or any other app domain?
Wait a minute. I thought one of the tricks of an app domain is that it's the only way t
-
Well, not to defend MS, but think about a few things. Serialization is an amazing thing to begin with. Prior to .NET, serialization was all custom coding to begin with! Serialization needs a lot of help. It cannot read your mind. Translating a class to a generic format needs your help, which is why we have these attributes, to give .NET some clue as to what we want serialized and how. Be happy that MS provided you with the ability to completely control the serialization process! Yes, the BinaryFormatter sucks for any heavy duty lifting. [plug] Which is why I wrote some articles on more compact serialization. [/plug] On the other hand, keep in mind that the serialization in .NET works very well for small packets of data and ties in well with web services, SOAP, etc. It's a general purpose technology that fits a particular niche, and beyond that, you can easily customize it to your requirements. Sometimes it really is awesome that I can serialize a DataTable without thinking about it, and other times, I feed it through my serializer because I know the BinaryFormatter won't handle it, and isn't a real stream anyways. So, pick the right tool for the job. OMG. What have I said!?!?! :rolleyes: Marc
I just gave up on it and now I write custom serialization for all of my serializable objects. I stopped having problems! Sure it takes some extra time but less than I have spend on average dealing with the issues left by MS. Personally, I think if they would have made private fields serializable by default without custom serialization most users serialization issues would have gone away. Even after reading the MS justification I am tired of the everything should be public methodology, although now in .NET I almost exclusively write public methods and classes just so the framework will support the code I want to write. Personally, I find it laughable that some framework classes and methods are actually documented, "Internal for .NET framework do not use". Which of course is so much better than using internal and private anything.
Need a C# Consultant? I'm available.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway