Will MFE be also published to the Microsoft Store?

[Void48]

Any plans for this? 😁

[xmine64]

@FireCubeStudios said he wants to do that.
I can't do it myself because I don't have enough money to buy ms developer account, so if he doesn't do that I can't do it neither but I release MSIX packages as well.

[Void48]

@FireCubeStudios said he wants to do that. I can't do it myself because I don't have enough money to buy ms developer account, so if he doesn't do that I can't do it neither but I release MSIX packages as well.

ah nice 👍🏻

[xmine64]

We have a problem here.

[dongle-the-gadget]

Well MSIX packaging is super broken so probably a damn long time.

[xmine64]

It works when you build it from command-line, this is Visual Studio's bug.

[dongle-the-gadget]

It works when you build it from command-line, this is Visual Studio's bug.

Literally everything breaks.

[xmine64]

Literally everything breaks.

what do you mean, it works fine when I build it from command-line.

[dongle-the-gadget]

Literally everything breaks.

what do you mean, it works fine when I build it from command-line.

The way we have now is just kind of a workaround.

[xmine64]

The way we have now is just kind of a workaround.

Yes, I thought you mean that's broken too

[dom6770]

It would be also awesome if you could release it on chocolatey.

[dongle-the-gadget]

It would be also awesome if you could release it on chocolatey.

Does Chocolatey support MSIX tho, since having to create another installer would be kind of crazy.

[sitiom]

@vedantmgoyal2009 I think the problem currently with adding it to Winget is that the msixbundle is self-signed, and so you would have to manually add it to your trusted store first before installing, which is not secure and not even supported by Winget yet (microsoft/winget-cli#424).

The best solution to this would be to course, publish it to the Microsoft Store where they would sign it themselves, which brings us back to this issue. So this needs to be resolved first before adding it to anything else (Winget, Chocolatey).

Side note: MFE is already in Scoop (uses the portable version), and is now being updated to the new version in ScoopInstaller/Extras#8181.

[xmine64]

MFE is already in Scoop

Cool, I'm being famous

For winget I can create an Inno Setup wizard, winget supports installers too, not just msix.

[sitiom]

For winget I can create an Inno Setup wizard, winget supports installers too, not just msix.

MSIX works, don't create another installer.

Does Chocolatey support MSIX tho, since having to create another installer would be kind of crazy.

And yes, it supports MSIX. See Windows Terminal package.

[dongle-the-gadget]

For winget I can create an Inno Setup wizard, winget supports installers too, not just msix.

MSIX works, don't create another installer.

Does Chocolatey support MSIX tho, since having to create another installer would be kind of crazy.

And yes, it supports MSIX. See Windows Terminal package.

Unfortunately the way we package MSIX is super broken. None of our attempts have been accepted by the Store so far.

[sitiom]

Unfortunately the way we package MSIX is super broken. None of our attempts have been accepted by the Store so far.

I suggest we fix that first.

[xmine64]

I suggest we fix that first.

You suggest but the problem is it can't be fixed. We can't publish a xaml island to store. We are waiting for App SDK 1.1 release to migrate to WinUI 3.

[dongle-the-gadget]

I suggest we fix that first.

You suggest but the problem is it can't be fixed. We can't publish a xaml island to store. We are waiting for App SDK 1.1 release to migrate to WinUI 3.

There is one way I know: Use VS 16.9

[sitiom]

Another question is why is MFE still using .NET Core? aren't we supposed to be in .NET 6 already? (and .NET Core EOL is in a few months.)

[dongle-the-gadget]

Another question is why is MFE still using .NET Core? aren't we supposed to be in .NET 6 already? (and .NET Core EOL is in a few months.)

No, XAML Islands makes it impossible for us to use .NET 5 or any newer version. We could try moving to .NET Framework though.

[xmine64]

.NET 5 removed builtin WinRT support from compiler, so we need a custom compiled version of CsWinrt that supports XAML Islands, or we need to move to WinUI 3. I tried to use .NET Framework 4.8, it supports XAML Islands but WinUI 2.8 was broken on it. We planned to move to WinUI 3 after AppSDK 1.1 release, because this version adds Mica support so we can keep Mica backdrop on background of Settings page.

[dongle-the-gadget]

.NET 5 removed builtin WinRT support from compiler, so we need a custom compiled version of CsWinrt that supports XAML Islands, or we need to move to WinUI 3. I tried to use .NET Framework 4.8, it supports XAML Islands but WinUI 2.8 was broken on it. We planned to move to WinUI 3 after AppSDK 1.1 release, because this version adds Mica support so we can keep Mica backdrop on background of Settings page.

But we will have to sacrifice good rendering and fast UI though.

[xmine64]

But we will have to sacrifice good rendering and fast UI though.

WinUI 3 is really that slow?

[dongle-the-gadget]

But we will have to sacrifice good rendering and fast UI though.

WinUI 3 is really that slow?

https://github.com/microsoft/microsoft-ui-xaml/issues?q=is%3Aopen+label%3Aproduct-winui3+slow+performance+is%3Aissue+

And also MS official docs says there is a "slight disadvantage" in performance in WinUI 3: https://docs.microsoft.com/en-us/windows/apps/windows-app-sdk/migrate-to-windows-app-sdk/what-is-supported

[xmine64]

still there's no other choice, except ModernWpf or C++.

[dongle-the-gadget]

still there's no other choice, except ModernWpf or C++.

ModernWpf doesn't have WinUI 2.6+ styles

[AZProductions]

.NET 5 removed builtin WinRT support from compiler, so we need a custom compiled version of CsWinrt that supports XAML Islands, or we need to move to WinUI 3. I tried to use .NET Framework 4.8, it supports XAML Islands but WinUI 2.8 was broken on it. We planned to move to WinUI 3 after AppSDK 1.1 release, because this version adds Mica support so we can keep Mica backdrop on background of Settings page.

You can re-enable WinRT in .NET 6 if you target msix packaging.

[xmine64]

.NET 6 also doesn't come with a native WinRT interop. The interop that C#/WinRT provides (TFM) is very miniature and inappropriate for our use case.

We can write an UWP app with a desktop bridge, then we can put Settings UI in UWP app and tray icon and MFE's actual logic in a win32 app. In this case we will lose ability to use modern context menu for tray icon but we don't need XAML Islands and we can publish app to store easily, also it fixes context menu bugs on Windows 10.

[dongle-the-gadget]

Don't think it's possible to do that though.

[xmine64]

Don't think it's possible to do that though.

I've already seen apps with this approach

[dongle-the-gadget]

I was talking about the context menu.

[xmine64]

I was talking about the context menu.

uh Ig we just have to use classic context menu, I said we lose ability to use modern context menu.

[xmine64]

Update: @dongle-the-gadget started working on C++ version of original MFE (we already have an unofficial C++ win32-based version with basic abilities of MFE by @rounk-ctrl, see here). I'll help him as soon as I have free time. There will be no problem for publishing that C++ version on store, except a valid certificate that @FireCubeStudios said he would help.

[dongle-the-gadget]

For some clarity, rounk-ctrl's port is unofficial. Mine is currently in private development (the repo is in the MicaForEveryone organization).

[dongle-the-gadget]

We are still focused on getting at least one version on the Microsoft Store though… And we want it to be MSIX.

[sitiom]

In the coming months, winget will start accepting portable softwares. Then we can put the same portable version on winget which is currently on scoop.

Portable software in zip files?

[sitiom]

Hmm, okay. microsoft/winget-cli#140 would have to be solved first before the portable zip version can be added to Winget.

[xmine64]

Creating an installer for winget won't be that hard. I can do that already in like 5 minute.

[sitiom]

Creating an installer for winget won't be that hard. I can do that already in like 5 minute.

Going back to #36 (comment), you already have an MSIX installer. Why not just use that? You only need a certificate for it.

[xmine64]

Why not just use that? You only need a certificate for it.

I don't have a valid certificate and a xaml island mixed with .NET Core can't be uploaded to store.

[sitiom]

I don't have a valid certificate

You said @FireCubeStudios would help on this.

a xaml island mixed with .NET Core can't be uploaded to store.

Sure, not on the store, but allowed on Winget (I don't see a policy disallowing it; just as long as it installs successfully).

[dongle-the-gadget]

@FireCubeStudios assist us in uploading the app to Microsoft Store. They don’t have a valid cert issued by a trusted CA.

[xmine64]

a xaml island mixed with .NET Core can't be uploaded to store.

I wonder if we can upload C++ version to store, it still contains compiled .NET Native code. Only applicable approach is using desktop bridge or using WinUI 3.0. Right now main app is .NET Core app and we have a helper UWP app for UI. In desktop bridge main app is UWP and there's a helper win32 executable to do stuff outside of UWP sandbox.

[sitiom]

Oh, alright. How about the possibility of migrating to WinUI 3 now? WindowsAppSDK 1.1 has already been released for while, so you can keep Mica backdrop now.

[dongle-the-gadget]

I don't think the C++ version has any C# code currently, and I genuinely don't think C# WinRT Components would just fail certification.

[dongle-the-gadget]

Oh, alright. How about the possibility of migrating to WinUI 3 now? WindowsAppSDK 1.1 has already been released for while, so you can keep Mica backdrop now.

There are still quite a lot of problems with WinUI 3, particularly with rendering and out of bounds context menus.

[xmine64]

out of bounds context menus

With desktop bridge we have to use legacy context menu too, same with WinUI 3.0
Is there any app with xaml island already on store? Using inline xaml instead of UWP helper app would solve store problem too, I did that on new rule dialogs for dynamic content.

[dongle-the-gadget]

Is there any app with xaml island already on store?

Aurora, Inkscape? (all .NET Core 3.1 compiled using VS 16.9)

[xmine64]

Aurora

Need to check, Store is OK with XAML Islands, UWP helper is the problem.

UPDATE: It's WPF

Inkscape

You mean the OSS alternative to Adobe Illustrator? It has XAML Islands?

[dongle-the-gadget]

I remembered the wrong name... It's Ink Workspace

[dongle-the-gadget]

IIRC the dev of Aurora has tweeted publicly about a version of it that supposedly uses Islands.

[sitiom]

Need to check, Store is OK with XAML Islands, UWP helper is the problem.

Have you considered using this: https://github.com/lepoco/wpfui

Or this: https://github.com/Kinnara/ModernWpf

[dongle-the-gadget]

I turned them down.

[dongle-the-gadget]

I think that’s no good…

[xmine64]

It'll be possible to put MFE to Store once we switch to C++. Problem is we have a UWP helper project that's not our app's main project, and it's in C#. We can put MFE to store even if we don't fully switch to C++ and just rewrite the UWP helper in C++.
Also this restriction should be a bug, we may can get help from someone inside Microsoft.

[dongle-the-gadget]

Also this restriction should be a bug, we may can get help from someone inside Microsoft.

The bug report has been left abandoned for quite some time though, and also .NET 3 would reach EoS within 2 months.