| Comments

Wow, what a week.  I have to say even as employees of Microsoft, we get surprised when we go to our conferences and see some of the bigger announcements.  There are things that are being worked on that are new or just in different divisions that we’re not focused on.  This past week at the Build 2015 conference was an example of that for me.  Lots of good stuff for developers from client to server!

Universal Windows Platform

At Build this year we introduced the Universal Windows Platform v10 with a set of new APIs and unified features for all Windows devices.  Perhaps the best vision of this is the Day 2 Keynote where Kevin Gallo walked through an example of this and a single app running on tablet, phone, Surface Hub, HoloLens, etc. 

Visit the keynote and watch the whole thing or if you want to jump to the start of this portion it starts at about 23 minutes in.  A really well done, compelling demonstration of the Universal Windows Platform.

XAML Session Recap

For the XAML developer on Windows, there was a lot of goodness shown from my team.  We’ve been working hard on a lot of internals and new API exposure for the Universal Windows Platform.  Our team had some representation in some deep-dive sessions from Build and the recordings are all now available…here’s a list for you to queue up:

One of the things I was really happy to have is part of the Office team come and talk about how they build Office on the same platform we ask you to build apps on.  It is good insight into a large application with lots of legacy and goals that might not be typical of smaller apps or smaller ecosystems.  A big focus for XAML this release was performance given that customers like Office and the Windows shells themselves leveraging XAML for their UI.

I hope that if you are a XAML developer you take some time to look at what new features are available in the Universal Windows Platform for you in Windows 10.

Get the goods!

If you want to get started playing around, the best way is to be a part of the Windows Insiders program.  Everything you need to get started you can find here https://dev.windows.com/en-US/windows-10-for-developers.  You’ll want to join the Insiders program, then download the Visual Studio tools and get started creating/migrating apps!  To help get you started after that here are some helpful links:

Give us feedback!

As you play around with the bits, please continue to give us feedback.  The best way is to be involved in the conversation on the forums.  Ask questions there, get help from the community, share learnings, etc.  Secondarily the Windows Insider Feedback tool (an app that is installed on Windows already for you as ‘Windows Feedback’) is available for you to give direct feedback to the teams.  Please choose categories carefully so that the feedback gets directly to the right team quickly. 

Thanks for helping make the Windows Platform better.  I hope these direct links help you jumpstart your learning!

| Comments

Recently I embarked on porting the TagLib# library to a Portable Class Library (PCL).  In my efforts I noted some frustration I had of the “convert and compile” flow to find issues.  Well, turns out I didn’t have to do that much pain as pointed out by Daniel in the comments!  The .NET team has released a tool to help out us developers called the API Portability Analyzer (currently in Alpha).  This tool basically looks at any existing .NET assembly and gives you a report to help you see where the APIs used are supported in the various .NET profiles available.

The tool is a single command-line exe and is as simple as launching:

ApiPort.exe path-to-your-assembly-file.dll

I recommend putting this in your path somewhere so you don’t have to remember the full path to launch.  The output from the console tells you very little and only really about what you it is doing:

Microsoft (R) API Portability Analyzer version 1.0 (alpha)
Copyright (C) Microsoft Corporation. All rights reserved.

To learn more about how this tool works, including the data we are collecting, go here - http://go.microsoft.com/fwlink/?LinkId=397652

Identifying assemblies to scan. Done in 0.01s.
Detecting assembly references. Processed 1/1 files.Done in 0.23s.
Sending data to service. Done in 2.88s.
Computing report. Processed 508 items.Done in 0.02s.
Writing report. Done in 0.17s.

Replaced output file "c:\ApiPortAnalysis.xlsx"

You may notice that the tool says ‘sending’ and yes, it is communicating with a public service.  The team notes this in the download:

NOTE: During the process of identifying the .NET APIs used by a binary Microsoft collects the list of .NET APIs used by the user submitted binaries. Microsoft also collects the names of various user created APIs. The tool does not collect the binary code, only names of APIs are collected. Microsoft will also collect assembly information such as assembly references for the binary & the Target Framework Moniker (TFM).

The real value is in the output data conveniently formatted into a pre-filterable Excel document.  The process was fairly fast for me, but I suspect might take longer for larger libraries (duh).  An example of the output is like the one here directly showing the TagLib# data that I used above.

If you read my previous post you will see that the areas I had frustrations about are clearly identified in the Unsupported columns for my target platform.  The tool attempts to recommend some alternatives when it can.  I can imagine this gets better over time as the recommendations for TagLib# were only two, whereas it should have provided recommendations for XmlDocument/XmlElement/etc. to the XLINQ equivalent areas.

In the end though, this is a helpful tool for those looking to convert.  I wish I had known about it in advance, but now that I know it is in my toolbox and my PATH!

Hope this helps!

| Comments

A long while back I had written a quick sample when Silverlight introduced drag-and-drop into the framework.  Then I decided to show dragging MP3 files into a Silverlight app and reading the metadata and album art.  In order to accomplish this I had to read into the ID3 data from a Silverlight library.  I found a few libraries but settled on TagLib# to do the job.  I had to modify it a bit to get it working in Silverlight as the .NET profile wasn’t the same.  Recently a surge of people have been emailing me for the code.  I spent time searching and apparently I didn’t think the TagLib# modifications were that important because I never saved them anywhere!  A conversation started on Twitter and I decided to devote some “20% time” to making these modifications and take it a step further and make it into a Portable Class Library (PCL).  Here’s my journey…

Deciding to Fork

My first task was finding the source of truth for TagLib#.  The main link on the Novell developer site was broken and stale.  I found it on GitHub and started looking around.  It really hadn’t been updated in a long while (after all, it really didn’t need to be fore core .NET framework) and the project is very stale.  There is no open issues list on GitHub as you have to use Bugzilla, but that didn’t even look like it was getting much attention.  I emailed the maintainer listed in the authors file in the repository and he indicated he’s not really the maintainer.  This felt like a project kind of fizzling down (if not fizzled already).

In looking at the tests, the project structure, and taking into account that I may want to do some things different, I made the decision to fork rather than clone.  I’m not totally married to the decision but I don’t think anyone is keeping the lights on to take a pull request either though.  I forked the code and started with new projects and using Visual Studio 2013 as my tool of choice.

Using Shared Projects

At first I thought that I would be doing perhaps a few different flavors, portable and full .NET framework.  Because I thought I would I decided to use the new Shared Project system in Visual Studio 2013 and the new Shared Project Reference Manager VS extension that allows me to add references from any project to shared code easily.  This gives me the flexibility for the future and sets my project system up in advance.  You’ll see in the end I haven’t actually needed to take that step and perhaps won’t even need the Shared Project anymore, but for now I’m keeping it as it does me no harm.

First Compile

Once I moved the code over and set my target profile for PCL, I hit build.  Whoa.  About 140 compile errors.  Immediately I thought that I didn’t want to spend the time.  I took a look at the issues and quickly realized that the base code had, in fact, changed a bit from when I messed with it in Silverlight.  I started making a list of the things that weren’t compiling as I was targeting .NET 4.5, Silverlight 5, Windows 8+, Windows Phone 8+, and iOS/Android (Xamarin).  The biggest errors came from the fact that the library was still using XmlDocument and hadn’t moved to XLinq.  Beyond that there were things like Serializable, ICloneable, ComVisible and File IO that weren’t going to work.  I got really frustrated quickly and about gave up.

Working at Microsoft I am fortunate to have access to try more things and indeed I reached out to some folks for help.  I was able to get some things working continued with XmlDocument, but it didn’t feel right and starting to think about releasing this updated library I just realized this wasn’t going to work.  I remained frustrated.

Helpful Friends

Sometimes when you are frustrated you just want to vent to the world.  We call that Twitter these days.  I was pulling some hair out and posted a comment, which was quickly replied by a member of the .NET team with a bit of a touché comment. 

I chuckled but I also knew that David and others were going to be the key to helping me find the fastest path here.  I started emails with the PCL team, including David and Daniel, who are incredibly knowledgeable and responsive.  I finally got most working and then my colleague and I started chatting about my frustrations.  He worked on XLinq for a bit and basically told me to suck it up and do the conversions and that it wasn’t that bad.  We walked through a few of the scenarios and indeed it really ended up all being isolated into one area that I could quickly scan through.  I could now remove my dependency on XmlDocument and have no other dependencies for this portable library.

Hooray for helpful people!  Even when you vent, the good peeps will still help out!

Changes to TagLib# for portability

After the full conversion, a few things remain.  Right now I have #ifdef’d out come of the interfaces and attributes that weren’t working.  Once I get to a point of porting all the tests over, I’ll decide if they are even needed.  Perhaps the biggest change though for users of this lib will be the removal of the default string path of file access.  In discussing with some folks, I could have tried to make a portable storage layer work, but it started to make less sense quickly to do that in the library and leave that simple task to the app developer.  This provides flexibility for the app to do what they want without the library trying to work around how different platforms do their file IO routines.  What that means is that the default way of reading a file’s tags changes from:

var tagFile = File.Create("ironlionzion.mp3");
var tags = tagFile.GetTag(TagTypes.Id3v2);
string album = tags.Album;


' file is a StorageFile
var fileStream = await file.OpenStreamForReadAsync();
var tagFile = File.Create(new StreamFileAbstraction(file.Name, fileStream, fileStream));
var tags = tagFile.GetTag(TagTypes.Id3v2);
string album = tags.Album;

in a simple case.  Yes, you as the app author have to write a bit more code, but it puts you in control of ensuring the file location you are reading.  You can see here that I did add my StreamFileAbstraction class to my fork by default, which was the key in the Silverlight port and is actually the key for WinRT as well.  Any app developer can create their own IFileAbstraction implementation and substitute it in the ctor of the create functions and be ready to read.  I actually did this in the test project to re-implement a LocalFileAbstraction for test purposes and used the System.IO.File classes to achieve that, which are available when running VS unit tests.


What started out as a frustrating exercise turned out to be helpful for me to better understand PCLs and hopefully add value to those who have been asking for this.  As mentioned, this isn’t fully tested and still a ways to go, so if you use it please log bugs (and help fix them) to complete the implementation.  I won’t be working on this full time of course, but do hope to get the test suite ported over as well.  Here are some relevant links:

Hope this helps!

| 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.


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

Silverlight 5 is finally released!  Congratulations to the team for getting through some of the toughest parts of finishing a product and validating with customers.  It’s been a pretty crazy year for the Silverlight team and this is a really good release for the product bringing some solid features to the platform for folks to leverage in building their apps.

In addition to the platform having a release, I was really pleased to see an update to the Silverlight Toolkit, which has been one of the most popular things almost every Silverlight developer/application uses.  If you didn’t know where to get things, here’s some links for you:

Rather than enumerate all the good features that were finished from the RC/Beta, you should head on over to listen/watch Pete Brown’s presentation on the Silverlight 5 release overview.  He also has a post about the release enumerating in short form (with links to tutorials for some of the key features) on his blog.

What I think is really cool is also the amount of effort put into the Silverlight Toolkit for this release.  The one large thing of note is the extensions to enhance your 3D development experience in Silverlight 5.  David Catuhe has a post outlining in great detail some of the 3D extensions included in the toolkit.  You should really go check out his post.  Scrolling to the bottom I was really surprised/impressed to see a set of 3D samples included to help you understand how to use this feature:

  • Bloom – uses the Content Pipeline and post-processing effects
  • CustomModelEffect
  • Generated geometry – how 3D models generated by code
  • Particles – c’mon, who doesn’t like a particle generator!
  • Platformer - while not 3D it appears, it is a complete game with levels
  • 3D Animation
  • Skinning – shows skinning a character using the content pipeline

I mean, wow, great stuff David! 

I hope you all enjoy the release of Silverlight 5 and kudos to the team for getting it out the door. Go download the bits and start building awesome stuff.