I have a Silverlight Line Of Business application which is run on an intranet as an Out Of Browser app.
Now since we have a staging server for testing releases we rewrite the manifest file inside the Xap file so that the application name is concatenated with the instance name. This appears in the window title-bar and means I can have the production and test versions installed on the desktop and easily tell them apart. Reduces the chance of doing something dumb to the production system by mistake…
Very handy and pretty unusual.
The Silverlight client also makes use of the Microsoft Enterprise Library which gets configuration information from a specially crafted xaml file – also located in the Xap. This xaml file is dynamically generated from a conventional configuration file on the server. This means that changes to the config on the server will cause a new Xap to be generated and the app will detect this upon start-up.
I reckon this is very rare.
All this is preamble – the problems started when the client needed elevated permissions – this broke auto-update because the Xap wasn’t signed and it couldn’t be signed during development because it is rewritten by the web-server…
So now the web-server signs the Xap package after rewriting has been completed – with a certificate issued by the local domain controller (this neatly avoids certificate trust problems as client machines already trust the issuer.)
I don’t know about you but this might make for a few sleepless nights…
Still having a working auto-update is nice!
I had quite a few hoops to jump through to get the code-signing certificate for the server too but that is another story – this blog post is long enough as it is!
In keeping with the modular nature of the original SDK, I have broken apart the source-code into separate assemblies.
Contains common classes.
Contains low-level PAP core and configuration classes.
Contains high-level push core, subscription, application management, request tracking and statistics.
Contains all acknowledgement handling extensions.
The code base has been updated so that SDK assemblies now share common version information via a custom (TFS Build friendly) target file – there be some cool tech in there that you may find useful in you own projects and solutions.
I have also started work on the deployment technology, enabling easy installation of the SDK for developers.
The installer project makes use of WiX and is dependent on WiX 3.6 Release Candidate (available at Windows Installer for XML
At the time of writing the project is bound to the latest build (v3.6.3025.0). In due course a merge-module project will be added to support your own deployment scenarios.
Finally I will be looking into a clean method for adding code-signing into the project files without having to go through the pain of actually having the signing file in source control (I’ll get endless requests for the signing password) – I suspect this will be best achieved with a tweak to my custom build target.
I’ll try and put together a new build and release to CodePlex over the coming week – real busy though so please be patient!
You can now download the sources for the BlackBerry Push Service SDK from the CodePlex web site from this link.
You should refer to the RIM Java documentation as this is a fairly close port however a sample web-site and test library is in-progress…
I am also looking for helpers for maintaining this project and adding source-level documentation 🙂
To be honest porting an API from one language to another can be pretty dull however once the grunt work is finished you can sometimes tweak the code to take advantage of specific language and/or platform features.
Since the shape of the existing API is synchronous I knew early on that changing the communications stack from blocking to non-blocking would be high on the ToDo list – to be fair if .NET did not have the async/await keywords I wouldn’t have bothered as writing async code without this feature is difficult and error-prone.
With this in mind I started with the lowest layer code that handled the request/reply over HTTP with the PPG inside IPapService – fairly simple since the comms classes already have Task-based wrappers.
After that follow the logic (and the build errors) into IPushService. The public API featured simple changes however under the covers the changes were more widespread…
ISubscriptionService is teeming with multi-threaded parallelised code so not only were there API changes but there was also an opportunity for refactoring a lot of the job partitioning logic into something much more concise and therefore easier to understand.
All this work meant that it was easy to update the acknowledgement HTTP handlers so that they are now implementing IHttpAsyncHandler which is good news!
So where are we? Well the CodePlex project has been created and the source will be checked in over the next few days – initially for Visual Studio 2010 but with VS2012 .NET 4.5RC version to follow.
Finished the subscription service and with that also concluded the implementation of the high-level push service interface: IPushService. I also knocked out the acknowledgement service and placeholders for the content provider notification and authentication services.
This means that all the major parts of the SDK have now been ported!
Now I am looking at parameter validation, type-safe exception types, Enterprise Library logging support and fully documenting the source to ensure the SDK is nice, robust and easy to debug/maintain.
I will then look at making the comms logic asynchronous and seeing how far up the call chain that work goes – perhaps IPapService and IPushService will go from synchronous to async APIs – I certainly hope so!
Finally I will start a Push Plus evaluation so that the advanced functional support can be fully tested.
At that point I will upload the solution to CodePlex for consideration by the community.
Once I completed and tested this code I will be looking at which API segments can be switched into Task based async methods.
The communication methods that form the IPapService and IPushService, the synchronisation and PPG notification methods in ISubscriptionService are all obvious candidates as they currently rely on blocking I/O calls.
I will be releasing three solutions;
- VS2010 + Async CTP
- VS2012 + .NET 4
- VS2012 + .NET 4.5
Please don’t thank me all at once… Rest assured I have my reasons for doing this!
I’ll dive straight into today’s changes. The subscription service repository is fully coded – a lot of functions but easy enough.
The subscription service itself is 70% completed with all the validation and query methods done.
Thankfully the Task Parallel Library and the new async/await keywords has meant that implementing the multi-path parallelised synchronisation code was a breeze.
Work is underway to implement the subscription code which is more complicated than it first appears – no surprise really as it must cope with users swapping device and other weird and wonderful use-case scenarios.
I had to re-code the SubscriptionQueryResponse class so as to flatten the XML returned from the server. Makes life simpler.
It was fun tracking down the endpoint addresses used by the subscription service – at one point I thought I might have to install the Java API along with Apache and watch network connections via Fiddler…