ChevronWP7: Now without the sideload limit.

on 9 Dec, 2010 in Windows Phone | 0 comments

It wasn’t long ago that ChevronWP7 was released, finally enabling everyone to take advantage of the Windows Phone 7 platform by running homebrew applications on it. Rafael Rivera said we could expect an update where the standard limit of 10 would be removed, though this sadly was not to be. After discussions, ChevronWP7 was discontinued, in favour of a homegrown homebrew solution from Microsoft. However, that’s not here yet, and realistically, it won’t be here for some time yet, so thanks to XDA Developers, we can continue using ChevronWP7 for the time being. However, as homebrew apps really start coming out, fitting them into that limit of ten is becoming a harder and harder task. So I decided to take to poking around inside ChevronWP7 with Red Gate’s .NET Reflector. Now, sure the assembly had been “secured” with Dotfuscator, but dotfuscator is one of the weaker obfuscators on the market. All that was used in ChevronWP7 was object-renaming and namespace-collapsing, so it wasn’t too hard to track down the necessary code. In fact, the necessary value was just one integer in the XML file the HTTP Server returned in response to a request from the phone. From: <a:AppsAllowed>10</a:AppsAllowed> To: <a:AppsAllowed>2147483647</a:AppsAllowed> This simple piece of XML can be found in the (-.)bg.a(object, b8) method, as it is called in the assembly. So without further ado, here’s a link to my modified assembly. I did modify the credits slightly at the bottom, so users can always tell whether they’re using the original 10-apps ChevronWP7, or my modified no-limits...

Read More

Avoiding Reflection: Adding the InteropServices library to the WP7 SDK

on 15 Nov, 2010 in Windows Phone | 1 comment

It’s a bit of a hassle to have to reflect the code as and when you want to use it in your code, so adding it to the files with the Windows Phone 7 SDK allows you to reference it just like any other included library. You must have admin rights (as it requires changing files in your Program Files folder) and a copy of the Microsoft.Phone.InteropServices.dll, easily obtained by extracting them from an Emulator BIN. It will originally be named something like GAC_Microsoft.Phone.InteropServices_v7_0_0_0_cneutral_1.dll. You should rename it as I described above, before copying it to “C:\Program Files\Reference Assemblies\Microsoft\Framework\Silverlight\v4.0\Profile\WindowsPhone”, adjusting C: to the drive Program Files is located on, and adjusting “Program Files” to “Program Files (x86)” if you are using 64-bit Windows. Then, navigate to the RedistList, where there is a “FrameworkList.xml”. This lists the files in that particular framework, and it is how Visual Studio populates the list of DLLs available to be referenced. You’ll need to open it up in a text editor, running as administrator or you won’t be able to save the modifications. Find the line:    <File AssemblyName="Microsoft.Phone.Interop" Version="" PublicKeyToken="24eec0d8c86cda1e" Culture="neutral" ProcessorArchitecture="MSIL" InGac="false" /> Duplicate that line underneath itself, and change “Microsoft.Phone.Interop” to “Microsoft.Phone.InteropServices” and remove the “PublicKeyToken” attribute. For some reason, the GAC DLL fails Strong Name verification if you leave the PublicKeyToken there, but it doesn’t matter for our purposes anyway. You should then end up with a line like:   <File AssemblyName="Microsoft.Phone.InteropServices" Version="" Culture="neutral" ProcessorArchitecture="MSIL" InGac="false" /> Now, save the file, open Visual Studio, and open your project. As you go to add a reference, you’ll now notice “Microsoft.Phone.InteropServices” is one of the standard assemblies available for you to add, and adding it allows you to use the functionality it provides without having to reflect the...

Read More