Part 8: Understanding Compilation and Deployment
If you'll recall from the C# Fundamentals series, the C# compiler compiles the code in your project to create a .NET Assembly. The end result is usually (at least, in the case of simple Console applications) an executable file with the file extension ".exe". While we worked exclusively with the debug version of the app in Visual Studio, by changing the Solution Configuration to Release we could create a version of the application suitable for deployment on another user's computer ... as long as they had the same version of the .NET Framework Runtime installed on that computer.
In this lesson, I want to talk about deploying the app we build to a physical device running the Windows Phone 8 Operating System. Up until now, we've merely deployed to the Phone Emulator. The compilation and deployment step is automated for us, and we may not be aware of how the program is packaged and installed into the Emulator. Furthermore, we will want to understand the way in which the app is packaged because we'll want to undoubtedly deploy the app to a physical phone device for testing, and we'll want to package the app so that we can submit it to the Windows Store to be approved and included there for download or sale.
So our game plan in this lesson:
- I want us to see what happens when we compile our app ... what does Visual Studio create? Maybe we can learn a little about the deployment process as a result.
- I want to deploy to an actual physical phone device, just to see our PetSounds app running on a real phone
1. Discovering what happens during compilation and deployment
Each time we run the app by hitting F5 on our keyboard, or the Run button on the toolbar, Visual Studio is creating a Debug version of our app. If you'll recall from the C# Fundamentals series, it creates a Bin\Debug directory where it places the .NET assembly as well as any additional files required for the app to run. Here's what the Bin\Debug directory looks like for our PetSounds app:
We see the .NET assembly (PetSounds.dll) and a file that we can ignore that helps coordinate Visual Studio's debugger with the running version of the app (PetSounds.pdb). There's some folders that match ones in our Visual Studio project, like the Assets folder, the es folder for the Espanol version of our AppResources.resx, and a Properties folder. Then there's a AppManifest file and a PetSounds_Debug_AnyCPU.xap.
The .xap file is quite large (6 MB). I happen to know that file extension indicates that it is the deployment package ... a file containing all the files and configurations required to deploy our app on the Windows Phone 8 OS.
Let's have a little fun. I'm going to copy that file to my Desktop ... I right-click the file, select Copy ...
... I right-click my Desktop and select Paste.
Once the file is on my Desktop, I right-click it and select Rename ...
... and I change the file EXTENSION from .xap to .zip ... Windows warns me that this might harm the file:
... this is only a copy, and Visual Studio creates a new .xap each time we deploy, so I select the Yes option in the dialog.
The file now looks like any other .zip file on my computer.
If I select the file in Windows Explorer, I can see its contents (even if I don't choose to Extract the files):
Wow, the .xap file is actually a fancy .zip file containing (essentially) what we saw in the \Bin\Debug directory of our Project! Drilling into the /Assets sub-directory ...
... and eventually into the /Audio and /Animals folder structure, I see the .wav files that we copied into the project a few lessons ago in there.
Let's back out to the root of that .zip file ... I want to see what's inside the AppManifest.xaml and WMAppManifest.xml files ... I right-click on the WMAppManifest.xml file ...
You may be asked which application in Windows 8 you want to use to open this file. Choose Notepad.
In Notepad you can see the true nature of the WMAppManifest.xml file ... it's simply XML ... just a lot of it. In Visual Studio, this complexity is hidden from us through a friendly "designer" ... a page in Visual Studio that restricts the changes we can make to the file.
The real question is: "why does it exist?"
The purpose of the WMAppManifest.xml is to introduce your app to the Phone. It tells the Phone which images to use as Tiles on the Start and Application pages. It tells the Phone which capabilities we hope to use and which languages we can support. It tells the Phone what our name is, and which version of the app this is, which screen resolutions we support, and so on. It is how we integrate our app into the Windows Phone 8 Operating System and ecosystem of apps.
3. Deploying to a physical phone
The final thing I want to try in this lesson is to deploy the app to my Lumia 920 phone. The rest of this lesson assumes you already have a Windows Phone Dev Center membership. It costs $99 per year.
First, I plug my phone into my computer using the USB cord that comes with the phone. I've done this many times before to transfer my music or charge the phone, but never with the intent of deploying an app to it.
In Visual Studio, I'll change from debugging in the Emulator to debugging on the Device using the little down-arrow next to the Run button to choose that option:
Next, I'll click the Run button on the toolbar, but will get an error:
So, the first thing I need to do is to unlock the phone for development. The URL in that message doesn't work ... use this URL instead to learn more:
I'll search for the Windows Phone Developer Registration app that was installed when I installed the Windows Phone 8 API on my computer.
In Windows 8, go to the Search charm ...
... and type in "Regi" ...
... that should be enough to locate the Windows Phone Developer Registration app ...
Start the app. It will take you back to the Desktop and display the following dialog ... as you can see, it tried to determine the status of my phone, however the lock screen was locked.
I unlock the lock screen and click the Retry button.
I click The Register button button and it asks me to Sign In to my Microsoft account ...
... Just a note, this always require I sign in twice for some reason. Don't be alarmed if you experience a similar behavior. You can usually get in on the second try.
After a moment, I get a confirmation that the phone was successfully unlocked for development:
I can confirm this by logging into:
(1 ) I navigate to the Dashboard
(2 ) Account
(3 ) Phones
(4 ) The phone I just registered shows up there correctly.
You'll note the name of the phone ... "Bob Tabor's Phone" ... I changed that in Windows Explorer by right-clicking the phone and selecting "Rename". This will allow me to test on multiple phones and tell them apart.
Now that I have the phone registered, I should be able to deploy the app to the Device.
But alas ...
... I must unlock the Device's lock screen and try again.
But after I overcome all the obstacles, I can finally see my PetSounds app running on my phone ...
... and not only can I see it, but it actually works! I can annoy my kids and pets with a duck quack!
To exit out of the debug session, use the Stop button on Visual Studio's toolbar just like you would if you were running in the Emulator.
Even though I stop debugging the app on my Device, the app is still present there and I can still run it even if I unplug the Device from the computer. Each time I debug, it will deploy the latest version of my app to the physical device just like it did in the Emulator.
Before we move on, you may see a message like this in the future:
Apparently, there's a limit to the number of apps you can deploy to the phone. I think it is limited to 10. If that happens, just uninstall one or more developer apps the way you would uninstall a regular app. I.e., hold down on the tile and select Uninstall.
And suppose that you want to unregister your phone for development for some reason. You can re-run the Windows Phone Developer Registration Tool and it will identify the phone as being unlocked for development and provide an option to Unregister the phone:
4. Obtaining a Windows Phone Dev Center membership
Finally, as I alluded to earlier, before you can register a phone for development and deploy your apps to it for testing, or later sell your apps in the Marketplace, you'll need a Windows Phone Dev Center membership. It costs $99 per year if you purchase it directly from Microsoft.
However, there is a second option. Nokia has a Premium Developer Program for Lumia that not only gives you a Windows Phone Dev Center membership, but also gives you Telerik's Rad Controls for Windows Phone, a Buddy.com membership and two Nokia tech support tickets that you can use, presumably, if you run into challenges while developing or deploying you Phone apps. This is the deal I took advantage of and it worked swimmingly.
To recap, the big take away in this app was the composition of a deployment package, the purpose of the WMAppManifest.xml file, and deploying to a physical phone device for debugging from Visual Studio. We talked about registering your physical device to unlock it to deploy developer apps to it, and how to obtain a Windows Phone Dev Center account.