Even a chimp can write code

Thursday, August 24, 2006

Achievement unlocked

It is the little things in life that matter much. Yesterday, I successfully argued for a bug fix in the Windows Shiproom.

This was my first time in that august place and at first I was a bit overwhelmed. At 3pm I entered this large conference room which was already packed to the rafters and the meeting had just begun. At the center of the room was a large table with what seemed like 18 people - an assortment of architects, project managers etc. - seated around. No, Brian Valentine wasn't there although that'd have been the icing on the cake. I've never had the pleasure of arguing with him. Around the fringes of the room were about 10-12 more chairs, all taken. There were people standing and leaning against walls; others were seated, with some squatting, and still others like me with their feet stretched forward, getting in the way of people bustling into the room. If there was one common thread tying everybody in this room, it was that everybody had an opinion and was willing to let you have it. Good, I like it when they're aggressive. It tells you they care about what goes in and what stays out.

One wall was lined with clocks showing the current time in places around the world. There was a large map of the world on one side. None of these implements were used in the time I was there, but like in a tasteful B-movie, I thought they added to the ambience and elevated the importance of the place. An adjacent wall had a poster recording the "Longhorn build release counter" which listed the number of consecutive dates that a build has been released from the main Windows branch, compared to the all time record. The wall opposite the clocks was lined with several posters, each with a classic cop-out or explanation like "Oh, its only a one line change in the [manifest | XML file]" that the Shiproom has heard one too many times.

The Windows Shiproom is the final arena where your Windows bugs are approved or rejected. In the typical development cycle, your bugs do not get escalated to this level. But when the product - in this case Windows Vista - goes to escrow, it is effectively under lockdown, and only high value changes are considered by feature/component teams and brought up to the Windows Shiproom. Once these bugs are fixed and exhaustively tested, one goes to through the various Shiprooms for approval. In the case of this bug in question, that journey involved the feature team triage, dev changes and test work, the Avalon Shiproom, the .NET Framework (WinFX) Shiproom and culminated with the Windows Shiproom.

Aside from procedural questions and quality gates questions, one is asked for a problem description as an end-user scenario, the nature of the bug, the nature of the fix, the risk of the fix, the risk of not taking the fix, the amount and quality of testing that went in, etc. Most times at the local Shiproom, you are asked what other such problems could/will occur and what you're doing to prevent them. Because the playing fields and system interactions are so different between the feature level, the component level and the OS level, different sets of experts need to scrutinize the fix and give approval. This is especially important when the product is locked down and considered stable. Fixes that pose lowest risk to the product and highest value to customers are the ones that survive, while the others die by the wayside, at the feature team triage or local Shiproom levels. My bug came for consideration toward the end of the meeting and a couple minutes later the Shiproom gave its approval.

This couple hours was an important experience for me and taught me a great deal about shipping products. The motivations behind your decisions are different based on where you are in the product's development cycle. You do everything you can to make sure your customers have the best possibile experience. Only, it is manifested in different ways at different times. During active development, we go the extra mile to make sure a fix goes in. But when the product is stable and is ready to ship, one needs to take a measured look at what impact one's fix can have on all of the hard work that went in over the years. You're still being true to your customers. You're just showing it differently.

If life were an XBOX 360 game, I'd see the little notification message that says "nerddawg: Achievement unlocked".

Tags: , , , , , ,

Email this | Bookmark this

Wednesday, August 16, 2006

Debugging Windows Presentation Foundation applications

Windows Presentation Foundation (WPF) apps, like other managed code applications, can be built on the command line as well as within an IDE like Visual Studio. The Visual Studio IDE environment with "Orcas" tools provides for sophisticated debugging features. Since there are some nuances to debugging, I figured it merited a post. I will try to keep this live, as things change.


The F5 debugging

People familiar with managed code debugging will see that the process of debugging WPF apps, whether standalone or browser-hosted, is pretty much the same. Within VS, you hit F5 to start the app in debug mode.

WPF browser-hosted apps (XBAPs), unlike their standalone counterparts, do not have a main method in the application executable. They are therefore launched by PresentationHost.exe, an out-of-process document object host, which is the registered Shell and MIME handler for .xbap files.  The XBAP project file lists PresentationHost.exe as the program that needs to be launched when you debug XBAPs (via StartProgram project property). The StartArguments property lists the command line parameters passed on to PresentationHost.exe. The notable item here is the -debug argument that tells PresentationHost.exe, "You are running in debug mode. Here's the XBAP you need to launch. Be a darling and don't induct it into the ClickOnce store".

There are some notable differences you need to understand:

  1. When you debug an XBAP, your app is not ClickOnce-deployed; meaning, the app is not inducted into the ClickOnce app store. This allows you to rev your application without revving the version numbers.
  2. Because of the above, the app will not return ApplicationDeployment.IsNetworkDeployed as true.
  3. The app is launched from your project's OutputPath (bin\Debug folder) and that location is treated as the "site of origin" for the app. Any remote resources need to be manually placed at that location.


Debugging by attaching to a running process

This is like attaching to any other running program in Visual Studio, except that you attach to PresentationHost.exe, not the XBAP or its executable. Assuming you've set breakpoints in the source files, the actual debugging steps are:

  1. From a command window run: %WinDir%\system32\PresentationHost.exe -debug
  2. Within Visual Studio, click project Properties -> Debug
  3. Check Enable unmanaged code debugging. Save your changes. 
  4. Click Debug -> Attach to Process
  5. Select PresentationHost.exe from the available processes list
  6. In the Attach To section, hit Select and check Managed Code and Native Code
  7. Click Attach
  8. Double click on the XBAP from your project's bin\Debug folder

The app will launch in your default browser. All your break points should get hit.

If you have multiple XBAPs running, make sure you attach to the right PresentationHost instance. It is easier if the XBAP being debugged is the only XBAP running. Also, the next time you want to debug the same XBAP, make sure you've cleared the ClickOnce app store (using mage -cc) or incremented the app's version.


Files at site of origin

If your app needs to access files or web services residing at it's site of origin, you can still use the F5 debugging method. Only, you need to tell Visual Studio to debug the app as if it were deployed from that location. Say, you have an app that is intended to be deployed from http://www.yoursite.com/apps/. Now, that location is deemed the application's site of origin. Suppose you have several data files and a web service running at that location, that your WPF app needs to access. You need to:

  1. Navigate to project Properties -> Security tab -> Advanced button
  2. Make sure the "Grant the application access to its site of origin" option is checked
  3. Type in the location from where you want VS to believe the app is deployed. In our case, it will be http://www.yoursite.com/apps/
  4. Click OK
  5. Hit Ctrl+Shift+S to save all files
  6. Close the solution (File -> Close solution)
  7. Re-open solution
  8. Hit F5 to debug 

Steps 6 and 7 are required because currently these properties are applied only on project load. These actions modify the project's StartArguments property. Please do not edit its value separately.


Debugging XBAPs to be run within Media Center

Assuming you have the Media Center SDK and by extension the XBAP templates for Media Center installed on your development machine, here's how you debug an XBAP meant to run in MCE:

  1. From a command window run: %WinDir%\system32\PresentationHost.exe -debug
  2. From within Visual Studio, hit F5 to debug your XBAP

A .MCL file is created and the MCE Shell (ehshell.exe) is launched with this file name as parameter. You will see your XBAP load and all your breakpoints should trigger.

There are one issue you need to be cognizant about: While running or debugging your XBAP (created with the MCE template), you will notice that changes you made to the app are not reflected when the app is run. This is because the app run outside of VS was somehow cached in the ClickOnce app store (unlike with conventional XBAPs). You can work around this issue by incrementing the version number of your application, or by using mage -cc to clear your ClickOnce app store. Make sure the MCE shell is closed when you do this. Mage.exe ships with the .NET SDK or Windows SDK.


Happy debugging!

Tags: , , , , , ,

Email this | Bookmark this

Tuesday, August 15, 2006

WPF deployment errors and what they mean

Platform Requirements Not Met

During deployment, the pre-requisites and references listed in the WPF browser application's (XBAP's) manifests are matched against the libraries accompanying the application (reference assemblies) or those installed in the Global Assembly Cache (GAC). If one or more references in the application manifest cannot be located, the "Platform Requirements Not Met" error is shown.

If you build your WPF app using one version (or CTP) of .NET Framework 3.0 but have another version on the client machine, you will see this error. In addition, you will see a "Get .NET Framework" button so you can download and install the right version of the platform in order to view the app.


Trust Not Granted

The "Trust Not Granted" error typically indicates the app is asking for more permissions than are available to it based on its deployment zone, or using features not supported safely in the sandbox. This is the sandbox refusing to run the app. As a workaround, I'd recommend running it from a different zone, say intranet or even Local Machine. If your app however does need to run in that specific zone (say, Internet zone), then you must re-factor the pieces of code that require elevated permissions or rely on features not enabled to run in the XBAP's partial trust sandbox.

Some time ago, there was a bug in the XBAP deployment mechanism of a .NET 3.0 CTP that resulted in the "Trust Not Granted" error showing up in place of "Platform Requirements Not Met", which shows up when your application requires one or more libraries not installed on the client machine. That has since been fixed but if you have older CTP bits of WPF on your client, you could be seeing the error because of this.

Email this | Bookmark this

Friday, August 11, 2006

New Mac TV Ads. Not!

Kam, Robbie, Jennifer and I were talking about the Mac ads, featuring John Hodgman and that other pretentious ass, getting heavy rotation on television. I love those ads! They make me wanna run and buy a new PC. Maybe I just identify with John's character. Well, apparently a few guys from The Best Week Ever had too much time on their hands and the result is this spoof on the said Mac ads. Here it is. Worth a look.


Tags: , ,

Email this | Bookmark this

Monday, August 07, 2006

The JSON RFC and JSONRequest

The JSON RFC (4627) was recently submitted by json.org. They are also proposing a JSONRequest which will be similar to XmlHttpRequest but allow two-way XML data interchange with cross-domain access securely.

I think the RFC speaks of good tidings, but I have mixed feelings about the JSONRequest particularly since the Web APIs WG recognizes the problem and intends to support cross-domain access. Besides, does this model of having FooRequest and BarRequest for every little detail really scale?


Email this | Bookmark this