| Comments

One of the features introduced with Silverlight 4 was the out-of-browser feature, enabling you to create an application that can be installed, run offline, automatically updated, etc.  As a part of that feature, some of the major code signing certificate vendors (for Authenticode certs) provided our team with test certificates so that we could go through the same process as a developer would to acquire the cert and apply it to an app…and, of course, validate it works.

During that time some of those vendors had promotional codes for the first year for Silverlight developers, providing reduced-rate (but not reduced quality) code-signing certificates for their apps.  Still during this time there were a lot that questioned why some providers were still expensive and didn’t value “the little guy.”  By that I mean that there are a lot of smaller firms or independent personal developers.  The thought of dropping a few hundred dollars on a cert is sometimes tough.

Last week a representative contacted me about their offerings as a premier partner of one of those providers.  Certs4less.com is now offering Thawte code-signing certificates for individual developers.  They are doing this at a price of $99 per year (less for multi-year). 

NOTE: As a part of this, like before with SL4, Certs4Less graciously offered a promotional cert for me to validate the end-to-end process so that I could speak accurately about it.  I do not use any of these certs provided by these companies for testing purpose toward any production application and they are for testing purposes only.  Besides, I’ve not found the time to write production code for apps lately ;-).  I am not getting paid for this post, nor am I getting another promo code for personal use myself.  I am simply providing what I think is valuable information and get no compensation from Thawte or Certs4Less.

I went through the process of obtaining this cert from Certs4Less.com and it produced exactly what you’d expect, a valid Authenticode code-signing certificate I can use for my Silverlight and Windows 8 application packages!  I shared a few points of feedback with the contact there and will enumerate them here for you as well (as well as some tips)

Your ‘Common Name’

Think about this one pretty good when you buy a cert.  This has a two-fold purpose why I mention this.  First, it is what your customers will see.  Do you want them to see an app signed by a name that isn’t recognizable or doesn’t make sense…of course not.  Additionally this is the name that will be verified.  So if you claim you work for Fizbin Enterprises, but that doesn’t actually exist…you’ll have issues during verification.

One year, 2 or more

One thing you should know about code-signing certificates is that once they expire, the keys change during renewal.  In some cases this can cause issues for your app (ClickOnce).  For this reason I personally recommend getting the longest you can afford.  Most likely this will be a wise investment and you’ll have piece of mind.

Apply on the computer you will receive it

One thing we as developers don’t do well is read directions.  One of the instructions you’ll see is to be sure that you do the cert request process from the same machine you plan on picking up the cert from!  Seriously, this is critical if you use the browser process because of the private key.  If you don’t…you’ll be screwed and out some cash.  Plan ahead and don’t do this while on vacation on your laptop that you repave weekly.

Verification Process

This is an area where I think I had the most negative feedback.  These verification steps are a bit old.  I understand they have their reasons, but in this digital age the fact that I had to find a notary was…well, just inconvenient.  This Certs4Less/Thawte process required me to do this.  The ‘form’ they emailed me really wasn’t a form…just an email with text broken out with ‘==========================’ before each section.  So when I brought in my printed out GMail ‘form’ to the Notary he looked at me like I was an idiot.  The verification form was nothing formal looking at all and I had to have 3 different people look at it before they finally just said ‘okay’ and signed it.

The thing that was most troublesome in this process was it was a distractor.  I had to actually print stuff out, find a passport, go to a bank, wait in line…you know, real people stuff.  But still, it felt annoying in this modern age.

Some of my other process with other vendors have been a lot more streamlined and I think this can/should improve.

Acquiring the certificate

Most of the time this is a quick process.  Remember when I mentioned that developers don’t read instructions?  Yeah, I’m no different.  The final email I got indicating my cert had instructions that I didn’t read that talked about making sure I had intermediate certificates installed first.  Without this I got ambiguous errors when trying to retrieve my certificate.  Be sure to read any verification instructions in detail to provide a good experience.

Back up/export your certificate

I don’t know about you but I’d probably use my cert in automated build processes, keep it on a share (perhaps a dropbox/Live/git location) so that I don’t have to only use my one machine to sign an app.  One thing I highly recommend is after the key is installed is to use the certmgr.msc tool and export the certificate.  When doing this be sure to export the all the key data as well as cert chain so that your resulting PFX file is portable.  Then you can use it in your build process for Silverlight as described here in my previous blog post about that feature.

Summary

I want to thank Certs4Less for reaching out to the independent developer and providing a valuable product at an ‘independent developer’ price level.  I appreciate them also reaching out to allow me to test the process to verify it is fairly painless and the result is what I expected.

Code-signing certificates are very valuable in many ways and I believe every developer should have one for their personal projects as well as their large ones.

Hope this helps!

| Comments

In the Silverlight world, there are two types of “cross-domain” things that may leave some banging their head against a wall for a while.  The first involves making network-based calls (WebClient, HttpWebRequest, etc) to services hosted on a domain other than the one that is the site of origin for the XAP.  This is solved by ensuring the service provider enables a clientaccesspolicy.xml file for their service.  More information here: Cross Domain Policy Files with Silverlight.

NOTE: “site of origin” is a term you might see a lot with regard to Silverlight.  This refers to the URI domain of the Silverlight XAP file.  For example: http://apps.mysite.com/sources/coolapp.xap might be a URI that you have for an app.  The site of origin in this is apps.mysite.com (more specifically it is actually the entire URI usually when people refer to this term).  This might help when you read things about cross-domain issues.

The second issues is one of hosting Silverlight applications (XAPs) on your site that are from a different domain.  What I mean here is that your site (www.coolwebapp.com) has an <object> tag for Silverlight plugin that has the Source parameter set to apps.anothersite.com/foo.xap.  This is essentially the cross-domain hosting situation.  What happens in this situation is that the plugin loads but the app does not, presenting in just a big blank space where the app should be.

A recent head-banger sent me a note and I sent him my items to check on how to solve this.  I thought I’d share.  When I see issues with this, I normally tell people to check for one (or more) of three things:

HTML Access

If the Silverlight application is doing anything to work with the HTML DOM of your hosting page, this is the first place to look.  Don’t know if this is happening?  If the Silverlight application uses System.Windows.Browser anywhere it likely does.  By default the tools and templates from Visual Studio generate the bar minimum <object> tag.  There is one property of the plugin, EnableHtmlAccess, that is set (essentially) to true for same-domain applications.  However, for cross-domain applications, you will need to opt-in for this adding this parameter to the <object> tag:

   1: <object data="data:application/x-silverlight-2," type="application/x-silverlight-2">
   2:   <param name="source" value="http://apps.somesite.com/foo.xap"/>
   3:   ...
   4:   ...
   5:   <param name="enableHtmlAccess" value="true" />
   6: </object>

By doing this, you are granting the XAP access to the HTML DOM of the hosting page.  Don’t say I didn’t warn you.

XAP MIME type

When the plugin loads a XAP from another domain, it checks what the MIME type is.  If it is not a valid Silverlight type, it won’t load the app.  This is a security mitigation.

If you are loading a cross-domain XAP, make sure the site delivering the XAP is delivering it with the appropriate MIME type: application/x-silverlight-app.  By default this is set in IIS7/Windows 2008, but not in IIS6/Windows 2003.  You can put this on the server level or the application level…wherever you feel comfortable, just as long as it is delivering it with the XAP. 

Obviously on non-Windows servers, this will not be set at all regardless of the version.  If you are getting a XAP from a Linux/Apache server for instance, the server administrator will want to add the type.  This is simple and you can do it at the global level in the mime.types file.  Or on a per-site basis you can do it by editing the .htaccess (or creating one) in the directory level that will serve the XAP and add:

   1: AddType application/x-silverlight-app xap

If you are using a CDN like Azure or Amazon S3 or something else and they don’t have the type associated, you will need to be creative.  Most CDNs enable you to set the MIME type (or Content-Type) on the file during upload.  For Azure, Silverlight should already be there.  For something like S3, tools like CloudBerry Explorer enable this feature for you (and actually already have a list of types built-in to their tool).

This situation (identifying the MIME type) can be quickly tested using a tool like Fiddler to see what the response and Content-Type are being delivered.  Fiddler is an indispensable tool…go get it, it’s free.

ExternalCallersFromCrossDomain

This is the black hole property right here.  This one is probably a last resort for most.  This property, in the Deployment node of your AppManifest.xaml file controls Javascript and HTML DOM access to scriptable objects defined in the XAP.  Like EnableHtmlAccess, for same-domain situations the setting is irrelevant, but in cross-domain hosted XAPs, the default is the NoAccess option.

To enable this you’ll need to manually edit the AppManifest.xaml file to add the ExternalCallersFromCrossDomain attribute.  There are two properties: NoAccess (default) and ScriptableOnly.  You’d want to *add* the attribute and set it to ScriptOnly.

   1: <Deployment xmlns="http://schemas.microsoft.com/client/2007/deployment" 
   2:             ExternalCallersFromCrossDomain="CrossDomainAccess" .../>

REMEMBER: This is is only if you need to.  Read the documentation to see if this applies to your scenario.

Summary

Sometimes debugging this stuff can be tricky. Having the tools and knowledge makes this easier to track down. Not all situations involve multiple of the above and if none of them fix it, then you might have another issue. Hopefully this helps provide some places to look.


This work is licensed under a Creative Commons Attribution By license.

| Comments

One of the new features in Silverlight 4 is the ability to sign your XAP applications so that your out-of-browser trusted applications look more friendly (trusted) to your users, they come from a verified publisher, and they can take advantage of the auto-update APIs in Silverlight.

If you don’t know what I’m talking about, here’s some resources for some background:

Basically if you are writing a Silverlight 4 trusted application, you WANT to be signing your XAPs.  The XAP sign process uses the normal Authenticode process for code signing. 

Thanks to our friends at GoDaddy, they want you to sign your apps as well and have them delivered from a verified publisher!  They are providing Silverlight developers a 50% discount on their code signing certificates for XAP signing!  If you don’t have a code signing certificate, now is the time!

To participate in this offer, be prepared to have all your information ready.  Certificates are issued to individuals/organizations.  It is much more of a verification process than something like an SSL web certificate.  In fact, the process actually involves human interaction!  You will be required to verify your information on your submission and perhaps be required to provide documentation of verification (if you are an organization readily found on the web, this usually isn’t a problem).  Follow the steps carefully and specifically.  I also recommend using Internet Explorer to go through the process to be safe.  Additionally, you will only be able to pick up your certificate from the machine you requested it on…so don’t pave that machine until you get it :-).

To take advantage of this offer, visit the GoDaddy code signing area and start the process.  You can choose a 1- or 2-year code signing certificate to apply this discount (might as well go for the 2 years so you maximize the discount).  Add the code signing certificate to your shopping cart then add this discount code in the promocode area: MSSILVER.  This will apply the 50% (of regular rates) to the 1- or 2-year code signing certs in your basket. 

Then complete your purchase.  Once complete you’ll receive email instructions on how to redeem the credit you purchased and start the verification process.  Be patient…this is not a 5-minute process.  In fact, in some cases it might take a few days to complete the verification process.

This offer is only good from 20-April-2010 until 20-May-2010 and only on 1- or 2-year code signing certificates, so act quick.  This is a great chance to get a well-known certificate authority code signing certificate.  During the order process you will be given the option to choose a Certificate Authority between GoDaddy and Star(something)…I recommend sticking with the GoDaddy CA on this one.

I hope you are able to take advantage of this offer.  This is a certificate that you can use to sign multiple applications…not just one, so it is definitely a worthwhile investment.  Make sure you timestamp your codesigns!!!

Hope this helps!

| Comments

Yet again, we’ve updated the Silverlight Client for Facebook for the Silverlight 4 release version.  In order to use the updated one, you must follow these instructions:

  • First, uninstall the previous version you have.  This can be done in Add/Remove Programs on Windows or by just deleting the app on Mac.
  • Ensure you have Silverlight 4 installed.  If you are using the development tools and have installed Silverlight 4 developer tools, that’s fine.  If you are not a developer, visit http://microsoft.com/getsilverlight to get the latest Silverlight 4 version (4.0.50401.0).
  • After you have Silverlight 4 installed, visit the app page and install it.

You should be good after this! 

So why so many uninstall/re-installs!?  I thought you had an auto-update mechanism!

We do!  With Silverlight 4 trusted applications, the update mechanism requires that your applications be signed in order to use the auto-update APIs.  We wanted to wait until SL4 released in order to provide a signed version (and our internal signing process didn’t allow signing the beta).  Now that we have a signed version, you’ll be prompted when an update has been installed for the app.  For more details on signing your Silverlight applications see:

Hope this helps!

| Comments

UPDATE: Silverlight 4 is RELEASED!  READ HERE!

Silverlight 4At MIX10, Silverlight 4 released an update, the Silverlight 4 RC (release candidate).  A few things have changed since the beta which was released in November.  If you haven’t read my guide to Silverlight 4 you may want to check that out.  The features still exist, but there are some changes to the implementations of some of the features as well as some new ones.  Please go read the previous post to familiarize yourself with the features.  This post will be complimentary to that and identify new/changed.

First let’s get you going with the tools:

And since sometimes people just want to get going with learning resources here’s my top suggestions:

So here we go, here’s my brain dump of some key areas of what you’ll be seeing in the Silverlight 4 RC.  This is not all-inclusive, but I think a list of some that most will want to know about.

ChangedNew

A quick note about Visual Studio 2010 RC

The Silverlight 4 tools linked above target the RC release of Visual Studio.  There have been 2 patches to Visual Studio 2010 RC since it’s release.  It is recommended that you have these two patches installed prior to installing the Silverlight tools.  Information about these patches (and links to them) is available here.

RichTextBox (the control formerly known as RichTextArea)

Silverlight 4 introduced a new control for enabling editing and display of rich text.  (See original details here for RichTextArea.)  A few things have changed here, one key one being the name: RichTextBox.  This was to be more consistent with WPF and also based on your feedback.  Additional improvements were also enabling the ability to get the XAML that makes up the underlying runs and paragraph of the rich text.  This is helpful for saving off the data and re-hydrating later if desired.  It’s a simple property on the RichTextBox control (assuming the control name is ‘MyRichContent’):

   1: string richText = MyRichContent.Xaml;

In addition to that, there are also some new text selection and position APIs to enable you programmatically select text and/or know where the current position of the text is located.  This is best demonstrated in the ‘Silverlight Notepad’ sample application in the hands-on-lab area where you can see examples of it being used.

^ back to top

WebBrowser control

The beta provided us with a mechanism for hosting HTML content within an out-of-browser application.  This is still available to us, however some APIs have changed.  The HtmlBrush is now called the WebBrowserBrush to be consistent in naming and what it actually does.

You can view a video on using the WebBrowser control here.

^ back to top

Printing API enhancements

The printing API was enhanced to help developers query for the printer page size and the printable area.  Another change was where the ‘document name’ is provided.  It is now required and a part of the Print() method.  Before:

   1: PrintDocument doc = new PrintDocument();
   2: doc.DocumentName = "Sample Document";
   3: doc.Print();

After:

   1: PrintDocument doc = new PrintDocument();
   2: doc.Print("Sample Document");

You can view a video on using the printing APIs here.

^ back to top

Native automation (COM interop)

API changes in the naming of the native integration (COM interop) feature for trusted applications.  Before:

   1: dynamic excel = ComAutomationFactory.CreateObject("Excel.Application");

After:

   1: dynamic excel = AutomationFactory.CreateObject("Excel.Application");

Simple, but will catch you in a recompile :-).  You can view a video on using native integration here.

^ back to top

Language/script support

Silverlight now has extended language support, including Thai and Vietnamese.  Additionally we added support for multiple Indic scripts.  The following Indic scripts are now supported:

ScriptLanguage
BengaliBengali, Assamese, Manipuri
OriyaOriya
MalayalamMalayalam
KannadaKannada
TamilTamil
TeluguTelugu
GujaratiGujarati
GurmukhiPunjabi
DevanagariHindi, Marathi, Sanskirt, Konkani, Kashmiri, Nepali, Sindhi

^ back to top

Networking

In the beta, socket ports were still being restricted in trusted applications.  In this release, the port restriction for socket ranges in trusted applications is removed.

Additionally, the client networking stack (ClientHttp) has been enhanced to enable UploadProgress reporting and caching support.

^ back to top

User consent dialogs (webcam/clipboard/etc.)

We call those dialogs that require user permissions ‘consent dialogs.’  Your users will see these whenever code requires things like requesting device access for webcam/microphone, clipboard access, or quota increase for IsolatedStorage.  In the beta we showed these dialogs always and didn’t have a mechanism for enabling the user to determine if they wanted their consent preference saved.  That has changed in this release.  Consent dialogs now give the user the option to remember the setting which is persisted to their preferences only for that application and is in their control.  Here’s the new consent dialog for clipboard, webcam and full-screen pinning:

Silverlight consent dialog

And if you look at the Silverlight configuration dialog you’ll notice a permissions tab now where these permissions are set for the user, which they can change or delete:

Silverlight permissions dialog

This consent dialog ‘remember my preference’ setting is not available for IsolatedStorage quote increase however.  It doesn’t make sense to enable that really for that scenario.

^ back to top

XAP Signing for trusted applications

We think trusted applications (or elevated privileges applications) will be a widely used feature for this release.  We changed the install prompt dialog for trusted applications.  These are different dialogs than the typical out-of-browser install prompt as we need the user to have more information provided about them.  One key feature of a trusted application is the ability to code-sign the XAP file.  Here’s a trusted application install prompt from an un-signed application:

Windows:

Unsigned trusted application on Windows

Mac OSX:

Unsigned trusted application on OSX

And here is one from a code-signed one:

Windows:

Signed trusted application on Windows

Mac OSX:

Signed trusted application on OSX

Which would you feel more comfortable installing?  Notice that in signed applications your custom icon will show as well (even if you have the icon settings set up, if the app is unsigned they will not show).  The process of code signing is very simple and although I expect the tooling for Silverlight to improve on this, it is as simple as adding a post-build event task (or a task for automated builds) that uses the signtool.exe (installed with Visual Studio) to sign the XAP.  Here’s my post-build event task:

   1: "%ProgramFiles%\Microsoft SDKs\Windows\v7.0A\Bin\signtool.exe" sign /v 
   2:     /f c:\users\timheuer\documents\authenticode\timheuer.pfx 
   3:     /p "MYPASSWORD" 
   4:     /t TIMESTAMP_URI_FROM_PROVIDER $(TargetName).xap

The PFX file is an exported certificate with my private key and password protected.  You can acquire code-signing certificates (normal Authenticode ones) from providers.  We were thankful to get assistance in testing this feature from the following providers who can provide you code-signing certificates for your organization:

All of the above provide Authenticode code-signing certificates and are trusted certificate authorities (CA) on Windows.  A trusted CA means that their root certificates are already a part of Windows verification.  The process of obtaining one is not instant so plan ahead.  There is a specific organizational verification process that occurs which may require documentation of proof of the organization and a few phone calls.  Once you have these certificates you will be on your way to providing even more trusted applications to your users.

NOTE: Thawte code-signing certificate requests should be made from a Windows XP machine as their current process does not support Windows Vista or Windows 7.  If you use Vista/7 you will not be able to export to a PFX file for automated build or to have your certificate stored on other machines.  Read each instructions carefully.

You can also sign your XAP using self-signed certificates.  If you do so, it is likely that you are not a trusted CA on machines and would have to instruct your users further.  In my opinion, it is better to acquire a trusted CA cert for external applications.  Take a look at Jeff Wilcox’s epic post on Code Signing 101.

A special note on trusted applications…please read!  If you want to take advantage of using the update features of Silverlight for your application (aka CheckAndDownloadUpdateAsync), then your application must be signedIf you do not sign your XAP for a trusted application it cannot auto-update.  Self-signed works here to, but don’t get your application in a state where it cannot be updated automatically!

You can view a video walk-through of XAP signing here.

^ back to top

Custom window chrome

One of the more requested features of trusted applications is the ability to customize the ‘chrome’ around the window.  The chrome area refers to the standard OS-specific border and title bar that a typical out-of-browser application will receive.  In this release we give you the ability to customize this for your users.  The Visual Studio tools also build in the capability to make this easier for you:

Window Style setting options

You can see there are a few options to choose from for window types.  Right now we do not support transparent windows or irregular shapes but are aware of the desire to have these.  Here’s an example of the Facebook client before:

Silverlight Facebook Client (beta)

and with custom window chrome:

Silverlight Facebook Client custom window

You’ll notice that in the custom window mode that since you don’t have the OS-specific title bar with minimize/maximize/close that you’ll be responsible for doing that.  That also includes handling the window moving and resizing events.  We enable APIs for you to do all of this easily. 

You can view a video on customizing window chrome and handling resizing and moving here.

^ back to top

Pinned full-screen mode

Are you a developer with multiple monitor setup?  I’m jealous.  If you’ve used silverlight you’ve no doubt run into a situation where you’ve put something in full-screen on one monitor and anticipated being able to work on other stuff in the other monitor.  Maybe you’re watching a Netflix movie while working?  You’ve likely experienced the issue that the full-screen mode goes back to regular when activity occurs in the second monitor.

We’ve changed that to enable the developer to prompt for permission to 'pin’ the Silverlight application to the monitor.  This will prompt the consent dialog option (with preference remembering) to get the user’s permission.  The code is extremely simple:

   1: App.Current.Host.Content.FullScreenOptions = System.Windows.Interop.FullScreenOptions.StaysFullScreenWhenUnfocused;

Once that is implemented, the full-screen application will remain pinned until the user hits ESC key or until you change the IsFullScreen mode in the code for them.

You can view a video on using the full-screen pinning mode here.

^ back to top

ContextMenu control

In the beta we introduced the right-click event handling capabilities.  In most cases this would be used by developers to implement context menus.  The Silverlight Toolkit for March 2010 release now provides a ContextMenu control for you to use and wire-up for this event.  It’s similar to the one Jesse Bishop created for the beta, so if you’ve used that it should be familiar.  It also supports ICommand too!

You can get the ContextMenu control and other great controls by ensuring you download and install the Silverlight Toolkit March 2010 release.

^ back to top

SLLauncher silent installs

One of the features we added in this release was using the sllauncher.exe (which is the program that assists in out-of-browser applications) to provide silent install capabilities for your applications.  The primary scenario here would be something like CD-based installation situations.  Using a command like this:

   1: "%ProgramFiles%\Microsoft Silverlight\sllauncher.exe"  
   2:     /install:"D:\deploy\demoapp.xap"  
   3:     /origin:"http://foocompany.com/apps/ClientBin/demoapp.xap"  
   4:     /shortcut:desktop+startmenu  
   5:     /overwrite 

would enable you to deploy an application in this type of a situation.  Setting the origin flag here enables the application to determine where it would get future updates from if CheckAndDownloadUpdateAsync methods are called within the application.

^ back to top

WCF RIA Services Toolkit

If you read above you’ll know that installing the Silverlight 4 Tools for Visual Studio also automatically installs the WCF RIA Services framework for you.  This release the RIA Services team also has a toolkit of their own.  After installing the RIA Services Toolkit you’ll get:

  • LinqToSql DomainService
  • SOAP endpoint – enabling exposing a SOAP endpoint for your DomainService
  • JSON endpoint – enabling exposing a JSON endpoint for your DomainService
  • ASP.NET DomainDataSource – enabling your ASP.NET application to talk to your DomainService

This is a separate install that you must complete.  For more details on this toolkit, visit Deepesh’s blog.

If you aren’t familiar with WCF RIA Services, you can view an introductory video here.

^ back to top

Summary

It’s been a fast pace since getting the Silverlight 4 beta in your hands in November.  We’ve had a lot of work to do to finish things up and implement some new key features.  We are very excited about this release of Silverlight 4 for developers and look forward to seeing the great applications you build with it!

Be sure to visit the MIX10 site for video recordings of various Silverlight-related presentations as the event is happening and as reference later on!  I really encourage you to view the keynote to see some new consumer-facing application experiences built on Silverlight, like eBay, Associated Press (Windows Phone 7)

Hope this helps!  Be sure to subscribe here via RSS or email and if you’re on Twitter you can follow me there as well for Silverlight updates/resources


This work is licensed under a Creative Commons Attribution By license.