Update: I just read this post in my news aggregator and some of the formatting didn't make the translation. For best evaluation you should probably look at this post in your web browser at http://blog.retrosight.com/DocumentationWhichDoYouLikeBetter.aspx.

I'm willing to bet Jeff Atwood has an opinion about this given his recent post Escaping From Gilligan's Island. We've been having an internal debate on how to best document steps to create applications -- mostly so folks find it easy to get it right the first time (hence the hat tip to Jeff's post).

I'd like to get your opinion on which of the following set of steps you find easier to follow (A or B) -- these steps are based on the Visual C# 2005 Express Edition Integrated Design Environment if you would like to try them out for real.

A - Create a strong name key file and add to the project assembly

1.       In the Solution Explorer pane, right-click the project and click Properties.

2.       Click the Signing tab, select the Sign the assembly check box.

3.       In the Choose a strong name key file list, click New.

4.       In the Key file name box, type a name.

5.       Optionally, select the Protect my key file with a password check box and enter a password for the key file.

6.       Click OK.

7.       On the File menu, click Save All.

8.       On the Build menu, click Build Solution to build the project assembly with the strong name key file.

B - Create a strong name key file and add to the project assembly

1.       Select the project in the Solution Explorer pane.

2.       Select View > Property Pages from the menu.

3.       In the Properties window:

a.       Select the Signing tab.

b.      Check the box labeled Sign the assembly.

c.       Click on the Choose a strong name key file drop-down list and select <New...>.

d.      In the Create Strong Name Key dialog:

                                                               i.      Enter a key file name

                                                             ii.      Optionally provide a password for the key file.

                                                            iii.      Click OK.

4.       Select File > Save All from the menu.

5.       Select Build > Build Solution from the menu to build the project assembly with the strong name key file.

Categories: Media Center SDK Code Sample | Software Development Kit | Windows Media Center | Comments [7] | # | Posted on Friday, June 22, 2007 5:53:03 AM (GMT Daylight Time, UTC+01:00)   

IgnoranceIsBliss continues his series on creating a Windows Media Center application using managed code (C#) and Media Center Markup Language (MCML). In his most recent post Stage 10 - Installing It he has the following to say about writing registry keys directly instead of using the Registration API:

1. Charlie, the Microsoft product director for Media Center extensibility (IE. the Media Center SDK) has informed me that MS won't guarantee that the method of registering plugins will remain the same. Of course, I then asked 'OK - then why do you TELL us to register them that way?' and there wasn't much of a response. I'm yet to see if this is still true in the newer version of the Media Center SDK.

2. If you run a 32 bit installation on a 64 bit version of Windows, your registry entries are placed in an entirely different tree. So the 64 bit version of Media Center can't actually see the keys you've created.. This means you MUST produce both a 64 and 32 bit version of your installer.

Microsoft themselves suggest you use WiX, which is an open source product of theirs that allows you to create installers - but since it's a complicated platform and I want to be able to take you through the basics without needing any additional software, I'm going to take you through the easy, but perhaps not officially supported method of adding registry keys directly.

In response...

A) The reason we provide an abstraction layer for the registry keys is simple: We can change the underlying methodologies for registering experiences without breaking the apps (or their installers). For example, suppose we change where Windows Media Center looks in the registry for applications. By writing registry keys yourself they may end up in a location we aren't polling -- and therefore the app won't appear. Using the API will always work even if we change things under the covers. Abstraction is good -- it helps you maintain forward compatibility.

B) There are a very few select OEM scenarios where writing the registry keys directly makes sense. Specifically, where you are using a single image for thousands of preinstalled machines. Outside of this specific scenario (i.e. if you aren't an OEM using this to prep machine images) there is no good reason to write the registry keys themselves, and to do so only increases the risk the installer will be possibly broken at some later date. I've even advised OEMs to use the Registration API during the preinstall phase rather than write registry keys.

C) We include writing the registry keys directly for those who are committed to only using a Visual Studio setup project. Effectively, the Windows Media Center Platform team does not recommend using the Visual Studio setup project because of it's inherent limitations (which are more than just this singular issue). As a bonus, using WiX also makes the installation solution accessible to folks using free tools (Visual C# 2005 Express Edition) as well.

D) WiX does carry a higher learning curve. Along with that comes much more granular control over the installer and, perhaps more importantly, a fundamental understand of what is happening when the user installs the application. FWIW, I personally found it difficult at first, but now that I've got a pretty good understanding of the pattern in the WXS file it's much more 'friendly' to me compared to a Visual Studio setup project -- which abstracts everything out too much in my opinion, and I'm not even a setup guru and love the abstraction to make it easier (just ask Aaron).

D) If you do follow IgnoranceIsBliss logic, just remember it's pretty unfriendly to force a user to figure out which installer to use (32 bit or 64 bit) -- especially given the actual library is identical for both (you don't need to compile for each in the context of a Windows Media Center application). Make it simple -- have a single installer. That means using the Registration API and WiX.

E) We revised this SDK documentation with the last release (see http://msdn2.microsoft.com/en-us/library/bb189827.aspx) which quickly vectors the reader back to 'use the Registration API'. We will make further clarifying changes in the future.

IgnoranceIsBliss has done a pretty good job of giving you a guide to creating a Windows Media Center application -- just make sure you use his documents as a supplement to the information in the Software Development Kit -- not in lieu of.


Categories: SDK | Comments [3] | # | Posted on Monday, June 18, 2007 8:23:23 PM (GMT Daylight Time, UTC+01:00)   

I was wondering if there are any computer user groups in North Carolina who would like to sit down and chat about Windows Media Center...? If there are and you'd like to get together, drop me an email at charlieo@microsoft.com and let's chat. I'll be in the Raleigh area as well at some point so could do a chat there as well.

[Update: Corrected email address. Dang it.]

Categories: Community | Windows Media Center | Comments [3] | # | Posted on Saturday, June 16, 2007 5:41:53 AM (GMT Daylight Time, UTC+01:00)   

Apple is a huge competitor in the space Windows Media Center seeks to inhabit. Evidence?

Front Row and Windows Media Center

Apple TV and Media Center Extender

But even though I want to compare and contrast these products I find myself always holding back.


Because of the signal to noise ratio. On the somewhat rare instance I do post something related to Apple it almost never fails that folks show up bringing nothing to the conversation of value. Case in point, go read the two comments on Thoughts on iPod Amnesty Bin. After reading those I again had to ask myself 'why bother'.

Mary Jo and Long are beginning to understand the pitfalls of writing anything other than high praises of Apple.

So, I ask myself would it be worth the time and effort to give my perspective of MacOS, iPod and AppleTV or will I be labeled as just another Apple hater who works for Microsoft. Can I count on the community (both PC and Mac) to engage in the conversation?

Categories: Apple | AppleTV | Media Center Extender | Microsoft | Windows Media Center | Comments [8] | # | Posted on Wednesday, June 13, 2007 7:10:42 PM (GMT Daylight Time, UTC+01:00)   
RSS 2.0
Sign In | All Content © 2014 Charlie Owen

This is a personal weblog. The opinions expressed here represent my own and not those of my employer.

Powered by newtelligence dasBlog 2.3.9074.18820