|
I put a binary file into a table in a dataset. I then write my dataset as a XMLfile using DataSet.WriteXML
When I look at the field with my file-content I have a string wich look like this ...
"<content>/9j/4AAQSkZJRgABAgEAYABgAAD/7ABzRHVja3kAAQAEAAAAPAADAF4AAAAtA<"
What kind of string is that? How can I get it without using dataset/writexml to get it?
I have a special solution where I need to get that string.
Please hekp // henrik
|
|
|
|
|
How are you storing your binary file before putting in the datatable? If you store binary file in byte[] then Google for 'convert byte array to string' You can use BinaryReader class for reading binary data.
Giorgi Dalakishvili
#region signature
my articles
#endregion
|
|
|
|
|
I think the DataSet uses Base64 encoding when it serializes binary fields into XML. I may be wrong, but it is the most common way to encode binary data in XML.
To read it, you could use a System.Xml.XmlReader (and its ReadElementContentAsBase64 method once you've located the correct field). However, the normal way to do it would be to recreate the dataset from the XML file, though (using ReadXml on a new dataset)...
If for some reason you don't want to use the system-provided XML tools and instead want to read the file as text and do your own decoding, you can either google for base64 or use, for example, System.Convert.FromBase64String.
Peter the small turnip
(1) It Has To Work. --RFC 1925[^]
|
|
|
|
|
Yeap ... It is base64 ...
Found the solution yesterday ...
Thanks // HenrikDaSwede 
|
|
|
|
|
MaWeRic wrote: Thanks // HenrikDaSwede
We are the turnips[^]. You will be assimilated. Resistance is futile... 
Peter the small turnip
(1) It Has To Work. --RFC 1925[^]
|
|
|
|
|
The app I'm working on has quite a lot of collections, some of which will hold several thousand items that have numerous fields - some of which are collections themselves.
At the moment I'm leaving everything to GC automatically and it's working, but I'm concerned that it may cause problems in production on lower spec machines if GC doesn't reclaim the memory.
Would I be better implementing IDisposable? Are there any pitfalls to doing so?
Dave
|
|
|
|
|
Since you don't have code that access unmanaged memory, no need of implementing a dispose pattern. GC is efficient and it will take care AFAIK.
|
|
|
|
|
Well...that's only partially true. If any of the objects in the collection implement IDisposable then he should also implement IDisposable so that those objects can get cleaned up when the collection goes out of scope or gets collected.
Scott.
—In just two days, tomorrow will be yesterday.
—Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
[ Forum Guidelines] [ Articles] [ Blog]
|
|
|
|
|
You are correct scott. Thanks for pointing it out.
|
|
|
|
|
The short and simple answer is: "Probably, yes." However, you haven't really provided a lot of details.
A couple of questions to think about:
1. Do any of the objects that will be contained in the collections implement IDisposable?
2. How large are the objects that will be contained in the collections?
If any of the collection items implement IDisposable, then yes, you definately should implement IDisposable so your collection can call Dispose on the items.
If your items are large (greater than about 85,000 bytes) you should probably still implement IDisposable, but definately make sure you set the items to null.
You can take a look at this article[^] for more information on IDisposable in general.
Scott.
—In just two days, tomorrow will be yesterday.
—Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
[ Forum Guidelines] [ Articles] [ Blog]
|
|
|
|
|
Thanks Scott.
None of the objects implement IDisposable directly but use methods that use objects that do - although these are all in using blocks.
Most of the items will be greater than 85K so I'll implement it.
Article bookmarked for investigation! 
Dave
|
|
|
|
|
Scott Dorman wrote: If your items are large (greater than about 85,000 bytes) you should probably still implement IDisposable, but definately make sure you set the items to null.
Setting the items to null serves no purpose at all. It's just a lot of work that doesn't result in the items being collectable any earlier.
Just set the reference to the collection to null, and everything that it contains (that isn't referenced from anywhere else) is immediately collectable.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Guffa wrote: Setting the items to null serves no purpose at all
Not entierely true. Since large objects (greater than 85,000 bytes) don't go on the normal heap explicitly setting them to null helps the GC know that they are no longer in use. This only applies to large objects...anything smaller and it is extra work but also causes no harm.
Scott.
—In just two days, tomorrow will be yesterday.
—Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
[ Forum Guidelines] [ Articles] [ Blog]
|
|
|
|
|
Scott Dorman wrote: don't go on the normal heap explicitly setting them to null helps the GC know that they are no longer in use.
Haven't heard of that one before. AFAIK, no GC related action happens when a reference is set to null and I don't see how it could be different for large and small objects.
Do you have any reference for that claim?
|
|
|
|
|
S. Senthil Kumar wrote: Do you have any reference for that claim?
Take a look at this article from Joe Duffy: http://www.bluebytesoftware.com/blog/PermaLink,guid,88e62cdf-5919-4ac7-bc33-20c06ae539ae.aspx[^]
Consider nulling out large managed object fields in your Dispose method. This is seldom necessary, but should be considered when a field is expensive to keep around, yet its owning object might be held on to longer than necessary. Simply because Dispose was called does not mean that its reference is being released. This could happen, for example, if its container (the object being disposed) is referred to from within a long-running scope (or stored in a static variable), and not explicitly nulled out. Doing this could help to reduce the lifetime of the object by making it eligible for garbage collection sooner. The definition of large and expensive is of course subjective and should be based on performance profiling and measurement. There were also a set of MSDN articles by Jeff Richter, but those appear to have been removed from the MSDN website...still looking around for other copies.
Also, take a look at this article, and specifically the comments from Wesner: http://weblogs.asp.net/pwilson/archive/2004/02/20/77422.aspx[^]
Or the second paragraph http://codebetter.com/blogs/raymond.lewallen/archive/2005/07/10/128999.aspx[^]
Scott.
—In just two days, tomorrow will be yesterday.
—Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
[ Forum Guidelines] [ Articles] [ Blog]
|
|
|
|
|
Scott Dorman wrote: ince large objects (greater than 85,000 bytes) don't go on the normal heap explicitly setting them to null helps the GC know that they are no longer in use.
Do you have any documentation to back that up?
AFAIK, it doesn't matter att all where the objects are allocated. The garbage collector only looks at the active references. If an inactive reference points to an object on the large objects heap, that doesn't turn it into an active reference.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Guffa wrote: Do you have any documentation to back that up?
Take a look at this article from Joe Duffy: http://www.bluebytesoftware.com/blog/PermaLink,guid,88e62cdf-5919-4ac7-bc33-20c06ae539ae.aspx[^]
Consider nulling out large managed object fields in your Dispose method. This is seldom necessary, but should be considered when a field is expensive to keep around, yet its owning object might be held on to longer than necessary. Simply because Dispose was called does not mean that its reference is being released. This could happen, for example, if its container (the object being disposed) is referred to from within a long-running scope (or stored in a static variable), and not explicitly nulled out. Doing this could help to reduce the lifetime of the object by making it eligible for garbage collection sooner. The definition of large and expensive is of course subjective and should be based on performance profiling and measurement. There were also a set of MSDN articles by Jeff Richter, but those appear to have been removed from the MSDN website...still looking around for other copies.
Also, take a look at this article, and specifically the comments from Wesner: http://weblogs.asp.net/pwilson/archive/2004/02/20/77422.aspx[^]
Or the second paragraph here[^]
Guffa wrote: AFAIK, it doesn't matter att all where the objects are allocated. The garbage collector only looks at the active references. If an inactive reference points to an object on the large objects heap, that doesn't turn it into an active reference.
It does matter where objects are allocated since objects in the LOB are still collected but the LOB itself is not compacted like the regular heap. I never said that "If an inactive reference points to an object on the large objects heap" it turns it into an active reference. What I did say was that you should set the large object to null, not necessarily anything that points to it.
Scott.
—In just two days, tomorrow will be yesterday.
—Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
[ Forum Guidelines] [ Articles] [ Blog]
|
|
|
|
|
Scott Dorman wrote: Take a look at this article from Joe Duffy
He's talking about setting references to null if you are going to keep the object that is containing the references. Does not apply.
Scott Dorman wrote: Also, take a look at this article, and specifically the comments from Wesner
He's talking about replacing a reference with a reference to a newly created object. Does not apply.
Scott Dorman wrote: Or the second paragraph here
He's talking about when the large objects heap is collected. Setting a reference to null doesn't change when that happens.
Scott Dorman wrote: It does matter where objects are allocated since objects in the LOB are still collected but the LOB itself is not compacted like the regular heap.
There is of course differences depending on where the object is allocated, but nothing that affects how the garbage collector finds out if the object is collectable or not.
Scott Dorman wrote: I never said that "If an inactive reference points to an object on the large objects heap" it turns it into an active reference.
You said that setting the reference to null would help the garbage collector if the object is on the large objects heap. The only way that would be helpful would be if the garbage collector treats references to large objects differently, which is doesn't.
Scott Dorman wrote: What I did say was that you should set the large object to null, not necessarily anything that points to it.
The discussion was about a collection of objects, so that's what I assumed that you were also talking about. If you are talking about something completely different, you will only be causing confusion if you don't specify what it is that you are talking about.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Guffa wrote: you will only be causing confusion
I'm confused - not by you Scott or Guffa - but by the conflicting info around.
Results of 'Googling' have basically said if using unmanaged memory then it should be used, if not then there's no need - but it won't hurt.
If I'm getting the last point correctly - it doesn't matter how large the Collection object is, it's the objects (items) it holds? If any of them are large then there may be a case for implementing?
If so, the point that if any of the items implement Idisposable then the collection should too means that I should implement it on any potentialy large objects and collections that may hold them?
Dave
|
|
|
|
|
DaveyM69 wrote: I'm confused - not by you Scott or Guffa - but by the conflicting info around.
Results of 'Googling' have basically said if using unmanaged memory then it should be used, if not then there's no need - but it won't hurt.
Sorry...trying to make sure I'm as clear as possible. (The conflicting information is actually what prompted my article.)
The primary purpose for the GC is to manage memory, which is actually different than managing resources. The Dispose pattern is for managing resources. That being said, the simplest rules are:
- If you are using/managing/maintaining any unmanaged memory it should be considered mandatory to use the Dispose pattern.
- If you are using/managing/maintining any objects that implement IDisposable, it should be considered mandatory to use the Dispose pattern.
- Anything else, it should be evaluated on an "as-needed" basis based on the semantics of the object and how it is intended to be used.
DaveyM69 wrote: If I'm getting the last point correctly - it doesn't matter how large the Collection object is, it's the objects (items) it holds? If any of them are large then there may be a case for implementing?
Yes, that's pretty much correct. Obviously, if the runtime allocates more than 85KB of memory to hold the actual collection object (the object itself, plus the pointers necessary for each of the "slots" in the collection) you should set it to null when you're done using the collection, but the collection itself isn't disposable per say. However, if any of the objects you maintain inside that collection implement IDisposable (or are larger than 85K themselves) you should implement IDisposable on the collection.
DaveyM69 wrote: If so, the point that if any of the items implement Idisposable then the collection should too means that I should implement it on any potentialy large objects and collections that may hold them?
Yes, that's also correct...for largely the same reasons I mentioned above.
Scott.
—In just two days, tomorrow will be yesterday.
—Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
[ Forum Guidelines] [ Articles] [ Blog]
|
|
|
|
|
Cool - I've got it 
Many thanks for all your input - and Guffa too!
Dave
|
|
|
|
|
Guffa wrote: He's talking about setting references to null if you are going to keep the object that is containing the references. Does not apply.
Yes, he is talking about setting references to null if the containing object will potentially live longer than the item. In the case of a collection, this could be the case. Consider the act of removing a collection item...the item is no longer referenced but the containing collection is.
Guffa wrote: He's talking about replacing a reference with a reference to a newly created object. Does not apply
This scenario is one of the more common causes for large amounts of memory consumption, and depending on what actions are taking place in the collection it very well may apply.
Guffa wrote: He's talking about when the large objects heap is collected. Setting a reference to null doesn't change when that happens.
True. Setting the reference to null doesn't change when anything happens. However, the LOH doesn't get compacted like the other generations. Setting the reference to null does help the GC know that you are done using the reference.
Guffa wrote: There is of course differences depending on where the object is allocated, but nothing that affects how the garbage collector finds out if the object is collectable or not.
Correct. The GC still has to walk to the heap to find objects that are no longer referenced. However, the LOH doesn't actually participate in the GC collection cycle. They are only removed if they are garbage.
Guffa wrote: You said that setting the reference to null would help the garbage collector if the object is on the large objects heap. The only way that would be helpful would be if the garbage collector treats references to large objects differently, which is doesn't.
Again, the LOH isn't part of the normal GC generations and isn't compacted. Setting the reference to null when you know the object is no longer needed can yield performance gains.
Guffa wrote: The discussion was about a collection of objects, so that's what I assumed that you were also talking about. If you are talking about something completely different, you will only be causing confusion if you don't specify what it is that you are talking about.
The discussion was about implementing IDisposable on a collection, to which my response was: If any of the collection items implement IDisposable, then yes, you definately should implement IDisposable so your collection can call Dispose on the items.
If your items are large (greater than about 85,000 bytes) you should probably still implement IDisposable, but definately make sure you set the items to null.
I don't see how that could have been any clearer.
Scott.
—In just two days, tomorrow will be yesterday.
—Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
[ Forum Guidelines] [ Articles] [ Blog]
|
|
|
|
|
Scott Dorman wrote: Yes, he is talking about setting references to null if the containing object will potentially live longer than the item. In the case of a collection, this could be the case. Consider the act of removing a collection item...the item is no longer referenced but the containing collection is.
But we are not talking about a situation where the containing object will live longer than the item. We are talking about the disposal of a collection, so the collection will not live longer than it's items.
Scott Dorman wrote: This scenario is one of the more common causes for large amounts of memory consumption, and depending on what actions are taking place in the collection it very well may apply.
It may very well happening during the use of the collection, but it has nothing at all to do with the disposal of the collection.
Scott Dorman wrote: However, the LOH doesn't get compacted like the other generations. Setting the reference to null does help the GC know that you are done using the reference.
You are repeating yourself, but you are still not explaining yourself. The GC determines if references are reachable or not, and unreachable references are not keeping objects from being collected, regardless if they are in the LOH or not. So how would the GC be helped in any way by setting a reference that is going to be unreachable to null?
Scott Dorman wrote: Again, the LOH isn't part of the normal GC generations and isn't compacted. Setting the reference to null when you know the object is no longer needed can yield performance gains.
Again, why do you think that the GC can not determine that a reference is unused by the fact that it's unreachable? How would code that uses up CPU time by doing something that is completely unnecessary help performance?
Scott Dorman wrote: The discussion was about implementing IDisposable on a collection, to which my response was:
If any of the collection items implement IDisposable, then yes, you definately should implement IDisposable so your collection can call Dispose on the items.
If your items are large (greater than about 85,000 bytes) you should probably still implement IDisposable, but definately make sure you set the items to null.
I don't see how that could have been any clearer.
It's clear what you mean, but not why you are saying it. I have already explained that setting the items in the collection to null is only a waste of time, as making the collection itself unreachable also makes all references that it contains unreachable. You are only talking about other situations where it is benificial to set references to null.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
The collection should only implement IDisposable if the items that you store in it also implements IDisposable.
If not, there is no benefit of implementing IDisposable. At the exact moment that the collection itself is collectable, everything that it contains (that isn't referenced from anywhere else) is also collectable.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
thanks for your advice Guffa.
Dave
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
