WP7, strong name, WCF

WP7, strong name, WCF

Old forum URL: forums.lhotka.net/forums/t/10329.aspx

mesh posted on Saturday, April 30, 2011

What Am I missing? WP7 assemblies can be signed only via Marketplace submission? So, how can unsigned WP7 app (in dev. / test ) "talk" with strong named server side data portal assembly via WCF? Or same thing, once app is submitted to Marketplace, and signed with another key...


RockfordLhotka replied on Saturday, April 30, 2011

My recommendation with WP7 (and other mobile apps) where you don't control deployment, is to avoid using a client-server model. Although I have demos (like SimpleNTier) that show doing this, it is for dramatic effect. And maybe I should stop - because as cool as it is for a demo, it is bad architecture.

The problem goes beyond signing. You will almost certainly need to version your server independently of the mobile app. You can't control the pace of deployment of your mobile app - because of the marketplaces, and because the user might ignore the update. You can't force the issue.

Therefore you must use a decoupled model between the mobile app and your server app. Notice that I just described this as two separate apps. That is SOA. And I really do think SOA is the right archtiecture for mobile apps.

So build the mobile app with CSLA and the local data portal. In the client-side DataPortal_XYZ or factory methods, call REST or SOAP services on your server.

The services are the interface to a separate app that runs on the server. This interface (XML, JSON, etc) is your contract between the two apps.

This allows you to version the server app independently from the mobile app, as long as you can avoid changing the contract. Obviously there are limits to how far you can take this idea - but it is a far better architecture for this type of app than an n-tier architecture.

And it solves the signing issue, because REST/SOAP services don't have the same low-level requirements as the n-tier data portal.

RockfordLhotka replied on Monday, May 02, 2011

I do think, however, that the signing that the marketplace does is for the application manifest, not for your specific assemblies. In that case the data portal should work fine in n-tier mode (regardless of whether that's the ideal architecture).

Or have you seen something to indicate that they re-sign your actual assemblies?

mesh replied on Tuesday, May 03, 2011

Thanks Rocky!

- If we are talking about the online biz. application, where data is located somewhere on the server, I think the WP7 developer can require mandatory update for his application. In an extreme case, there is even the possibility of simultaneously supporting current AND previous server version... In that way customer can continue working with old version until he is in wi-fi/home area to conduct an update. Anyway, in mobile applications development, app versions are slightly less frequent...

Also, we must not forget the fact that WP7 Mango update brings SQL CE local database and the LINQ / ORM framework... So online only apps will be rare, but we must not exclude n-tier/client-server solution just beacuse maybe thats a bad architecture... I think that decision should be based on sound arguments.

- I'm not sure about the signing assemblies problem. That part I have to explore in more detail. Just for a start, here's part from the Windows 7 Phone Application Certification Requirements Document:
"1.1.2 Code Signing
Code signing occurs automatically once the application has successfully passed the certification testing without any failure. The application and repackaged XAP files are signed with the Authenticode certificate assigned to you when you registered for App Hub membership. Any signatures submitted in a application or XAP files will be replaced and are not retained.
All applications must be signed with the Microsoft Authenticode certificate issued before they can be installed and run on commercially available Windows Phones."

- Suppose that we have signed assemblies, question that really interested me: What is the potential scenario that hackers could exploit an attack on the public WCF service / CSLA portal??

Copyright (c) Marimer LLC