Is there a way to convert this to "not a Microsoft Store app" ?

[by321]

Being a Microsoft Store app carries too much unexpected issues, while I have no intention of make a Microsoft Store app here,

[axodox]

What is the goal you would like to achieve?

I chosen the current solution as I intend to submit this app in the Store in the future, and also since this way it does work on the Xbox as well. I have some plans with 3D model generation in the future, but that won't be limited with the UWP app model.

Besides, this is just a UI, the lib doing the actual heavy lifting has a non-UWP build as well. If you look to support different platforms, e.g. MacOS the best would be to create a native MacOS UI which fits the OS best and reuse the lib only.

It would easily possible to convert this app to the Windows App SDK (which is mostly just renaming a few namespaces in the code) which would allow it to run from an unpackaged exe, however the last time I have tried it, it still seemed to not up to par in functionality with the UWP stack.

[axodox]

carries too much unexpected issues,

Can you describe the issues you encountered?

[by321]

The latest issue, which I could not fix after searching the internet and trying all solutions (except reinstalling Visual Studio or Windows (yes that's actually a suggested solution)), is this:

---------------------------
Microsoft Visual Studio
---------------------------
Unable to activate Windows Store app . The activation request failed with error 'Operation not supported. Unknown error: 0x80040904'.

See help for advice on troubleshooting the issue.
---------------------------
OK   Help   
---------------------------

The stupid thing is, I was able to run it once, it reached the model selection UI. I had no model installed, so I shutdown the app, went to deal with models. After setting up a model, I keep getting that message after seeing the splash screen and could not go further.

One more thing: every time I run the app from Visual Studio (Start without debugging), it does a rebuild, even when I changed nothing and just clicked "Start without debugging" twice in a row.

[axodox]

If it did worked once, it sounds like a corrupted build, which happens sometime in VS.

You can usually resolve it by closing VS then deleting the following folders manually:

• unpaint / bin, obj, generated files
• .vs / everything but the .suo
• you could also go to unpaint in the start menu, right click and uninstall it

BTW which VS and Windows versions do you have?

[by321]

What is the goal you would like to achieve?

Mostly I just want to play with SD in C++ outside the usual Python settings, I'm not interested in dealing with Microsoft Store app issues.

It would easily possible to convert this app to the Windows App SDK (which is mostly just renaming a few namespaces in the code) which would allow it to run from an unpackaged exe, however the last time I have tried it, it still seemed to not up to par in functionality with the UWP stack.

OK I'll look into this.

[axodox]

I see, you can just use the axodox-machinelearning library I have created in a non-Store app to experiment, it is available as a nuget package.

FYI resolving your corrupt build would only take a few min probably, porting the whole UI is probably 2-4h if you know what you are doing, but if not it will likely take much more.

[by321]

I did try full rebuild a few times, to no avail. But after a VS update, a reboot, one more full rebuild, it runs again. I have no idea what happened.

[by321]

Oh well, it's happening again. And while trying to figure it out, I encountered a new error:

DEP0700: Registration of the app failed. [0x80073CF6] An internal error occurred with error 0x80073D05. See http://go.microsoft.com/fwlink/?LinkId=235160 for help diagnosing app deployment issues.

That page tells you to use event viewer to get diagnostic information, and in the event viewer, the message texts refer you back to that page. At least they got the self-referential loop done right.

Now I see why Microsoft Store app is not more popular.

[axodox]

Usually, a clean rebuild does the trick, however I am not really experiencing such issue, in fact I think I had this only once with Unpaint during development, and I resolved in 1 minute.

This issue usually happens when switching either between debug / release, or between branches, or after installing VS updates, and not doing a clean build after, as VS fails detect some old object files and creates a corrupt build. I am not sure if it is connected to Store apps, it is more like a failed startup, and can happen with any MSVC project I think.

[axodox]

The problem with Store apps were, that in the Windows 8 era MS made it locked down, their UI framework did not fit desktop use, and many old Win32 APIs, most importantly anything UI related besides DirectX was not available. Some devs also not liked the tighter security. And Valve was afraid that Steam would be booted from Windows in the future, as Windows would become more like IOS and the Apple Store. Older Windows devs did not like to change any of their code so basically would not accept any change breaking old Win95 era systems.

However around 2-3 years after Windows 10's release the new APIs became pretty mature, removed a lot of cruft and simplified new developments, you could do anything what was needed from a normal app, and in a safe and secure way, with clean uninstalls not messing up the system. But like with video games released in a poor state, people made their judgements already.

Now there is also Windows App SDK, which is a mix of old and new, but in my opinion most of its features are only needed by legacy or special apps.

In any case I do target the Xbox - which cannot be done in any other way, and I do not have any problem with the restrictions. I am not saying MS tooling is perfect - it can be buggy mess sometimes, however as someone who had developed some widely used dev tools, I understand that it is just not simple to support so many use-cases and configurations.

IMHO most of the failure on MS side was: releasing the new dev framework too early, then restricting it too much, and the usual keep coming up with ever newer solutions - instead of fleshing out ideas completely - which are then also very similar to the last one, but adding some new headaches.