This blog has been ported to Azure! For all previous post, and all future posts, please visit dvlup.com
Your one-stop shop for Microsoft Build 2018 sessions, slide decks, post links, keynotes and much more.
- AI, Windows ML and Cognitive Services
- Desktop – Windows Store (UWP, Win32 and IoT)
- ASP.NET, PWA and Web
- Azure and Cloud Services
- Hololens and Mixed Reality
- Microsoft Graph and Microsoft 365
- Keynotes and other key presentations
- Windows Features
Living Document Note:
These Playlists will continue to be reordered and updated in real time as new content becomes available. However, the links will always remain the same and you can refresh the playlist page to get any updated ordering/content.
If you’re a Xamarin Forms developer, you’ve likely used PCLStorage (or other Dependency Service) to interact with the target platform’s file system in the portable class library’s code. However, since November 2017, Xamarin.Forms now uses a .NET Standard 2.0 class library and PCLStorage is no longer supported.
This isn’t a problem because in .NET Core 2.0 you now have access to System.IO.File’s GetFolderPath and SpecialFolder methods (see System.IO.File in .NET Core 2.0 docs).
Thus, you can get a path to the app’s local folder (the one that the app can save to) without having to write a Dependency Service (which is what PCLStorage does) by using:
var localFolder = Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData);
With a reference to the localFolder path, you can Combine it with the file name:
var notes = File.ReadAllText(Path.Combine(LocalFolder, "notes.txt"));
As a very simple example, I created a couple extension methods for Stream and Byte in the below FileExtensions class.
To test it, I created a ContentPage that downloads an image, saves it using the extension method and set a FileImageSource to confirm that it’s a file (instead of just using a StreamImageSource).
Note that the extension methods are very basic and shouldn’t be used in production as-is (i.e. no defensive programming code).
Here is the result at runtime on UWP:
I was given the honor of having early access to Windows 10 on ARM (WoA) so that I could chronicle the experience and provide you with tips to ensure that your development experience is smooth. I’ll go through a list of potential issues you might encounter, along my fix for each.
What this post is:
This article is intended to be a quick guide on how to set up the device so that you can deploy and debug your apps. I will be writing this from a UWP developer’s perspective, sharing the experience of deploying and debugging this real time video effects test app.
Several of my fellow MVPs also got a device and will be writing posts about their experiences as well. Some articles will be UWP specific and others win32 specific, see the Additional Resources section at the bottom of this post.
What this post is not:
This will not be a “product review” style post about the device or the OS itself. I will say this: I am very impressed, it’s just Windows 10 and I really wouldn’t be able to tell it was on ARM until I realized that it’s been 2 weeks since I last charged it 🙂
Okay, enough intro talk, let’s get our hands dirty. First, a little primer on x86 emulation, an explanation of how Microsoft was able to get Windows on ARM and how your app will work.
How Windows on ARM works
Chances are you’re using a 32 bit application right now, but your PC is running a 64 bit version of Windows running on an x64 CPU. How does an application with 32 bit instructions work on a CPU that expects 64 bit instructions? This is accomplished using x86 emulation, provided by the WOW64 layer in Windows (WOW64 stands for Windows 32bit on Windows 64bit).
To create Windows on ARM, Microsoft ported Windows 10 to ARM64! The kernel, shell, in-box drivers and in-box apps all run native on ARM. What about your apps? Windows on ARM has x86 Win32 emulation!
The WOW abstraction layer, in concert with a custom x86-to-ARM emulator and CHPE dlls (x86 assemblies with ARM64 code in them, pronounced “chip-ee”), your x86 application can run in an emulated process on an ARM CPU.
Here’s a diagram to better explain it
Some key features
- The x86 app win32 app runs unmodified
- The app will installs and run like it does any other PC
- The x86 instructions are translated to ARM64 at runtime and they get cached so that future app runs are faster!
Windows on ARM supports ARM32 and x86 applications
- Store apps (ARM32 preferred, x86 supported)
- Win 32 apps (x86 supported, x64 not supported).
Tip: If your Store application has an ARM32 package available, it will be installed and will run natively as this provides the best user experience. Where possible, make sure all of your Store apps also have an ARM32 package.
If you’re not sure how to do this, when you go to package your app, you’ll see three checkboxes, make sure ARM is selected:
For win32 apps, you can use NGEN (see #2 under the General Tips section below).
There are some limitations at this time
- No x64 emulation support
- No kernel mode support
- Apps that rely on drivers may not work (the driver developers should start updating their drivers for ARM support)
- Apps that inject code into Windows processes won’t work
Okay, now with a high level look at how WoA works, let’s dig into my experience and how I hope it helps you
Familiar Ground – Remote Debugging
If you’ve used Visual Studio’s remote debugging tools before, for example with Hololens or Windows IoT, then you’ll feel right at home. The process is essentially the same, but with a couple things to keep an eye out for when you’re first getting started.
The first thing you need to do is enable Developer Mode in the device’s PC Settings > Updates and Security > For Developers page. Not only so that you can deploy apps to the device, but also to enable the Remote Debugging tools.
Here’s a screenshot of the PC Settings page:
However, you may not see this option, which brings me to my first point.
Potential Issue #1
My device came with Windows 10 S out of the box, this means that I will not see a “For Developers” item on the Settings > Update and Security page (screenshot above).
Upgrade the OS. I used a product key for Windows 10 Pro in the Settings > System > About page, but you can use whichever option is available to you.
After updating you’ll now see the Developer Mode option on the For Developers page, toggle that to move forward. Enabling this will trigger a download an installation of a Developer Mode package that contains the Remote Debugging Tools.
Potential Issue #2
You may experience an issue where the developer mode package didn’t install correctly, you should see a “Remote Debugging Tools Installed” success message. If you didn’t or see an error message, this means that you will not have the tools on that machine and you’ll get frustrated when trying to deploy from Visual Studio.
Download and install the tools manually, you can find the download here. Alternatively, you can copy over the tools from your dev machine if you’re familiar with the steps, but installing the tools is the most straightforward option: run and done.
Targeting the Remote Device
If you’re not familiar with using the Remote Debugger, I strongly urge you to read this Microsoft documentation article, but let’s go through the main steps.
Changing Target Device to Remote Machine
If you open your application’s Properties page in Visual Studio, and switch to the Debugging tab, you’ll see that you have a Target Device drop down.
Switch that to Remote Device, then the “Find…” button on the right will become enabled. After clicking the Find… button, you’ll be presented with the following UI:
Now you have an opportunity to select a remote device, but you will most likely see that the ARM PC isn’t showing as an available device to target.
There are two ways to solve this, use the device’s IP address or let “Auto Detected” find it for you. In both cases, the device needs to be visible on the network, but Auto Detected is far better because it helps with setting Authentication Mode.
Potential Issue #3
No devices are in the Auto Detected list or you can’t connect using IP address.
You need to make sure that the both the development PC and the ARM PC need to be on the same network and that Network Discovery is enabled.
The quickest way that I like to do this (there are other ways), is just to use File Explorer and selecting “Network” in the pane and follow the prompts.. Easy Button style. Here are some screenshots to guide you:
Once you click the OK button, File Explorer will show a yellow bar at the top:
Click that bar and follow the prompts, it will ask you to make the network you’re on a Private Network (that’s my preferred option as it’s the safest). You’ll now see that the PC will scan the network, finding other devices and listing them in File Explorer. Go ahead and close File Explorer now that it has done its job.
NOTE: If you need to, repeat this process for your development PC.
With both PCs visible on the Network, reopen the Remote Connections dialog window again (using the “Find…” button) and check the Auto-Detected list for the ARM PC. Select it, then follow the steps to connect and pair it.
Potential Issue #4
You’re not able to see the device in the Auto-Detected list, and you’ve hit Refresh button to scan again.
You can instead use the ARM device’s IP address and select “NONE” for the authentication option. When selecting this route, you’ll be shown a PIN number to pair to Visual Studio.
I haven’t been able to get Universal Authentication to work with manual IP address connection yet, but my follow MVP testers have and their blogs posts may touch on this further.
Congrats, now you’re ready to deploy!
Debugging & Deploying
Before you click F5 (or that shiny green start debugging button) for the first time, let’s review another issue you will encounter that might you might miss. I didn’t see it the first time because I was looking at Visual Studio instead of the device.
Potential Issue #5
When debugging, you do not see any runtime analytics / debugger metrics in Visual Studio Diagnostic Tools window (usually at the top right):
Keep an eye on the ARM device for an elevated permissions UAP prompt the first time you deploy. You may only see a TaskBar yellow-flashing icon and not a full screen prompt, click the icon to see the prompt and allow it.
You’re going to be quite surprised at how well everything just works, In several cases, I found my apps worked faster on the ARM device than my dev PC!
Tip 1 – Failure to launch
When remote deploy does’t work, look at the Visual Studio build output window. Close to the end of the build output, you’ll probably see a reason why the deploy failed.
You’ll most likely see one of these errors (click the link to view the respective troubleshooting article):
- Error: Unable to Automatically Step Into the Server
- Error: The Microsoft Visual Studio Remote Debugging Monitor (MSVSMON.EXE) does not appear to be running on the remote computer.
- Unable to Connect to the Microsoft Visual Studio Remote Debugging Monitor
Issue 2 – Slow first launch
When using an x86 application on Windows 10 on ARM, the first time an app launches it will be a little slower. This is because the x86 to ARM translation will occur the first time, but the result is cached on disk so the future launches are significantly faster.
Also, while waiting for that first launch, don’t try to relaunch it again. Otherwise, you’ll end up opening multiple instances of the app that will further slow things down (it can take 5-30 seconds depending on how much translation needs to be done). I’ve communicated my feedback to Microsoft that there should be some sort of indication that the app is starting up (e.g. a flashing taskbar icon).
- If the app is a Store app, provide an ARM package so that it runs natively and doesn’t need emulation.
- If the app is a win32 app, try using NGEN.
This post will be a living document for a little while, I’ll come back and update the post with anything new I find, and continue to share my tips with you. I’ll be sharing my fellow MVP’s posts as they become, see them under the Additional Resources paragraph below.
I hope you enjoy running your x86 apps on an ARM device as much as I have, it’s a wonderful future for mobility and battery life where you don’t have to sacrifice your library of applications because of a CPU’s architecture.
- Anything I can help with?
- Are you stuck trying to deploy your app?
Leave a comment below or reach out to me on Twitter here (please remember that I can only answer development-specific questions).
I will update this list as more posts from my fellow MVPs, and Microsoft documentation, becomes available.
- Daren May – Remote Debugging UWP Apps on Windows 10 on ARM
- Morten Nielsen: Building an ARM64 Windows Universal App
- Windows 10 on ARM documentation
- Remote Debugging documentation
- Device Portal documentation (for desktop)
Telerik UI for Xamarin comes with two themes out of the box, Default and Blue. You can easily style individual items, but you can also define an entire theme at once in a separate ResourceDictionary.
With this approach you can swap out ResourceDictionaries at runtime for a nice user-selected theme feature in your app’s settings. Let me walk you through a very simple demo to illustrate the approach.
Step 1. Create your custom theme’s ResourceDictionary
Xamarin.Forms doesn’t have a good ResourceDictionary template, so start with a Content Page (XAML) template and then change the ContentPage type to “ResourceDictionary” in both the XAML and code-behind.
Now, you can add in all the styles and colors you want in that one dictionary. You can find the Color names we use for your controls in the Themes Overview documentation.
In the custom dark theme example below, the Color resource key values are pretty clear as to what they do.
Step 2. ThemeHelper Class
I usually like to create a static class like this so that I can change the theme from anywhere in the app, but isn’t necessary. You can put this logic entirely in your settings page if you’d prefer.
You may have noticed that I’m using a RadResourceDictionary. We created this when Xamarin.Forms didn’t have MergeWith support. You can use a Xamarin.Forms ResourceDictionary type if you’re using a newer version that supports it.
Step 3. Runtime
I’m using a RadSegmentedControl to change the theme, and a RadListView to easily see the difference between themes. You can of course use whatever UI control you’d like to change themes, for example a Picker.
The important thing is that you call the helper class’s ChangeTheme method and pass the theme name that you need to change to:
When selecting one of the options, you’ll get one of the three results you see in this article’s header image.
If you have any questions feel free to reach out to me on Twitter at @lancewmccarthy.
Microsoft has opened up the ability to have a 3D app launcher to all developers in the Fall Creator’s Update. In this blog post, I’m going to show you how to build your own 3D app launcher from scratch (accompanying YouTube tutorial video embedded below).
What is a 3D app launcher?
Up until now, you’ve only been able to have a regular 2D tile in the Start menu and the user could place a 2D frame of your app on a surface in the Cliff House (the Mixed Reality home) or on a surface in your HoloLens mapped area. Clicking the app frame would launch the app in the same frame.
If your app was a 3D app, then it would launch the immersive experience, but the launcher was just a 2D . The user wouldn’t be able to intuitively know that the application is an immersive app. There are some apps that have 3D launchers, for example the HoloTour app that you see in this article’s featured headline image.
Wouldn’t it be nice if your immersive application had a 3D launcher, too? By the end of this blog post, you’ll be able to! To get started, let’s take a look at the model and how to build one yourself.
First thing you’ll need to understand is that Microsoft requires your model to use gITF 2.0 specification and more specifically, the binary format (.glb). To accomplish this, we are going to use Blender.
Blender is a modeling and animation application that is open source and free. You can choose to build your model directly in Blender if you’re familiar with it. Alternatively, build the model in another application but use the Blender gITF Exporter add-on, which is what I’ll show you today.
Building The Model From Scratch
To keep this tutorial simple, I’ll create a simple UVSphere in Blender and use a solid color texture. Creating complex models in Blender is a bit out of the scope of this post, however I cover doing it from scratch in this video (if the video doesn’t load, here’s the direct link).
Just be sure to read the next section, even if you followed the video, so that you’re familiar with the restrictions you’ll inevitability encounter while trying to use different models.
Importing a Model
Alternatively, you can import other model types, like FBX, into Blender. This is easy, as FBX importing is available out-of-the-box .Take following steps once you’ve opened Blender
- Select File
- Expand Import
- Select FBX
- Locate and load the file
One thing you’re going to notice is that model may not be visible in your area, it’s far too large and off center. To get it in your view, you can use the “View All” shortcut (Home key) or drill into the menu “View > View All” (this menu is underneath the 3D view area). Here’s a screenshot:
Now, look in the Outliner panel (located at the top right of Blender) and find the object named “root” this is the imported model. Then, to get the right editing options, select the Object properties button (see the red arrow in this screenshot).
Take note of the highlighted Transform properties, we’ll change those next. However, before we do, let’s review some of the guidelines Microsoft has set for 3D app launchers:
- The Up axis should be set to “Y”.
- The asset should face “forward” towards the positive Z axis.
- All assets should be built on the ground plane at the scene origin (0,0,0)
- Working Units should be set to meters and assets so that assets can be authored at world scale
- All meshes do not need to be combined but it is recommended if you are targeting resource constrained devices
- All meshes should share 1 material, with only 1 texture sheet being used for the whole asset
- UVs must be laid out in a square arrangement in the 0-1 space. Avoid tiling textures although they are permitted.
- Multi-UVs are not supported
- Double sided materials are not supported
With these in mind, let’s start editing our mesh, under the Transform section, take the following actions:
- Set Location to 0,0,0
- Set Scale to 1,1,1
- Now, lets re-frame the 3D view so we can see the model by using the “View All” shortcut again.
You should see that your model is now at the right place and close to the right scale. Now that you can see what you’re doing, make any additional tweaks so that your model meets #1 and #2 of the Microsoft guidelines.
Lastly, we need to check the model’s triangle count, there is a limit of 10,000 triangles for a 3D app launcher (you can see the triangle count in the top toolbar when the model is selected). Here’s what it looks like:
If you need to reduce your triangle count, you can use the Decimate Modifier on your model. Go here to learn more on how to use Decimate (I also recommend checking out a couple YouTube videos on the topic, Blender is complex app).
I strongly urge you to go to this documentation and read all the model restrictions and recommendation, such as texture resolutions and workflow. If you use a model that doesn’t meet the guidelines, you’ll see a big red X like this:
Now that your model is done, it’s time to export it as a gITF binary file.
By default, Blender doesn’t have a gITF export option, so you’ll want to use the KhronosGroup glTF-Blender-Exporter. Installation of the add-on is pretty straight forward, go here to read the instructions.
You get to choose between two options to add it:
- Option 1: Set Blender to use repo’s scripts folder (to stay in sync with the exporter’s development)
- Option 2: Copying a folder into Blender’s folders (I chose this option, scroll down to where the author starts a sentence with “Otherwise”)
Finally, enable the add-on in Blender (last step in the instructions). Once the add-on is enabled, go ahead and export your model! You’ll see a glb option in the File > Export list.
Here’s a screenshot:
UPDATE Jan 2018
You can now pack your more complex textures using a new tool released by Microsoft a few weeks ago! It takes away the requirement to be a shader ninja by importing your existing glb, packing the textures properly and exports an updated glb that will work in the Mixed Reality home.
Go here to get the converter and read how to use it https://github.com/Microsoft/glTF-Toolkit
Setting the 3D Launcher
Now that you have a glb file, it’s time to open your Mixed Reality UWP app in Visual Studio. Once it’s loaded, we need to add the glb file to your app’s Assets folder (right click on the folder and select “Add > Existing Item”). Once it’s been pulled in make sure you set the Build Action to Content (right click on the file, select Properties and change Build Action to content).
Lastly, we need to edit the app’s Package.appxmanifest file XML manually, to do this, right click on the file and select “View Code”. At the top of the file, add a new xmlns and also put it in the IgnorableNamespaces list
xmlns:uap5="http://schemas.microsoft.com/appx/manifest/uap/windows10/5" IgnorableNamespaces="uap uap2 uap5 mp"
Next, locate the DefaultTile tag (under Application > VisualElements), expand it and add the MixedRealityModel option with your
<uap:DefaultTile ShortName="Channel9 Space Station" Wide310x150Logo="Assets\Wide310x150Logo.png" > <uap5:MixedRealityModel Path="Assets\Dog.glb" /> </uap:DefaultTile>
Here’s a screenshot, with the additions highlighted:
You can see the final result at the end of the video above. Keep in mind that I keep the triangle count down for this, but next time I’ll likely increase it to 64 segments and 32 rings. Additionally, I’ll use a texture that can be mapped around a sphere (the Earth for example).
If you’re having trouble with your model and want to check your app settings with a known working mode, download the glb I created for here. I hope this tutorial was helpful, enjoy!
Did you just get a new Mixed Reality headset? Were you so excited that you ripped open the box and plugged it in only to to find that after setting up your floor and boundaries that you got the following error:
Cannot download Windows Mixed Reality software
I spent a lot of time digging around the Hololens forums and long conversations on the Holodevelopers Slack and it seemed there was a wide variety of reason for this. However, after looking at my Developer Mode settings page (in Windows Settings), there was an incomplete dev package installation.
At this point, I suspected I needed to “side load” these packages, bypassing the on-demand download over network. I just didn’t know where to find it until… my hero, and holographic Jedi, Joost van Schaik (@localjoost) had the same problem and found a fix for his. Joost followed a suggestion from Matteo Pagani (@qmatteoq) to use dism to install the packages manually.
I tweaked his solution (basically just found different packages) so that that it worked for a non-Insider Preview build and it worked!
It turns out that you can get the ISO file for the On-Demand-Features for your version of Windows 10 and install the packages manually.
Here are the steps:
1 – Go to the appropriate downloads page for your version of Windows 10 (these links use my.visualstudio.com, you may need to use whatever download
- Go here if you’re running 1703 (Creator’s Update)
- Go here if you’re running 1709 (Fall Creator’s Update)
- Go here if you’re running 1803
2 – Download the Windows 10 Features on Demand file (ISO file) listed there. Note: There may be two ISOs offered for download, I found the cabs I needed in the 1st ISO.
2 – Mount the ISO file and make sure you see the following files (if you don’t, you got the wrong ISO):
3 – Open an elevated Command Prompt and run the following commands (replace “E:” with your mounted ISO’s drive letter)
— Install the holographic package (this is what the Mixed Reality Portal app is failing to download)
dism /online /add-package /packagepath:"[YOUR-DRIVE-LETTER]:\Microsoft-Windows-Holographic-Desktop-FOD-Package.cab"
— Then install the Developer Mode package
dism /online /add-package /packagepath:"[YOUR-DRIVE-LETTER]:\Microsoft-OneCore-DeveloperMode-Desktop-Package.cab"
Here’s a screenshot of the result
4 – Open the Mixed Reality Portal app again and bingo, success!!!
Underlying Cause of the Issue
After some discussion with the folks at Microsoft, it turns out that if your PC is using WSUS (Windows Update Service), which is normal for a domain-joined PC under a corporate domain policy, this can prevent the download of some components (like .NET 3.5, Developer Package and Holographic Package).
You can talk to your IT department and ask them to unblock the following KBs:
BIG THANKS to Joost and Matteo 🙂
[Updated to add Matteo, fix some grammar and add the info about the KBs]