WinUi 3 desktop app doesn't open camera. and is there any way that can open default system camera and capture image

[sangitamalviya]

CameraCaptureUI captureUI = new CameraCaptureUI();

        StorageFile photo = await captureUI.CaptureFileAsync(CameraCaptureUIMode.Photo);

        if (photo != null)
        {
            CameraCapture.Source = new BitmapImage(new Uri(photo.Path));
        }

CameraCaptureUI it doesn't open camera. even CaptureElement does not find on UI

[JaiganeshKumaran]

I think CameraCaptureUI requires you to invoke IInitializeWithWindow and pass the window handle.

[sangitamalviya]

hi @JaiganeshKumaran , https://gist.github.com/wbokkers/cc8bcc7bc5a646b82a4d41b337330c69 here FileOpenPicker IInitializeWithWindow . I was same tried for CameraCaptureUI IInitializeWithWindow,but it's giving Exception "Element Not Found".I do not know CameraCaptureUI have different Guid or not.

[jonwis]

Looks like the CameraCaptureUI does not support IInitializeWithWindow, and expects the caller to be on a CoreWindow thread. The implementation uses multiple pickers and launchers that need the "with window" treatment. It's an interesting candidate for open-sourcing the implementation for improvement.

[craigomatic]

Is there any workaround in the meantime?

[applefanbois]

Just do exactly like Apple and everything will be fine. I know this new Windows SDK is 15 years behind the SDK of Android and Apple, so I won't be too mean. Our app cannot release until we have access to the camera, we need to be able to scan documents with a camera.

[JaiganeshKumaran]

Looks like the CameraCaptureUI does not support IInitializeWithWindow, and expects the caller to be on a CoreWindow thread. The implementation uses multiple pickers and launchers that need the "with window" treatment. It's an interesting candidate for open-sourcing the implementation for improvement.

CameraCaptureUI is probably implemented as a wrapper on Launcher::LaunchUriForResultsAsync as it opens the Windows Camera app in a modal dialog, but Launcher::LaunchUriForResultsAsync doesn't work in desktop apps.

[JoeyLiang-0]

Any update on this issue?

[applefanbois]

No, surely things will get resolved over time. After all, the hide-task-bar is still not working half the time 25 years later in Windows 11.

[janseris]

@jonwis What happens with this issue, please? This bug is now included in official release of .NET MAUI. That's not good.

[XeonKHJ]

Still wating for this issue to be resolved.

[aletfa]

+1 here.
One of the reasons that lead us to believe in MAUI is the possibility of using the HW of the devices, the camera is the most important among them.

[janseris]

@jonwis any progress?

[bit-wrangler]

So, is this bug the reason why the "Camera" permission is listed as not supported for Windows on this MAUI docs page? https://docs.microsoft.com/en-us/dotnet/maui/platform-integration/appmodel/permissions?tabs=ios#available-permissions
This is a pretty important feature to be missing on a platform.

[castorix]

You can use DirectShow (WinUI3_DirectShow_Capture)
or Windows Media Foundation or AVICap for camera capture

[sangitamalviya]

I used CameraCaptureUI with Winui 2
https://docs.microsoft.com/en-us/uwp/api/windows.media.capture.cameracaptureui?view=winrt-22621

[anovik]

CameraCaptureUI works fine in UWP but doesn't work in WinUI3.

[1888games]

Any progress on this? A similar thing is happening for me using the Windows.Devices.PointOfService.PosPrinter API, calling PosPrinter.FromIdAsync(deviceInfo.id) returns null in MAUI/WinUI3. Exactly the same code, with the same pointOfService capability enabled in the mainifest, works fine with Xamarin Forms/UWP.

This would normally pop up a dialog for the user to confirm they want to pair with the printer, so I'm guessing this is a similar issue to this:

#1034 (comment)

[brokenthorn]

Any progress on this? A similar thing is happening for me using the Windows.Devices.PointOfService.PosPrinter API, calling PosPrinter.FromIdAsync(deviceInfo.id) returns null in MAUI/WinUI3. Exactly the same code, with the same pointOfService capability enabled in the mainifest, works fine with Xamarin Forms/UWP.

This would normally pop up a dialog for the user to confirm they want to pair with the printer, so I'm guessing this is a similar issue to this:

#1034 (comment)

Don't the docs say that the Windows.Devices.PointOfService namespace is for UWP apps only?

[1888games]

Well, they come under /UWP in the docs hierarchy but it seems strange that this whole swathe of useful, generic device functionality is only available to UWP apps. If it is UWP only, the namespace Windows.Devices.PointOfService is not very clear, it suggests to me that any Windows app whether written in C++, C# or VB.Net, and using any UI framework, should be able to use it.

It's not like we have a choice - Xamarin is being deprecated, UWP is clearly being phased out and MAUI only supports WinUI3. Two years into a project to port a legacy system to modern cross-platform technologies we have essentially had the rug pulled from under us.

After all, most of this stuff - cash drawers, stripe readers, receipt printers etc - does not require any UI, especially in a non-sandboxed world outside of UWP. The dialog that asks you to pair with the printer (it's not even bluetooth, just ethernet) is completely unnecessary in a commercial environment, it preferably just gets done silently in the background.

Fortunately one of the brand of printers we use has their own SDK but we switched away from that to give us the flexibility to switch to any other brand that supports the POS standard. Hopefully there will be no issues with switching back...

[Zacharianel]

I'm having the same issue while developing in .NET Maui. Using the .NET Maui Apis, I need to be able to use both MediaPicker.Default.CapturePhotoAsync() and MediaPicker.Default.CaptureVideoAsync() to take a photo and video.

According to the documentation it should work in Windows: https://learn.microsoft.com/en-us/dotnet/maui/platform-integration/device-media/picker?tabs=windows ...but it doesn't work.

Any progress fixing things?

I have the same problems. Any info?

[ackh]

My UWP app uses DisplayRequest, CaptureElement, MediaCapture, BarcodeScanner and ClaimedBarcodeScanner to implement a QR code scanner. All of these APIs should be made available by the Windows App SDK.

I know that I could implement this myself in a different way when migrating to the Windows App SDK. But why would I have to? A QR code scanner is such a standard building block that it just makes no sense at all not having it in the Windows App SDK.

[nikolayvpavlov]

It is sad that nobody from Microsoft steps in to say when this will be fixed. As a result of WinUI's fault, this is broken in both Maui and Uno. And I must develop an app that captures pictures... Sweet, isn't it.

[ackh]

@nikolayvpavlov I haven't tried this myself but I have seen a workaround for taking pictures here. Maybe it helps.

[janseris]

@jonwis @btueffers after 6 months I am asking again, any progress? Who is responsible for these issues? Why is (seemingly) noone doing anything?
This issue directly affects .NET MAUI.

[applefanbois]

Stop it, don't hurt yourself anymore. Microsoft has abandoned Windows 15 years ago. You should port your app to Android and it will run natively on Windows 11 from the Amazon Store. We are in the same situation, the code is done since 2019 but we are still waiting for MS to provide us with a working webview that support Web 2.0. Webview2 is still not working, It is unusable.

We are stuck with a useless windows app for 3 years now and it will never work. MS is 15 years behind Android, iOS, macOS, Linux... They don't care about new apps. Microsoft is only used to run legacy software nowadays.

Good luck my friend. You should not keep trying at this point, Microsoft does not love you.

[mattleibow]

I think this PR will fix mui by using the cool community code, but maybe it can somehow be integrated into this SDK? dotnet/maui#13220

[castorix]

one alternative is using the MediaCapture, MediaFrameReader, and relative classes, then, then render each frame to an XAML Image control.

Or also IMFCaptureEngine that I tested on Windows 10 (WriteableBitmap + Image control), with audio/video recording easy to use (StartRecord does all the work, without implementing IMFCaptureSink)

[NicholasChrzan]

I found a work around that works in 1.2 it uses LaunchUriForResultsAsync in a self-contained WinUI3 x64 desktop app (which I put together from various partial examples I found online):

public class CustomCameraCaptureUI
{
    private LauncherOptions _launcherOptions;

    public CustomCameraCaptureUI()
    {
        var hndl = App.WindowHandle;  //Helper which calls WinRT.Interop.WindowNative.GetWindowHandle on the main window

        _launcherOptions = new LauncherOptions();
        InitializeWithWindow.Initialize(_launcherOptions, hndl);

        _launcherOptions.TreatAsUntrusted = false;
        _launcherOptions.DisplayApplicationPicker = false;
        _launcherOptions.TargetApplicationPackageFamilyName = "Microsoft.WindowsCamera_8wekyb3d8bbwe";
    }

    public async Task<StorageFile> CaptureFileAsync(CameraCaptureUIMode mode)
    {
        var extension = mode == CameraCaptureUIMode.Photo ? ".jpg" : ".mp4";

        var tempFolder = await StorageFolder.GetFolderFromPathAsync(System.IO.Path.GetTempPath());
        var tempFileName = $"CCapture{extension}";
        var tempFile = await tempFolder.CreateFileAsync(tempFileName, CreationCollisionOption.GenerateUniqueName);
        var token = Windows.ApplicationModel.DataTransfer.SharedStorageAccessManager.AddFile(tempFile);

        var set = new ValueSet();
        if (mode == CameraCaptureUIMode.Photo)
        {
            set.Add("MediaType", "photo");
            set.Add("PhotoFileToken", token);
            set.Add("MaxResolution", (int)MaxResolution);
            set.Add("Format", 0);
            
        }
        else
        {
            set.Add("MediaType", "video");
            set.Add("VideoFileToken", token);
        }

        var uri = new Uri("microsoft.windows.camera.picker:");
        var result = await Windows.System.Launcher.LaunchUriForResultsAsync(uri, _launcherOptions, set);
        if (result.Status == LaunchUriStatus.Success)
        {
            return tempFile;
        }

        return null;
    }

    public CameraCaptureUIMaxPhotoResolution MaxResolution { get; set; } = CameraCaptureUIMaxPhotoResolution.HighestAvailable;
}

[TimVanDyke]

Thank you @NicholasChrzan for the workaround. Found this from this trail:

dotnet/maui#5849

#3241

I need this for a dotnet MAUI project.

OK now @microsoft SERIOUSLY? This is STILL an issue after 2 years?

Does anyone see the create date is JULY 3 2021? What's going on over there?

[Brosten]

Another vote from a Xamarin user currently converting to .net Maui. Rather surprised to find THIS still being an issue.

[mattleibow]

I think we worked around this by launching the camera app directly in maui: dotnet/maui#13220

This should be working in .NET 8 now. Does Windows have the ability to change the "default camera app"? Not sure if we are losing a feature by launching the windows camera directly. Not sure I ever saw a way to set an alternate default.

Another question would be if the code is correct (or as correct as a workaround can be) or if we are missing something?

[Saharsh979]

Hi everyone,
We’ve added a new CameraCaptureUI API as part of the WASDK 1.7 Experimental 1 release. The updated API is now available, and we've also added samples for both C++ and C# to demonstrate its usage.
WindowsAppSDK-Samples/Samples/CameraCaptureUI at release/experimental · microsoft/WindowsAppSDK-Samples

To test, please retarget your project to WASDK version 1.7.241114004-experimental1.

As an optional step, you can enable the "Send diagnostic data" option to help us gather data on the API’s reliability. Please check this box under: Privacy & security -> Diagnostics & Feedback -> Send Optional Diagnostic data!
We’d appreciate your feedback on whether the samples and API usage are clear, and if the fix works as expected

[nikolayvpavlov]

CameraCaptureUI cameraUI = new CameraCaptureUI(windowId);
This is not pleasant and something that should be improved. It must be possible to pass the current page / window / parent in the constructor, and it should be able to do the rest automatically.

var file = await cameraUI.CaptureFileAsync(CameraCaptureUIMode.Photo);
It is a bit limiting that we can only capture on a file. Is it possible to extend the functionality of UWP, and capture on a stream?

Last, but not least: all these helpers in MainWIndow.xaml.cs must be integral part of the API without need for interop with Win32.

[mattleibow]

I think in the old days, UWP was sort of a "single window" world, so none of this mattered. But with WinUI and all the multi-window worlds, a modal dialog has to block some window and thus you need to specify which one.

Some magic could be added if you only have one window, then just use that. But, this now adds a layer of "worked when I did this, but now crashes with missing window errors" because the first test you only had 1 window, and the second test you had 3 windows.

I think it all has to do with the modal window idea. Maybe this API should not be blocking and have a non-modal option? So if you don't pass in a window ID then it just pops up a dialog with no blocking of the other windows.

[Saharsh979]

Hi @nikolayvpavlov
Thank you for taking the time to test the new CameraCaptureUI API and for sharing your valuable feedback!

Regarding your points:

WindowId Constructor Parameters: We appreciate your suggestion to make the constructor more intuitive by passing the current page/window/parent directly. However, for now, we’ve kept the windowId parameter to ensure to support WinUi3 AppWindow (has Id()) & Window, and also Win32 apps which might be using HWNDs. Could you elaborate on the difficulties you see with the WindowId?

Capture on Stream: Great feedback. For WASDK1.7 release, our primary goal is to uplift the original UWP CameraCaptureUI API and support it in the WinAppSDK. We will explore it in upcoming release.

[Saharsh979]

@mattleibow Thank you for sharing your thoughts.

We believe the current behavior of blocking the window is by design. The CameraCaptureUI flow is intended to be a modal interaction, meaning it should start and complete before allowing other user interactions. This ensures the camera capture process is smooth and doesn’t conflict with other UI actions, there also might be hardware limitations.

Could you elaborate on the issue you mentioned: "worked when I did this, but now crashes with missing window errors"?