One of the hardest things about shipping software is shipping software. During the final testing phases for our Windows Phone Developer Tools CTP refresh, we discovered a bug that will impact developers using some existing “transparent Silverlight” assemblies (Microsoft & 3rd party) in their Windows Phone applications. So we had a choice to make: 1) pull back the release to fix the underlying problem (which may have taken up to two weeks given where the actual problem exists and how the engineering & test work required to validate the fix didn’t cause other regressions), or 2) shipping what we had with relatively simple work around.
I like to tell everyone who will listen to me that my job is to be the number one and loudest advocate for our Windows Phone developer experience. Since so many of you have already updated to the recently released Visual Studio 2010 final release, I didn’t want our community to wait any longer for access to the updated Windows Phone tools. We feel confident that this issue impacts only a small subset of Windows Phone developers, but we want to be as transparent as possible about this issue, and get the word out about the work around as quickly as possible.
The Bug – System.IO.FileLoadException
When loading assemblies that make up an application, the Windows Phone OS checks their digital certificates. There are 3 types of assemblies:
1) Those included with the phone – these are signed with a Windows Phone cert
2) Those that are provided by other SDKs – these are transparent Silverlight assemblies, and are generally signed with some other cert
3) Those that are built as part of your app – these are your source code, and in this release they aren’t getting signed
In one of those “d’oh” moments, we found that the loader, in this iteration of the Windows Phone Developer tools, fails to load assemblies that are signed with non – Windows Phone specific certificates. So any signed SDK assembly will fail to load. This issue will surface if you are trying to use transparent assemblies from toolkits such as the Silverlight SDK (e.g. to use the RSS capabilities found in System.ServiceModel.Syndication.dll).
The problem is specific to this release of the Windows Phone Developer Tools. It will be fixed in a future update.
Detecting the Problem
If your app deploys to the emulator, but fails to run with a “System.IO.FileLoadException” then you may be using a signed assembly. These will be assemblies you manually added to your project.
For example, if you have an application that uses System.ServiceModel.Syndication.dll (which is an assembly shipped with the Silverlight SDK and thus is digital signed) and you try to run that application in the emulator it will fail in the debugger with an error like this:
A first chance exception of type ‘System.IO.FileLoadException’ occurred
The workaround is pretty straightforward: Temporarily use copies of the assemblies which do not have signing certificates in them. I have provided a PowerShell script that will make creating these copies easy. Simply run it, specifying the path to the assembly you want to use, and it will create a copy with an easily identifiable filename prefix of “WP7_CTP_Fix”. You can then use this assembly with the CTP Refresh.
Finding The Location Of The Assembly DLL
1. For each project in your solution, expand the References folder to show the list of referenced assemblies.
2. In the Properties for each assembly the Path property will contain the fully qualified path to that assembly (If the Properties Windows is not showing press Alt-Enter until it shows up and the Properties list is expanded).
How Do I Know An Assembly Is Digitally Signed?
1. If your app deploys to the emulator, but fails to run with a “System.IO.FileLoadException” then you are probably using a signed assembly.
2. In Windows Explorer right click on the assembly – choose Properties if the Digital Signature tab is present and contains a signature it is signed.
Using The Script
1. First save the script to your machine to a file named wp7ctpfix.ps1.
2. Copy wp7ctpfix.ps1 to the folder containing your signed assembly.
3. Open an elevated command window and go to the folder from step #2. You can do this by right clicking on the Command Prompt in the Start menu, and selecting “Run as Administrator.”
4. Run “powershell” to enter PS window. UDPATE: A commenter usefully pointed out that Powershell is initally set to block execution of all scripts. Read about it by typing: get-help about_signing. The solution is to enable script execution by running command: “set-executionpolicy remotesigned” .
5. Run “.\wp7ctpfix.ps1 <your signed assembly>” in PS window. Please note, that a fully qualified path name is required. For those unfamiliar with PowerShell, the “.\” in the front part of this command is required for PowerShell.
6. The tool will show “Operation succeeded.” if it succeeds.
7. A new dll “WP7_CTP_Fix_<your signed assembly>” should be created in that directory.
8. Type “exit” to exit PowerShell.
Referencing The New Assembly
1. Open your solution in Windows Phone Developer Tools.
2. Expand the References folder and remove the original (signed) assembly by right clicking it and choosing Remove.
3. Right Click on the References folder and choose Add Reference…
4. Use the Browse tab of the Add Reference dialog to navigate to the folder containing the assembly. Select the new dll file (e.g. WP7_CTP_Fix<your signed assembly>).
The Fine Print
We’ll fix this problem in a future update, and when we do you’ll need to go back to using the signed assemblies. Because there’s no way for you to distribute or make money from apps containing these assemblies, and those apps won’t run on anything other than the WP7 emulator, the scope and impact is pretty small. For Microsoft signed assemblies we are providing temporary blanket permission to use this technique to work around this problem. And now the official words from our lawyers:
So as to enable you to load your applications on the pre-release version of the Windows Phone 7 operating system that is included with this April 2010 CTP of the Windows Phone Developer Tools, you may temporarily remove the signatures from any Microsoft-owned assemblies that you would otherwise be licensed to include in your programs, solely for the limited purpose of evaluating this CTP. Upon the next pre-release of these Developer Tools or July 31, 2010, whichever is earlier, you must replace such signature-stripped assemblies with assemblies from which the signatures have not been removed. Nothing in this statement should be interpreted as permission on behalf of owners of non-Microsoft assemblies.