Can I use CsWin32 to open the FileOpenDialog from a console application?

[MikeYeager]

I don't want to bring in WinForms or WPF just to get to the FileOpenDialog. I could figure out how to manually PInvoke, but simplifying that that seems to be what this project is for. When I add FileOpenDialog to the NativeMethods.txt file in my .NET 6 console app, all it generates is this:

#pragma warning disable CS1591,CS1573,CS0465,CS0649,CS8019,CS1570,CS1584,CS1658,CS0436,CS8981
namespace Windows.Win32
{
	using global::System;
	using global::System.Diagnostics;
	using global::System.Runtime.CompilerServices;
	using global::System.Runtime.InteropServices;
	using global::System.Runtime.Versioning;
	using winmdroot = global::Windows.Win32;

	namespace UI.Shell
	{
		[Guid("DC1C5A9C-E88A-4DDE-A5A1-60F82A20AEF7"),ComImport()]
		internal partial class FileOpenDialog
		{
		}
	}
}

But the class is unusable. It just instantiates an object with no real methods or properties on it. Is this something I can even do with CsWin32?

Thank you.

[AArnott]

I believe you'll have to also request generation of the IFileOpenDialog interface. I can't remember off-hand how to properly request the object (it may not be as simple as new FileOpenDialog()), but once you have it, you can cast to the interface and then call methods on that.

[MikeYeager]

Hi @AArnott. Thanks for the quick response. I actually tried that (I tried a lot of things!), but using the interface seems as difficult as using PInvoke. For instance, there is a .SetFileName() method to set the default file name for the dialog, but it takes a Windows.Win32.Foundation.PCWSTR as a parameter. There is a constructor on that class that takes a char* as an argument, but that's not exactly C#. Shouldn't the generated code be callable by C# without having to resort to unsafe code and explicit marshalling? I feel like I'm really missing something here.

[AArnott]

CsWin32 generates interop signatures based on those found in the normative C header files. We do try to make things easier where possible (e.g. generate helper methods that take string instead of PCWSTR) in addition to the pointer-based methods, but unsafe is often required, and even more often desirable over the IntPtr alternative. Because ironically, unsafe code is often easier to read, write, and get right than the so-called "safe" alternative that involves manual memory management and untyped IntPtrs.

In particular for your example, the SetFileName method is defined on the interface with PCWSTR, and it's should also be available as an overload or extension method that takes string. When allowMarshaling: false is set, this friendly overload is declared right next to the original method. But when allowMarshaling: true, it's declared as an extension method.

Here is a working example:

using Windows.Win32;
using Windows.Win32.UI.Shell;

PInvoke.CoCreateInstance(
    typeof(FileOpenDialog).GUID, 
    null, 
    Windows.Win32.System.Com.CLSCTX.CLSCTX_INPROC_SERVER, 
    out IFileOpenDialog openDialog).ThrowOnFailure();
openDialog.SetFileName("hi");
openDialog.Show(default);

NativeMethods.txt:

FileOpenDialog
IFileOpenDialog
CoCreateInstance

[MikeYeager]

Thank you for the reply and the sample. It's interesting to me that when using CoCreateInstance() (vs new) the SetFileName() method has an overload that takes a string. Unfortunately, GetFileName() doesn't have an overload that returns a string (with either approach). I tried setting allowMarshalling: false in a NativeMethods.json file and figured out how to code that approach, but GetFileName() still only returns a PWSTR or PWSTR* and the SetFileName() call blows up. Going back to your original example (above), I added openDialog.GetFileName(out Windows.Win32.Foundation.PWSTR name); but when I ran it, GetFileName() returns a pointer to "hi", even after I chose a valid file. The GetSelectedItems() call blows up.

I really appreciate your work and your effort to help me figure this out. I don't do a lot of C or C++ programming and even less Win32 programming, so I'm really starting to get confused as to which approach using CsWin32 is best or how I would even know to try them. I was hoping this would simplify using the Win32 dialogs, but I think this might just be the wrong approach for me as I'm not a Win32 or COM Interop expert. I think I can find examples using DllImport attributes for most, if not all of the dialogs I need to implement. Using MarshalAs attributes seems straightforward and I think I can figure out how to approach any dialogs I can't find existing examples for. The CsWin32 approach, without any available examples and the potential that on any given day the code could break due to changes in this package or changes in the metadata it uses seems less appealing, especially since the convenience methods are still missing. Perhaps I'll take another look in a year or so.

Thanks again,
Mike

[AArnott]

especially since the convenience methods are still missing

Which convenience methods are missing?

Yes, we do expect that over time some additional convenience methods (more friendly overloads) will be generated. But this will always be interop, which requires that you are quite familiar with the native methods. This will not ever evolve into generating BCL-like friendly APIs that are obviously optimized for a premium .NET experience. That will always be hand-crafted additional APIs written independently of CsWin32.

I added openDialog.GetFileName(out Windows.Win32.Foundation.PWSTR name); but when I ran it, GetFileName() returns a pointer to "hi", even after I chose a valid file.

This goes back to my point that you have to understand the underlying native APIs. The docs indicate that GetFileName should not be used for this purpose. You should use GetResult instead. That gives you an IShellItem, which you then call GetDisplayName on. That gives you a PWSTR, which you can easily call .ToString() on to get a string. CsWin32 will likely never make this easier because, per the docs and as is common with any API that returns a string, the caller often has obligations with regard to memory freeing that are unique to that API and for which you must read the docs. This isn't something the metadata is likely to ever express and thus in C# you must write very similar code for memory management during interop that you would have to write in C. That's a hidden challenge in interop because you'll have it "working" but if your memory management is off, your app could crash due to corrupted memory, or a memory leak, etc.

So, reading the native API docs I was able to get your next step working fairly quickly:

using System;
using System.Runtime.InteropServices;
using Windows.Win32;
using Windows.Win32.Foundation;
using Windows.Win32.UI.Shell;

unsafe
{
    PInvoke.CoCreateInstance(
        typeof(FileOpenDialog).GUID,
        null,
        Windows.Win32.System.Com.CLSCTX.CLSCTX_INPROC_SERVER,
        out IFileOpenDialog openDialog).ThrowOnFailure();
    openDialog.SetFileName("hi");
    openDialog.Show(default);
    openDialog.GetResult(out IShellItem item);
    item.GetDisplayName(SIGDN.SIGDN_FILESYSPATH, out PWSTR name);
    Console.WriteLine(name.ToString());
    Marshal.FreeCoTaskMem(new IntPtr(name.Value));
}

Interop is harder than managed APIs, no doubt. What I have above may get slightly easier over time as CsWin32 improves, but likely not by much.

I tried setting allowMarshalling: false in a NativeMethods.json file

This will generally produce APIs that are harder to call. It's there for game developers or similar where absolute bare-metal perf is required.

The GetSelectedItems() call blows up

The method returns E_FAIL (which ends up throwing an exception into the app) when I add that call as well. That presumably would happen in C as well, so I would approach that problem by studying the docs to see what the calling pattern is. It likely will work if you set certain properties, flags, make prior method calls, and/or make different selections in the dialog itself.

I was hoping this would simplify using the Win32 dialogs

Dropping from BCL libraries to interop is unlikely to simplify anything. Interop is useful for speed or accessing Win32 functionality that the BCL doesn't expose.

I think this might just be the wrong approach for me as I'm not a Win32 or COM Interop expert

I totally respect that. Interop is a tough area. CsWin32 makes it easier by not requiring you to hand-author the C# interop APIs yourself, but interop itself is a broad topic and can still be quite hard to get right.

[MikeYeager]

@AArnott thank you so much for your time and your patience.