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:
1. 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.
2. 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 al 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.
Recap
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.
No comments:
Post a Comment