The company I work for creates Point Of Sale (POS) software using Software As A Service (SAAS), so we host our clients' databases.  We do not force all of our clients to be on the same version of our software; i.e. some clients are on version 3, others v4, others v5, etc.  As you would expect, the database schema for each of these versions is different, so each of these clients also use a different version of our client-side app.

We are looking at making a Metro app that acts as a light-weight POS app that clients can use to sell their products.  The problem is, we will require having multiple versions of our Metro app in production; the version of the app that the client uses must correspond to their database version.  I know that we can't do this from the Windows Store and would need to sideload our apps.

We have come up with a strategy for deploying multiple versions of our metro app, but I wanted to check with the experts (you) to see if what we want to accomplish is technically possible. Here is what we are thinking:

We would sideload an Updater App to the client's tablet.  The purpose of this app would be to check what version of the POS App is installed on the Windows tablet, and check which version of the POS App the client should have.  If the correct version is already installed, it would simply launch the POS App.  If the correct version is not installed, it would download the proper .appx file from our servers and side-load it onto the device (of course the client device would need to have a sideloading product key), and then launch it.  The other (ideal) option of course is to just have one metro app that checks and auto-updates itself.  The concept behind this seems pretty straightforward, but is this something that is technically supported by metro apps?

I was hoping to be able to run PowerShell code from my Metro app to use cmdlets like Add-AppxPackage, but it looks like this is not possible.  So is what we want to do possible?

If the above is possible to do, another lesser concern is, is it possible to "hide" our POS App so that our clients cannot launch it directly?  We want them to always have to go through the Updater App to ensure they always have the proper version of the POS app installed, and have the Updater App launch the POS App.

Any suggestions, ideas, or comments are appreciated.  T

Just an update on things I've tried in my prototype metro app.  It looks like it's not possible to run PowerShell in metro apps; it doesn't support me referencing the System.Management.Automation assembly in my Windows 8.1 metro app, and doesn't include System.Diagnostics.Process for me to spin up a new process to run the PowerShell.exe.  Is PowerShell.exe even installed on Surface RT devices?  So I'm not sure how I would have the Updater app install/update the POS app.  If we did combine the Updater app and POS app into one single app, is it possible to have the app check for and download it's update from our servers, and then update itself?  Basically we would really like our app to auto-update itself, rather than our clients having to manually download and sideload the app on all of their devices every time there is an update, which is typically every 1 - 4 weeks.

If the above is not possible, do I have any other options?  The only other thing I can think of would be to make our Updater app a Desktop app; that way I could use PowerShell to install/update the POS metro app, but I believe that Surface RT devices don't support desktop apps (is that correct?), so it would drastically increase the price point for our clients, as they would have to buy Surface Pros instead of Surface RTs.

I find it hard to believe that our company is the first to try and do something of this nature, so there must be some solution out there. Any suggestions would be greatly appreciated. T

Hi,

I think we can't write script into Metro app.

However, during the deployment sequence, we can first write a script to get appx version and compare, then decide which task should be run.

 http://blogs.technet.com/b/heyscriptingguy/archive/2013/07/26/use-powershell-to-inventory-modern-apps-in-windows-8.as

SurfaceRT can't run Desktop apps, because Desktop apps are for Win32, and SurfaceRT is ARM.

Sideloading might not be a workable solution either, since to sideload, the Windows device needs to be provisioned with a sideloading product key, which are only sold in blocks of 100  via Volume Licensing (and are something like $30 each, so $3000).

Sideloading, as you've identified, has a few challenges around the "updating" cycle, it basically requires a re-install (of the newer version). You also need to address the signing and root certificate matter, (you need a certificate chain deployed).

I wonder if Intune might be a possibility?

Are you sure the WindowsStore can't work for you? What if you published "POSapp2013" (version3) and also "POSapp2014" (version4) etc ?

Thanks for the reply Kate.  This is basically what I was thinking in my second post above, where I mentioned we could make our Updater app a regular desktop app (or a PowerShell script).  I just wasn't sure if this is a possibility for Surface RT devices; I'm not sure if they support desktop apps or powershell scripts.

Hi Don, thanks for the reply.  The sideloading license keys are not a problem, but I'm not certain if the certificate chain would be or not.

Intune looks neat, but this is something that we would like to avoid.  We don't want our enterprise clients (or smaller clients) to have to manage updating the app on all of their tablet devices every few weeks.  We would just like the app to detect, download, and install its own updates.  If we can use PowerShell scripts on SurfaceRT devices, then this would still be a possibility for us.  Do you know if Surface RT devices can run custom PowerShell scripts?

The last resort option would be, as you mentioned, to publish a separate app for each major version of our software to the Windows Store.  We are really hoping to avoid this though.  Once possible workaround might be to package all of the separate app versions into a single app, and then just run the appropriate code depending on which version that client has.  So in simpler terms, instead of having 3 separate apps, we would have one app with 3 separate classes, and would use the class that corresponds to the client's version.  I'm not sure if this violates any Windows Store policies or not though.  Is this option another valid possibility?  Thanks.

I've no hands-on experience with SurfaceRT, nor with developing apps (it's just that I can't abide an awkward silence, most times ;)

So I'm really not sure about PoSH on WoA (I suspect it's not possible, happy to be corrected).

The MSDN forums for modern apps would surely be more likely to get you some developers attention for your (most excellent) questions?

(my expertise is in the enterprise/corporate/internal IT segment, mainly around deployment engineering and support, so not really a great match for your topic. but we are soon to be challenged with deploying and maintaining modern apps, and all the BYOD/CYOD use-cases are rapidly multiplying for us...)

Thanks for the reply again Don.  My colleague has a Surface RT and confirmed that he can access PowerShell on it, so I think rather than making an "Updater app" as a desktop app (not supported on Surface RT devices) or a metro app (not possible to install/update other apps or itself because it is sandboxed), we could use a PowerShell script as our Updater app and have that launch the metro app.

We are also considering another option of essentially packaging multiple versions of our app into a single Windows Store app, and then just determining at run-time which code to write. This option wouldn't be as flexible as having an Updater PowerShell script, but is very attractive as it would (hopefully) still allow us to use the Windows Store rather than having to sideload our app on all of the devices. If you are interested, you can read more about this idea on the dedicated thread I created for it.

Just an update on this. It looks like creating our Updater as a PowerShell script is not an option either, as PowerShell runs in Constrained Language Mode on Windows RT, which does not have access to any libraries that can be used to download files from the internet (e.g. System.Web.Client).  So while we could use PowerShell to install/sideload our app, we can't use it to download the appropriate version to install from the web, so this is no longer an option for us either :(  It looks like our only viable option is to manipulate our app to work with the Windows Store's criteria.  Thanks for the responses though