Building a library used in packaged and unpackaged apps

[mlynch]

I have a library that depends on the Windows App SDK (1.0), and users might target both packaged and unpackaged apps with it. There are many APIs that seem to require package identity and, thus, don't work in unpackaged apps.

How can I, as a library author, defensively program around this? Is there a way to detect whether the app is packaged or unpackaged at runtime? What about replacements for some of these APIs like FileIO that are very useful? Any help for managing these types of unknowns at runtime would be very helpful.

[mveril]

Hello
This documentation page could be useful for your
Detect package identity and runtime context

[mlynch]

Okay thanks that makes a lot of sense. Basically the managed Storage utilities are just doing a lot of that stuff for you in the context of this package system. So, outside of that, I need to emulate it. Shouldn't be too difficult then. Thanks!

[ptorr-msft]

A lot of the answer depends on the type of packaged app, and the locations of the files you're expecting to operate on. If all the files are part of the app (either in the app's package, or in the app's "private storage") then you can use any API you want. If the files are found in other places (photo library, documents folder, random user-provided filenames, etc.) then your options are little different for AppContainer apps (note that there's no concern for just general packaged apps).

If possible, for a library that might be used in AppContainer apps and might have to deal with arbitrary file locations, my recommendation would be to avoid filenames altogether and simply accept streams / strings / byte buffers (with encoding, if appropriate) instead. That can negatively affect the usability of your API, and you might have requirements to really have the filename for other reasons, but using streams or buffers as your currency avoids the permissions problems.

[DrusTheAxe]

Is there a way to detect whether the app is packaged or unpackaged at runtime?
...
This documentation page could be useful for your Detect package identity and runtime context

You may find AppModel::Identity::IsPackagedProcess() a better reference model¹ for how to detect if you're running in a packaged or unpackaged process (i.e. has/lacks package identity).

¹ I'm fairly confident making this statement as I wrote both those functions, plus the underlying API they use :-)

[andrewleader]

That AppModel API isn't public? Or it's not projected to C#? Or not part of 1.0? I'd love it if we had a simple API for this but I'm not seeing it in my C# app.

[DrusTheAxe]

That's not an API per se, just some code in the project using the recipe (but as noted, done well 🙂).

GetCurrentPackageFullName is a public Windows exported Flat-C API. There's no C# equivalent or projection, but a simple P/Invoke would do it.

It never crossed anyone's mind to make it an API given it's such a simple thing but now that you mention it, yes that would make sense as an API. Please create a new Issue requesting that functionality and we can follow up through that

Thanks for the ask/suggestion!