GetHandler<IStream> hangs after getting property from ShellItem

[tim-fernico]

After getting a ShellItem for a file, I get the MIMEType property followed by opening the file using GetHandler. The app hangs on the call to GetHandler

If I new a ShellItem (from a PIDL) for the properties call and new another ShellItem for the GetHandler it works fine

What code is involved
Calling ShellItem.GetHandler after ShellItem.Properties.TryGetValue

Expected behavior
GetHandler should return an IStream

using (var shellItem = new ShellItem(this.SelectedItem.pidl))
{
    if (!shellItem.IsFolder)
    {
            if (shellItem.Properties.TryGetValue<string>(PROPERTYKEY.System.MIMEType, out var val))
            {
                System.Diagnostics.Trace.WriteLine(val);
            }
        }

        // calling this after the properties hangs - don't know why
        var storage = shellItem.GetHandler<IStream>(BHID.BHID_Stream);
        try
        {
            // IStreamStream  wraps IStream with a .NET Stream
            using (var stream = new IStreamStream(storage))
            using (var sr = new StreamReader(stream))
            {
                System.Diagnostics.Trace.WriteLine($"{shellItem.FileSystemPath} ({stream.Length})");
            }
        }
        finally
        {
            Marshal.ReleaseComObject(storage);
        }
    }
}

[dahall]

I'm wondering if this has to do with using the same IBindCtxt twice. Does it hang if you call GetHandler and then get the property?

[dahall]

I liked the idea of a COM IStream wrapper so I did some searching for IStreamStream but couldn't find an implementation, so I wrote my own. You'll find it in the next release as Vanara.InteropServices.ComStream. I answered the last question I sent. No, it only happens in the order you mentioned. I'm recreating your code in native C++ to see if the problem is there too. I'll let you know my findings.

[dahall]

Well, I ran the following code and it works just fine so the problem is somewhere deep in my library. I'll keep looking for the problem.

HRESULT hr = CoInitialize(NULL);
if (SUCCEEDED(hr))
{
   IShellItem2* pshi2;
   hr = SHCreateItemFromParsingName(L"C:\\Temp\\Holes.mp4", NULL, IID_PPV_ARGS(&pshi2));
   if (SUCCEEDED(hr))
   {
      PROPVARIANT pv = { 0 };
      hr = pshi2->GetProperty(PKEY_MIMEType, &pv);
      PropVariantClear(&pv);

      LPBC ppbc;
      hr = CreateBindCtx(0, &ppbc);
      if (SUCCEEDED(hr))
      {
         IStream* pstream;
         hr = pshi2->BindToHandler(ppbc, BHID_Stream, IID_PPV_ARGS(&pstream));
         if (SUCCEEDED(hr))
            pstream->Release();
         ppbc->Release();
      }

      pshi2->Release();
   }
   CoUninitialize();
}

[tim-fernico]

Does it hang if you call GetHandler and then get the property?

It works fine calling GetHandler before the property.

[dahall]

Found the problem: It turns out that if you call IShellItem2::GetPropertyStore to get an IPropertyStore object, it holds the file open for the lifetime of that object. Since the Properties on ShellItem holds a reference to that object once created, it means that after calling it, no other operations that require file access (like binding to an IStream) can be called. So, I'm looking at alternatives that will likely require some significant rewriting of the logic. It will take some time. Sorry.

As a work around (though a little hacky) you can use the methods on IShellItem2 to get properties without locking the file. Below is a snippet.

if (!shellItem.IsFolder)
   Console.WriteLine(((IShellItem2)shellItem.IShellItem).GetString(PROPERTYKEY.System.MIMEType));

Besides GetString, there are similar methods for retrieving a variety of types. See the docs for IShellItem2.

[dahall]

It wasn't so hard a change after all. I have it working in the posted version of the library. I will release later this week after further testing.

[dahall]

Package 2.3.8 with the changes has been published.