In our case we're not at all interested in publishing anything in the Store or for any other platform. The application will always remain a Windows desktop app. So, the first step (containerization) will suffice and the second step (re-package) is not relevant.
Howeverr, for other parties it may be relevant, so your info is relevant too.

Regards, Peter

>There was also a presentation at this year's BUILD with more current information: https://channel9.msdn.com/events/Build/2016/B829
>
>To clarify a few things... this is more of a re-packager than a converter. It packages your app as an AppX that can be put up on the Windows Store or side-loaded. (By the way, it looks like side-loading is enabled by default in Windows 10 Pro.) The app runs inside of a sandbox/container that essentially gives the app it's own copy of the registry and Users/AppData folder. This is supposed to make the app more secure, so users feel safe about what they install. However, it runs as "full trust" (for the current user, not as an admin). This is not as locked down or secure as a true UWP app, but it must be required for most Win32 apps to function. There are a few additional limitations: you're app can't run as admin, and you may not be able to install certain system-wide components, like the .NET Framework. Other than that, there isn't much of a difference between running your app as a Centennial app vs running it traditionally on the desktop. VFP apps ought to run fine, but they will only run on x86 devices that include the Win32 desktop, not ARM phones. In other words, only on devices where your app could already run.
>
>Another thing this enables is communication between the UWP and Win32 platforms, something that MS strictly prohibited when Windows 8 came out. If you want to add new Windows 10 features to your VFP app (touch interface, inking, Cortana, etc.), it is technically now possible. The app runs in two processes. The UWP portion runs in the standard WinRT AppX container, and the Win32 portion runs in the new full trust Centennial container. The two processes communicate via the AppService API. It's important to note that this is a WinRT API, and COM platforms like VFP don't have direct access to it. You could probably build a wrapper in C# or C++ to expose the AppService API to COM/VFP. wwDotNetBridge may be helpful in this area. The two processes can send messages back and forth, but I wouldn't expect anything as sophisticated as COM.
>
>At the end of the day, reasons you might want to use this include:
>- You want to add new Windows 10 features to your app
>- You want to sell your app in the Windows Store
>- You want to run your app inside the Centennial sandbox/container for improved security
>- As a migration strategy, while you rewrite your app for UWP
>
>Microsoft hopes developers will do the latter and rewrite their desktop apps for UWP. I wouldn't hold my breath.
>
>>You're right. That's why MS labeled it DESKTOP App Converter. In our case this is fine. The app will never be for mobile devices or for the internet.
>>
>>>Hmm. Sounds as if, in theory, you're right. Would be interesting to see the results. Of course a VFP app (or, for that matter, any desktop exe) is not, unless it is trivial, going to run well on anything other than a desktop/laptop device without re-writing the UI with XAML.
>>>
>>>Watching this : https://channel9.msdn.com/Events/Build/2015/2-617 I was struck by how closely it follows the Android/IPhone models. Although perhaps not surprising since it has to cope with the same limitations....
>>>
>>>>The containerization technology is Microsoft's way to go to ensure that all the legacy application will still work in the future. It enables Microsoft to further develop Windows without having to bother too much about backward compatibility. It will also support VFP, as to my understanding. See also: http://fox.wikis.com/wc.dll?Wiki~Windows10ProjectCentennial
>>>>
>>>>Win32 merely refers to the 32 bit Windows versions. (The containerization technology will also support 16 bit.) There's no requirement that apps use the standard featues of those Windows versions for creating windows and input controls. By the way, as I understand it, the vfp-windows are formally Windows windows. It are only the controls within those windows that are vfp native.
>>>>
>>>>
>>>>>Don't think so - VFP is not a 'Windows App' in that sense (e.g. does not use standard Windows input controls etc.)
>>>>>
>>>>>>VFP app modules, probably not suitable, but a VFP Win32 exe might be (?).
>>>>>>https://msdn.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-root
>>>>>>
>>>>>>
>>>>>>>Isn't that all about converting Windows applications to UWP ?
>>>>>>>Since FoxPro is NOT a windows application I don't think it's relevant......
>>>>>>>
>>>>>>>>Hi All,
>>>>>>>>
>>>>>>>>In 2015 Microsoft introduced the phrase 'Windows Desktop Apps' for PC-applications. This month they demonstrated the preview of the ‘Desktop App Converter’. The claim is that legacy apps can run without much adaptations inside a 'container'. Moreover, extensions can be built with the legacy platform, but also with newer platforms.
>>>>>>>>
>>>>>>>>I interpret this as the claim that, in time and gradually, we can build new modules and/or replace existing modules with another tool/language. Eventually the application might be totally VFP-free. However, esp. one question pops up:
>>>>>>>>
>>>>>>>>Modules (.app) in VFP are aware of the open tables/cursors, the public/private variables and the various SETtings. Will we be able to build a module with such a new tool/language that is also aware of open tables/cursors and variables??