I haven't released the source code so far. It's something I've thought about but never decided on.
That there's little in the library that is thread sensitive. The operations are all carried out simply on the thread used by the client code, and the only 'interesting' inter-thread stuff occurs if the user calls Abort from a different thread (yikes!).
GetFolderListing is effectively just:
ObexGetStream strm = Get(null,
ObexConstant.Type.FolderListing);
Objects.ObexFolderListingParser
parser = new Objects.ObexFolderListingParser(strm);
Objects.ObexFolderListing
listing = parser.GetAllItems();
return
listing;
Note that it calls Get as opposed to GetTo. So can you try and see what happens if you replace your GetTo with a Get, also adding code to read to the end of the stream to. Something like
using (Stream src = sess.Get(name, null)) {
while(true) {
int readLen = src.Read(buf, 0, buf.Length);
if (readLen ==0) break;
// Include this to write to the stream as written to by GetTo,
// but it's unnecessary for the initial testing.
// dst.Write(buf, 0, readLen);
}//while
I presume that the content you're reading in the GetTo is different from you're reading in the GetFolderListing, so maybe the server itself is hanging in delivering the content. If your test code above still fails to complete then that's likely the case, we could turn on some sockets debugging to see when it hangs. What's the server BTW?
Most of the samples use Get from a background thread, but not GetTo similiarly. I've just added a very simple test case to my unit-test and if passed fine and will try an example in a WinForms app if I get a moment.
Andy