SystemInformation helper throws an exception with Unpackaged Windows App SDK projects

[gus33000]

Describe the bug

Upon using the SystemInformation class, the following exception is thrown in unpackaged Windows App SDK projects:

• Is this bug a regression in the toolkit? If so, what toolkit version did you last see it work:

Steps to Reproduce

• Can this be reproduced in the Sample App? (Either in a sample as-is or with new XAML pasted in the editor.) If so, please provide custom XAML or steps to reproduce. If not, let us know why it can't be reproduced (e.g. more complex setup, environment, dependencies, etc...)

Steps to reproduce the behavior:

1. Create a new Blank Windows App SDK app (Packaged)
2. Perform the required modifications to the project so it runs unpackaged (https://aka.ms/winui3/unpackaged-apps)
3. Add the following code in mainwindow.xaml.cs:

        private void myButton_Click(object sender, RoutedEventArgs e)
        {
            myButton.Content = "Clicked";
            SystemInformation info = SystemInformation.Instance;
        }

4. Install the Windows App SDK runtime if not already installed (https://aka.ms/windowsappsdk/1.0-preview3/msix-installer)
5. Start the application
6. Click on the button
7. The call to SystemInformation.Instance fails

Expected behavior

SystemInformation.Instance doesn't fail and provides a subset of the values that are available without a package identity, or if not possible, throws a more friendly exception.

Environment

NuGet Package(s):

• CommunityToolkit.WinUI.UI.Controls
• Microsoft.WindowsAppSDK (1.0.0-preview3)
• Microsoft.Windows.SDK.BuildTools (10.0.20348.19)

Package Version(s):

7.1.1-preview3

Windows 10 Build Number:

• Fall Creators Update (16299)
• April 2018 Update (17134)
• October 2018 Update (17763)
• May 2019 Update (18362)
• May 2020 Update (19041)
• Insider Build (22000.282)

App min and target version:

• Fall Creators Update (16299)
• April 2018 Update (17134)
• October 2018 Update (17763)
• May 2019 Update (18362)
• May 2020 Update (19041)

Device form factor:

• Desktop
• Xbox
• Surface Hub
• IoT

Visual Studio version:

• 2022 (17.Preview/17.0.0-pre.7.0+31825.309)

Hello gus33000, thank you for opening an issue with us!

I have automatically added a "needs triage" label to help get things started. Our team will analyze and investigate the issue, and escalate it to the relevant team if possible. Other community members may also look into the issue and provide feedback 🙌

[gus33000]

The issue seems to be caused by the following call which will fail under applications with no package identity:

WindowsCommunityToolkit/CommunityToolkit.WinUI/Helpers/SystemInformation.cs

Line 41 in 07fa14d

ApplicationName = Package.Current.DisplayName;

I don't think the other fields would actually fail in the same way with no package identity available.

[michael-hawker]

Thanks @gus33000 we haven't checked unpackaged support yet with the Toolkit. Not sure if there's an alternative method we can call to get the app name in unpackaged scenarios?

[gus33000]

Thanks @gus33000 we haven't checked unpackaged support yet with the Toolkit. Not sure if there's an alternative method we can call to get the app name in unpackaged scenarios?

The only way I think that is standardized of setting an application name without a package probably would be AssemblyInfo for .NET apps. We could get the package version name copyright and more using this.

I was wondering if it would not be a good idea to make a Package like class but for unpacked apps as some sort of shim. UWP apps and Unpackaged apps would use this class to get the same info but different methods behind the scenes would be applied to get different properties.

Same idea could be applied to make an ApplicationData shim?

[zateutsch]

Update:
Some of the SystemInformation class functionality is dependent on ApplicationDataStorageHelper, which also doesn't support unpackaged scenarios (no Application Data without Package identity).

Will need to address both for proper functionality in WinUI3 unpackaged apps.