And the queue still doesn't show all items I added there. I have about 84 items in my queue, and the app shows me only about 53. That's better than the web site (which shows only 25), but still doesn't work as it should. Funny, I reported this problem a couple of times (for the web site), but looks like nobody cares...
It would be nice to also clarify how Linux programs/packages installation fits into windows ecosystem. Where do they go, are they observable only to the Linux subsystem, and what happens with them once I uninstall this subsystem?
Having you guys said the API allows to discover and communicated with devices of particular user with MS account, how are you going to join Android and iOS devices to this ecosystem without OSes support for that and without MS account on these devices?
I have a question regarding migrations. In this demo you had all the staff in single project, so when you were generating migrations, the code was added to this project. But what happens if I implement my persistence layer in a separate assembly and want everything related to data access to stay in this assembly (including migrations)? In other words, how do I generate migrations in a project different to Web App project?
In continuation to my previous post: I'm wondering, is it possible to call a Main method from a .Net Core application (like ASP.NET Core web app) from a UWP app? For example, I would like to start Microsoft.AspNet.Server.WebListener server from a UWP Background task which is generated by the IoT template in VS. My understanding is that CLI (former DNX) supplies the runtime, and all the rest is done by managed code (with possible interops) which is runtime-agnostic. So what prevents me from starting a CoreClr application from different runtime?
I guess at this session you talked about starting an ASP.NET Core web app on a Raspberry as a regular server, probably via remote powershell session. But since an IoT device won't ever be used as a real web server, such approach seems impractical. You don't get automatic updates through the store, crash monitoring, and all what you get when you install your code as a UWP app. And, what's more important, you can't make such a server a Web UI for you app naturally (like reading sensors and displaying their data on a page). So starting a web server from a UWP app looks very reasonable to me.
Another big problem with UWP Map control is very limited flexibility of custom tile sources. In particular, there is no way to force tiles refresh, which makes many dynamic scenarios like traffic information practically impossible. There are workarounds for this like reattaching the tile source every time you need to update the tiles, but this is very performance inefficient and visually flickering. Again, this was posted in several places including insider feedback in early windows 10 version, but after about a year MS didn't bothered to make this scenario possible.
The UWP Map control is practically unusable on Windows IoT Core on Raspberry Pi 2, because nobody bothered to implement a graphics driver with hardware acceleration. Instead, it provides Microsoft Basic Render Driver, which is quite slow in displaying maps. I wrote about this in many places, but didn't get any reaction from Microsoft.
@simpleatsh, I have the same concern, Windows IoT Core uses software driver (Microsoft Basic Render Driver) for graphics rendering. I think is shame to not utilize graphics hardware we pay for! Its enough to display the Map control to see how poor performance is.
Asp.net on Raspberry! This what I've been wanting to see for long time! I'm serious, you should consider official support for ARM platforms, since IoT devices very often provide web server for administration and configuring an app running headless (not to be confused with the OS's web administration page). I also can imagine a setup where a Raspberry device runs a headless app in some place, and other devices (IoT or full-fledged) display web-based UI with some dynamic data in different places on their own displays, meaning true concurrent servicing requests.
How come my system still consumes almost 14 gigs of page file memory with almost no apps running?? And almost 8 Gigs of physical memory is in use not including caching! What for??
The System process, which is where this memory compression consumption is displayed in TM, consumes not that much, as you can see. And I don't observe this cache-like behavior you describe for low-memory conditions, when compressed pages are written to page file, freeing the physical memory.
To be clear: I would have bothered with these numbers (assuming this all is due to memory compression or whatever), BUT I do observe system slowdown, low memory warnings and apps crashes while there is no obvious reason to observe this, since my apps don't consume so much, and I have lots of physical memory installed.