Add async/await support for all long-running DISM operations (fixes #82)

[Rolling2405]

Closes #82

The DISM API is entirely synchronous, blocking the calling thread during long-running native operations. This causes UI freezes in WPF/WinForms/MAUI apps. As noted in #82, wrapping calls in Task.Run alone does not solve the problem because the native progress callback fires on the calling thread.

This PR adds *Async counterparts for all 17 public methods that accept a DismProgressCallback, using the TaskCompletionSource pattern suggested by @jeffkl in the issue thread.

Implementation

• Pattern: TaskCompletionSource<bool> + Task.Factory.StartNew with TaskCreationOptions.LongRunning — not Task.Run, since native DISM calls are truly long-running blocking operations
• Progress: IProgress<DismProgress> instead of DismProgressCallback (standard .NET async pattern)
• Cancellation: CancellationToken wired to DismProgress.Cancel = true, which signals the native EventWaitHandle. CancellationToken.None is passed to Task.Factory.StartNew to ensure the delegate always runs — cancellation is handled inside the delegate to avoid hanging tcs.Task

Usage

// Before: blocks the calling thread
DismApi.AddPackage(session, packagePath, ignoreCheck: true,
    preventPending: false, callback, null);

// After: non-blocking with standard IProgress<T> / CancellationToken
await DismApi.AddPackageAsync(session, packagePath, ignoreCheck: true,
    preventPending: false,
    progress: new Progress<DismProgress>(p => progressBar.Value = p.Current),
    cancellationToken: cts.Token);

[Rolling2405]

Hi @jeffkl, I’m aware there’s a merge conflict with main. I’m away from my computer for a while — since maintainer edits are enabled, feel free to resolve it directly if you’d like to review sooner. Happy to fix it myself when I’m back if you’d prefer. Thanks for considering this!

[jeffkl]

I'm going to push a bunch of changes, I want to enforce a coding style but realized I don't have enough in place to do so. Commits incoming...

[jeffkl]

@Rolling2405 there are other operations that don't use progress but can take some time like opening a session, adding/removing drivers, etc. Should we add Async methods for everything? Those one's just wouldn't have progress. I never use the API in a UI so I'm not sure what users would want.

[Rolling2405]

Yes, I think it makes sense to add async versions for those too even without progress. Any operation that can block the UI thread is worth making awaitable, so callers aren’t forced to wrap everything in Task.Run themselves.

[Rolling2405]

@jeffkl what do you think about this?

[jeffkl]

@Rolling2405 sorry been slammed as of late and I'm out on vacation starting tomorrow. I've noticed that some of the new tests fail sporadically when I run all tests together but not when I run them individually, been trying to debug that.

I'm completely fine with making all APIs that take some time but don't have progress be async.

[Rolling2405]

@jeffkl When you get a chance, can you please take a look and see if things look good for merging? Thanks!

[jeffkl]

I'm back from vacation, I'm taking a look. Copilot didn't do a very good job on the implementation but I'm making progress...

[jeffkl]

@Rolling2405 question for you. Not all DISM functions take progress, so I don't think they can be canceled. For example. DismAddDriver.

If we add DismApi.AddDriverAsync(DismSession, string, bool, CancellationToken), then cancellation would happen on the task started by Task.Factory.StartNew() rather than DISM itself, meaning if the caller cancelled it, the task would still run to completion in the background.

So should we add async calls to all possible methods after all? Or just to the ones that support progress and therefore can actually be canceled by DISM?

[Rolling2405]

@jeffkl In that case maybe we should just add it to the ones that support progress so the user can actually cancel when they want to