@ GHI - Next time you talk to your friends at MS ask them how I’m supposed to create a beautiful extensible Raspi/Win10 IoT GUI if I can’t easily call other apps AND I can load in my own custom stuff via reflection.
Bah. Gimme something here guys. You want Pyxis 4 don’t ya? :wall:
Well, dynamic loading of downloaded content isn’t (or at least hasn’t been) part of the UWP/Store design. That’s part of the “App Store” model. I don’t love it either, but it’s part of the walled-garden store design. Anything that goes through the app store (and all UWP apps are designed using this same model) needs to go through the review process, and they can only enforce that if runtime extensions are not possible. I think you can do dynamic loads - just not of anything that wasn’t in your original signed package.
So for multiple configs : you need to either create multiple products or ship all options and load and enable them selectively.
And for extensibility : you need to create additional downloadable products and use contracts or URL binding to talk between the installed products.
The only ways around it that I have found is with LUA code (which will make your app non-compliant and get it ejected from the store when that gets noticed) and JavaScript/WebHost (rarely gives you the UI functionality or UX that you actually want).
Apple does the same thing with iOS and admittedly it sort of makes sense for enforcing content review on iOS and UWP App Store stuff, but it is a bit harder to swallow for IoT. So far, it looks like IoT apps won’t go through a store review process (that would be totally impractical), so (to me) it would make sense to add Assembly.Load(byte[]) to the IoT api profile.
Does this mean I can not deploy UWP apps to devices without the Store (or Visual Studio)?
This makes it completely unusable for my kind of industrial applications.
In some cases I need to make weekly or even daily updates, sometimes multiple small updates on one day.
Sometimes my customers them self needs to be able to create new versions with modified settings and deploy these to multiple devices.
If this is true for UPW apps, and UWP apps are the only way to deploy apps to W10 IoT, then I will never use it.
No, Pete and I had an internal discussion with the IoT folks about that. If I am interpreting the responses we got correctly, you are able to redistribute the binary images (sd card images) of the OS as you got them, plus your UWP app without additional contact with Microsoft.
However, adding anything else that modifies the core OS image (think of that as : anything that isn’t a UWP app) may require additional signing processes, but it sounds like none of that is quite worked out yet.
I also don’t know what the in-field update story is supposed to look like, but currently it does not involve the Microsoft Store. It’s pretty clear that even the IoT team is still working this stuff out internally. I believe the right things will happen - they just haven’t been worked out yet. It may be the case that the IFU story today involves swapping out an SD card, but that’s just for now and also because I don’t know of any other mechanism. Doesn’t mean there isn’t a better way - I just don’t know what it is.
This is not an official MS statement - this is my understanding of the situation from internal conversations and the answers are likely to evolve in the near term.
There you have the same problem - updating a UWP app, which is only possible via the side-loading deployment mechanism from a Windows machine.
It is possible to communicate between UWP apps - I just don’t know any way other than dev-mode deployment or SD images for sharing them, no matter whether there is one, two or many of them.
The problem is the install process - there’s no such thing as an xcopy install for UWP apps. Under windows 8, you could use a ‘developer license’ to do a side-load install via powershell. There’s some new process in Win10 that involves having the donor machine be in ‘development mode’.
If you right-click on a UWP app and select Store->Create Package and then answer ‘No’ when asked if you want to use the store, then you will get a warning that says you can only using the resulting package “on a computer that has a developer license installed or meets the requirements for sideloading Windows Store apps”. There are also two links on that page - one of which seems to be for Win8, and the other one requires a dev-mode donor machine running VS.
It’s not looking great for being able to do incremental field updates via UWP installs. I could be missing something, but that’s what I know now.
[edit : running a little powershell experiment - results shortly]
Ok - I did the following experiment:
Generated a package with rightclick->Store->Create Package (generate a non-store, ARM package image)
Using the UNC path of my RPi device, I opened an explorer window, created C:\Packages, and copied the ARM package there
Used enter-pssession to remote into the machine
cd c:\Packages
Set-ExecutionPolicy Bypass
.\Add-AppDevPackage.ps1
Result : The term ‘certutil.exe’ is not recognized as the name of a cmdlet, function, script file, or operable program.
…and I don’t have an ARM version of certutil.exe, so I’m kind of stuck there. Even if this worked, it relied on some stuff (remote PS sessions or starting a PS session from a UWP app) that I think are not possible or practical.
I get the UWP model and it makes sense in a lot of places. It doesn’t make sense on the RasPi to limit the developers so.
The RasPi is a powerful little machine that’s capable of a lot but with no way to update, call other programs or implement anything that might actually approach an operating system why would anyone bother with Win10 over Linux on the RasPi?
Sure there’s fun little one offs that you can run on it, but that’s a waste of the power of the board.
Even if I could just update my own app and launch other apps, I could probably work something decent out.
I don’t think this will be lost on the IoT devs in Microsoft - they will hear it from lots of places and I am sure it will get addressed. It’s just what we have today, which is still pretty early on for the IoT release.
Yup, I can deal with early. As long as I know it’s coming down the pipeline I can start as a single app that has everything and break it apart when options become available.
Hmmm… not sure how much that helps. Services could certainly download and dynamically load DLLs, and can host the CLR and allow them to do dynamic downloads, but I think Windows.Devices is designed to run in an appx sandbox, so what good does it do to gain service-level system access if you lose all the Windows Devices stuff.
Now, if I am wrong and you can get at the Windows.Devices support outside the appx sandbox, then all is well, but that remains to be seen.
I think there are still some tricky bits around cert management, but I am working through the problems now to see if I can build an IFU pipeline, just to prove to myself whether all the pieces are really there. User-installed system services do fill a gap - just not the only gap.
Ok - so I looked into this a bit more, and I want to reference the original question as to how you can load custom stuff via reflection. Here are the various use cases and some strategies:
Use case 1 : Loading dynamic UI modules (OP question):
You cannot create a single appx-based UI app that loads modules dynamically. The appx sandbox just plain won’t allow it. You need to update the whole appx image.
Mitigation 1 : You can install multiple appx apps and navigate between them with Launch and pass contextual information via launch-URL query strings or by consulting a state-management service that lives outside appx. But, you cannot install appx apps from within appx, so you need to create an an installation helper service that can use the Win32 apis to manage certificates and perform the elevated functions for installing an appx and manage the inventory of installed apps.
Mitigation 2 : Host the webview control like this guy did : https://www.youtube.com/watch?v=KFHIVQ-ohu0 and keep your UI on a server somewhere (not the best UI experience if you ask me, but it does work)
Mitigation 3 : If you really, really, really want dynamic UI functionality, and you don’t care that the hosted code isn’t .net, then create your own UI markup language and/or implement LUA scripting (or any other bytecode or text script language) in your appx code. Then you can download markup and script and execute it internally. The appx sandbox restricts loading .net code - but it cannot restrict loading of markup and script that doesn’t become part of the AppDomain.
Use case 2 : Loading dynamic code for non-UI functionality and/or in-field update support
This you can do from a standard Win32 service. You can use C/C++, or host the CLR. You might even be able to use the .Net windows-service template, but I haven’t tried that. You then have the ability to dynamically load modules, and you can access any WinRT winmd functionality that is marked with [DualApiPartition()] in the MSDN documentation. So you CAN do stuff like GPIO, I2C, etc from non-appx apps.
If you use a little imagination, you can see how you could combine both of the above to achieve dynamically-loadable UI, and in-field dynamic updates. Neither is simple to implement, and I don’t think either has been fully proven out (working on it) but it seems doable. I researched this all as part of Verdant because asset management, deployment services and config management are core to the value proposition and I really want coverage for Win10-iot.