Category Archives: .net

Developing for the Windows Runtime: a few more notes from the field

I have been poking around in the code for my Windows Runtime ITWriting.com reader, which is based on this MSDN sample. The list of posts looks like this:

image

Not bad, but that block showing the date of each post is based on Windows Team Blog page, which is nothing to do with me. What would it take to modify the design?

The problem with sample code is that when you copy and paste you do not really know how the code works, and sometimes issues are hidden. The MSDN article, while it does a good job explaining most parts of the app, does not explain how the date block is put together. A few observations then from my efforts to modify this.

Most of the code for this date block is in the ResourceDictionary element in App.xaml, which means it can easily be reused on multiple pages. The code is a ControlTemplate element, which means it defines a custom control. This is then referenced within a DataTemplate element on the pages where it appears. The DataTemplate defines how the bound data appears in the list.

Reading a block of XAML and trying to visualise how it will render is not much easier than viewing a photo in a binary editor. However, you cannot view App.xaml in a visual designer, since it is not a visual page. The only solution I could think of was to copy the ControlTemplate out of App.xaml into a page where I could see the design, tweaking it, and then copying it back.

I started a new project in Blend, and copied the Canvas code from the DateBlockTemplate, and replaced the data bound values with hard-coded examples. So far so good: I could now tweak the design.

image

My design skills are rubbish so I ended up with a simpler layout. In my adaption, the month and day appear on one line, as in “Aug 26”.

This led me to another problem. In the sample, the month and day are bound as separate fields, for example:

<TextBlock.Text>
<Binding Path="PubDate" Converter="{StaticResource dateConverter}" ConverterParameter="month"  />
</TextBlock.Text>

How could I concatenate the two bindings to appear in one TextBlock? In Windows Presentation Foundation (WPF) you can do this with the MultiBinding class, but this did not seem to work in WinRT XAML. Rather than go further down that route, I decided to amend the DateConverter class which is also part of the sample, to add a conversion that returns both the month and the day.

DateConverter.cs users the new DateTimeFormatter class.  The documentation explains that this takes a “format template string” but does not offer a reference for constructing formats. I experimented and ended up with:

DateTimeFormatter dateFormatter = new DateTimeFormatter("{month.abbreviated(3)} {day.integer(2)}");

which turns out to work.

Now my list of posts looks like this:

image

Not as stylish as before, but at least it is different.

The Windows Runtime App Certification Kit: not too good detecting crashes and hangs

Now that I have a lovely ITWriting.com App I thought I should check out whether it is ready to fly.

I therefore ran the App Certification Kit that installs with Visual Studio 2012.

image

The tool asks you to select an installed app and then exercises it. I saw my app open, though I did not see it get beyond the first screen.

image

Eventually – bad news:

image

However, there is only one thing wrong with it:

image

Yes, the version installed is the debug build. I can fix this simply by rebuilding in release configuration.

What does the Kit test? Here is the list:

  • Crashes and hangs test
  • App manifest compliance test
  • Windows security features test
  • Supported API test
  • Performance test
  • App manifest resources test
  • Debug configuration test
  • File encoding
  • Direct3D feature level support
  • App Capabilities test
  • Windows Runtime metadata validation

That sounds most impressive and makes a great list for you to show to your customer.

I am sceptical though. If the app was not exercised beyond the opening screen, might it not be a bit buggy after all?

I inserted the following line of code into the the Click event handler for reading a blog:

int iCrash = 1 / string.Empty.Length;

I then rebuilt the app in release mode and ran the App Certification Test. Great news!

image

and specifically:

image

Thanks though to my umm, bug-unfix, the app crashes whenever I click to read a blog.

I mention this not to poke fun at the App Certification Kit, but to observe that it does not do a good job of automatically detecting crashes and hangs.

The implication is that the human testers are the ones who will do this before an app is admitted to the store. I think they would find my obvious bug; but how much time will they have to test every feature of an app?

Developing a Windows Runtime app: some observations

What would it take to create a Windows 8 Modern UI content reader for this site? Just for fun, I built a simple one; or rather, I slightly adapted Microsoft’s Metro style blog reader tutorial.

The app only has four screens (or pages) but despite its simplicity I found the tutorial somewhat fiddly. Getting the data from the WordPress RSS feed is simple, thanks to the Windows.Web.Syndication namespace which is part of .NET Framework 4.5. Most of the work is in the user interface, which means switching between XAML and C#. Of course as a developer I would rather work in C#.

Further, the Visual Studio editor for C# is better than the editor for XAML. In C# I can easily navigate the code using Go to Definition, Find all References, and so on.  In XAML it takes longer to find things like referenced styles and resources. Plus XAML is XML, which I find harder to read than an elegant language like C#. Even commenting out a line is more hassle in XML.

I did not like the colours used by the tutorial for the list of posts in SplitePage.xaml. It took me a while to work out what to change. Was the colour defined in a resource, or in a template, or in a style, or directly coded as an attribute of the relevant TextBlock object?

Of course you can open the XAML in Blend if you prefer, the designer-oriented tool that comes with Visual Studio 2012. Blend is more complex than the Visual Studio XAML editor, but may be better once you have figured out how it works.

The amount of work involved in making your app well-behaved is proportionately larger if your app is essentially very simple. You have to deal with different layouts for different screen sizes and orientation, as well as the small Snapped layout. You also have to consider what happens if your app is suspended and resumed.

The above means that despite the apparent simplicity of a Modern UI interface, with its chunky buttons, there is more to consider than with, say, a Windows Forms application whose window is never rotated and over which you have full control.

Still, I was pleased with my app which has reasonable functionality based on a small amount of work.

Visual Studio 2012 is impressive, though I did experience some screen corruption after switching back and forth between the Metro and Visual Studio environments for debugging. Restarting Visual Studio fixes it. Using the simulator seems more robust in this respect.

image

The App Bar

One thing though. If you squint at the above screenshot, you will see that I have put a Read button to the right of the post title. Clicking or tapping this opens the post in a embedded web browser view that is nearly full-screen. However, this Read button is not included in the tutorial, which says:

On the split page, we must provide a way for the user to go to the detail view of the blog post. We could put a button somewhere on the page, but that would distract from the core app experience, which is reading. Instead, we put the button in an app bar that’s hidden until the user needs it.

This may in fact be an excuse to include an App Bar in the tutorial; but I disagree with it. With the App Bar, the user has to right-click or swipe down to display the App Bar, and then click or tap the View Web Page button.

image

That is two actions rather than one. Is it really better than having a small button in the UI?

It seems to me that tucking things into the App Bar is fine in cases where there is real merit in an immersive experience, such as in the web browser, but less compelling when you already have a screen with a back button and a scrollable list. I was also concerned that users might not realise they needed to display the App Bar in order to use the app properly.

Let the design debate continue.

Design-centric

Microsoft’s Modern UI continues a trend which began with Windows Presentation Foundation (the first incarnation of XAML), which is to make a platform richer for UI designers and more challenging for developers who lack design skills. Nothing wrong with that; but if you remember how easy it was to snap together an app in Visual Basic 3.0, you may feel that something has been lost.

I guess that recognition of that fact was one of the motivations behind Visual Studio LightSwitch, in which you define the data and business rules, but the screens are generated for you. LightSwitch has complexities of its own though.

Installing Kodak All-in-One Printer driver on Windows 8

I have been busy upgrading computers to Windows 8 now that the RTM is available. So far so good, though I ran into a problem with a printer which, oddly, worked fine in the Windows 8 Release Preview.

The printer is a Kodak All-on-one. Kodak has a universal installer for all its all-in-one printers. When I ran this, I got a message that .NET Framework 2.0 was needed and would be updated.

image

It would then try to install .NET 2.0, but fail.

Easy, I thought, just install .NET first. In Windows 8, you do this through Control Panel – Programs – Turn Windows features on or off.

image

I installed .NET Framework 3.5, which includes 2.0, and re-tried the Kodak printer install. Same message, same error.

I also tried running the installer in compatibility mode for Windows 7 and Windows XP. No go.

Time for some serious troubleshooting. I presumed that if I could figure out what the installer was looking for when it failed to detect .NET Framework 2.0, I could fix it.

First, I checked the official instructions for detecting .NET in an installer. This was already correct.

Next, I downloaded Process Monitor to see if I could spot the registry query or file search the installer was making. I noticed that aio_install.exe, the Kodak installer, unpacks a setup into a temporary location and runs from there. I copied the extracted files and ran the setup. Using Process Monitor, I discovered a registry query to HKCU\Software\Kodak\BootStrapInstallStatus and the REG_DWORD key InstallStatusKeyForDotnet. This was currently set to 1. In a spirit of experimentation I changed the 1 to a zero.

image

Next I re-ran setup. It worked perfectly.

image

I still do not know why that registry key was set, but I am not inclined to pursue it further. Possibly if .NET Framework 2.0 is already installed before you run the Kodak installer for the first time, the problem does not arise.

If you encounter this problem though, I suspect the following two steps will be sufficient:

1. Install .NET Framework 3.5 using Control Panel.

2. If installing the printer driver fails, check for the registry key HKCU\Software\Kodak\BootStrapInstallStatus\InstallStatusKeyForDotnet and set it to 0.

Embarcadero preparing Delphi, C++ Builder XE3 release

Embarcadero has announced a world tour to promote its forthcoming XE3 development suite.

image

But what is in it? No details yet, but a few clues:

  • Windows 8 “look and functionality” for VCL and FireMonkey apps
  • A new edition of the FireMonkey cross-platform framework, called FM2
  • A new tool called HTML5 Builder.

There are a few more clues in a leaked PDF document on what is new in Delphi and C++ Builder XE3. This refers to “full support of the Windows 8 Metro user interface” and describes new project wizards for “VCL Metro Desktop Application” and “FireMonkey Metro Desktop Application”.

Since “Desktop” normally means non-Metro in a Windows 8 context, this phrase is puzzling, making me wonder if the tool will build apps that look and feel like Windows Runtime apps, but really are not. That would be unsatisfactory, because features like Contracts and Live Tiles only work with real Windows Runtime apps. Or is Embarcadero is planning full Metro support and is distinguishing from mobile apps.

There are also changes in FireMonkey to add support for Actions, Anchors, and Layout managers. Sensor and gesture support will be important for Windows 8 apps.

Finally there will be a SQLite database driver in XE3.

All the above, save the tour announcement, is unofficial and may be wrong or subject to change. I doubt the Metro name will feature so prominently in the eventual release, for example. And Metropolis?

Update

Looking at the wording here seems to confirm suspicions that Delphi and C++ Builder are not getting true Windows Runtime support:

  • Create Delphi, C++Builder and Prism applications with Windows 8 styling and functionality
  • Create HTML5 web apps and mobile apps for Android, iOS and more with new HTML5 Builder
  • Build Windows 8 apps with WinRT using Prism XE3 in RAD Studio

Otherwise, why would Embarcadero state “WinRT” for Prism but not for Delphi and C++ Builder?

Using Windows Runtime (WinRT) APIs from desktop applications

After trying out Windows 8 notifications from a Windows Forms application, I did a bit of research into using the Windows Runtime (WinRT) API from desktop applications.

It turns out that this is something Microsoft planned for:

Desktop apps should for the most part be able to use WinRT. This is an area where we should have more information moving forward.

says Microsoft’s David Lamb, in Developer Support. He was answering a question about the Proximity APIs.

How do you do it? In C/C++, according to Steve Harne:

For this to build, you’ll need to set the following compiler switches in the the C++ Win32 Console wizard generated project:

C/C++ / General Settings
    Enable Windows Runtime Extensions (/ZX)
    Additional #Using Directories (/AI) -> set this to "C:\Program Files (x86)\Windows Kits\8.0\Windows Metadata" (modify as per your installation)

C/C++ / Code Generation
    Disable Minimal Rebuild (/Gm-)  -> this is not compatible with /ZX

In .NET applications you can set a reference to Windows.winmd. This is a WinRT metadata file, which you can browse in the Visual Studio object browser.

image

You even get a short summary describing each class and class member.

Note that as Microsoft’s Larry Osterman explains here:

there is absolutely no (zero) il in the windows.winmd file – it’s a metadata-only assembly. This is important because winmd files only describe structure, they don’t contain code (note that the C# compiler can produce hybrid winmd files that also contain some code, this was to support certain C# scenarios)

While a lot of stuff works, there will be WinRT API calls that make no sense other than for real WinRT apps. It is also worth noting that all of this is specific to Windows 8 (and higher, I presume). Since most desktop apps will need to be compatible at least with Windows 7, this requires some care. Lamb also says:

WinRT APIs may be tied to Metro style apps, Desktop apps or potentially available to both. The documentation will list which environments (Desktop, Metro style or both) a given API works in.

and in fact you can see this in the documentation. For example, the docs for the ToastNotification class states:

Applies to: Metro style apps | desktop apps

image

whereas if you look at the ContactPickerUI class, it says:

Applies to: Metro style apps only

For those APIs where desktop use is supported, you can go right ahead.

Notifications in Windows 8: how to display new-style toast from a desktop app

This post was prompted by the discussion over the fact that Windows 8 boots into the Start screen, and cannot apparently be modified to boot into the Desktop (though no doubt someone will find a way).

What if, I wondered, you put a desktop app into your startup folder so it runs automatically on boot? The answer: it runs on the desktop, but you will not see it until you click or tap into the desktop from the start screen. This is different behaviour from actually starting a desktop app from the start screen, which switches you to the desktop.

So what if that desktop app has something important to tell you? The answer: you will not see it until you switch to the desktop.

To demonstrate this, I wrote a Windows Forms app that displays a MessageBox alert after a 5 second delay. I ran the app, activated the alert, and switched to a Windows Runtime Metro app. When the alert fired, I heard a little ding, but saw no message. Only after switching to the desktop did I see the message.

image

To be fair, you might not see this even if you were working in the desktop, since Windows has complex (and sometimes unpredictable) rules about when apps are allowed to come to the foreground. Even calling the Activate method, which gives your window the focus, may do no more than flash the icon on the taskbar.

Windows 8 has a new-style “toast” notification mechanism that works across both desktop and Windows runtime. I got this working in my Windows Forms app.

image

So how do you do this? For some background, see Jim O’Neil’s series of posts which start here. However, I mostly used code from the sample Sending toast notifications from desktop apps. This is a WPF application, but I got the code to work in my Windows Forms application. Note that to reference Windows.UI.Notifications you have to add a reference to:

C:\Program Files (x86)\Windows Kits\8.0\References\CommonConfiguration\Neutral\Windows.winmd

Update: in the release version of Visual Studio 2012 the way you reference winmd has changed. See this MSDN article and the section called Core Subgroup; however at the time of writing the method described there does not quite work. Instead, proceed as follows. First right-click the project in the Solution Explorer and choose Unload Project. Then right-click the project again and choose Edit [project].csproj. Add the following to the project file after the other Reference elements:

<Reference Include="Windows" />

then save and close the editor. Finally, right-click the project name again and choose Reload project. Do not add the suggested TargetPlatformVersion element, since if you do the project will not compile.

You also need the Windows 7 API code pack which is here.

Here is a quick summary though. In order to display a toast notification, you first need a shortcut to your app on the Start menu. In addition, the shortcut has to have an AppUserModeId, which you can set in code.

Once that is sorted, you can use the ToastNotificationManager class – for which you need that reference to Windows.UI.Notifications – and retrieve a standard XML template for the notification. You can add event handlers to the notification, so you can respond if the user clicks it. Then call:

ToastNotificationManager.CreateToastNotifier(APP_ID).Show(toast);

to actually show the notification.

Note that your event handlers will not fire on the UI thread, so you need to use thread-safe methods if you want to interact with controls on your form.

It is all somewhat laborious, but on the plus side you get notifications which are better than the old notification area toast, and much better than MessageBox.

Note that this is one bit of code applications will only have if they are modified to work on Windows 8. That is worth noting if you have an application in which notifications play an important role.

image

Office 365 for developers: Getting started with Microsoft Napa

One key aspect of Microsoft’s forthcoming Office 2013 is its support for a new app model. The idea is that rather than building local add-ins for desktop Office, you will build web applications that live in one of four places:

  • In SharePoint
  • Within an Excel document
  • Within a Task pane in Excel or Word
  • Adjacent to an email in Outlook
Advertisement

If you have been following Office development for a while, it is hard to supress an initial reaction of “oh no, not another development model for Office.” After all, we have had Basic macros, Visual Basic for Applications, COM Add-ins, Visual Studio Tools for Office, and in the case of Exchange, other APIs such as MAPI and Exchange Client Extensions. Further, most of this stuff still works, which is a mixed blessing as the the whole thing gets more bloated and confusing.

Even so, I can see the sense of the new Apps for Office. One key advantage is that they work in Office Web Apps as well as in the desktop applications. They are also easier to deploy and secure, since they require no executable files on the client, are sandboxed, and only interact with the local document via a JavaScript library. That may not always be sufficient of course, in which case you can stick with one of the older extension models (personally I still find VBA useful), but where it is sufficient, this strikes me as a good approach.

That said, there are plenty of gaps in the list of supported app types:

Application Supported types
Excel 2013 Preview Task pane, Content
Excel Web App Preview Content
Word 2013 Preview Task Pane
Outlook 2013 Preview Mail
Outlook Web App Preview Mail
Project Professional 2013 Preview Task Pane

It would be good to see content apps supported more widely. Still, it is a start.

Office program manager Brian Jones has an excellent post on the background to apps for Office and SharePoint, which inspired me to sign up for a developer preview. Microsoft had already created an Office 365 preview account for me, but this other one is the real deal: you get to administer an entire test organization, complete with SharePoint, Exchange 2013, and all the Office 2013 preview apps.

After sign-up, it took a few minutes to provision, and then I was able to add the Napa development tools to the site. This is itself a cloud app. It is easy to get started: choose the type of app you want and you are in.

image

Napa is a cloud IDE, essentially a code editor with some syntax highlighting and code completion.

image

The real joy, if you have ever done SharePoint development, is how easy it is to deploy. Just click the Run button.

image

Once installed, you can launch the app with a click, provided you have enabled pop-ups on the site. An Excel content app works in the same way, but opens up the app running in an Excel Web App spreadsheet.

I am sure seasoned Microsoft platform developers will find Napa rather limiting, but there is also an Open in Visual Studio button, and all going well you should be able to do most of your coding in Visual Studio, upload back to Napa, and still get the benefit of easy test and deploy.

image

If you are pleased with your app you can easily offer it for sale by publishing to the Office store:

image

The implications for Office 365 are rather profound. It is evolving into a true extensible cloud platform, where businesses can add apps and deploy to their users using an app store model.

That said, you can argue that Microsoft is playing catch-up here. For example, Salesforce.com has had Force.com for years, and I know from visiting the huge vendor exhibitions at events like Dreamforce how strong that marketplace has turned out to be. Salesforce has also enabled its users to build apps in the cloud for many years now.

All true; but Microsoft’s approach does have the advantage of continuity. As I mentioned above, the old stuff still works, so customers can move at their own pace towards a cloud-based platform.

For more information, I recommend this overview.

Microsoft opens up Office 365 and Azure single sign-on for developers

Remember Passport and Hailstorm? Well here it comes again, kind-of, but in corporate-friendly form. It is called Windows Azure Active Directory, and is currently in Developer Preview:

Windows Azure AD provides software developers with a user centric cloud service for storing and managing user identities, coupled with a world class, secure & standards based authorization and authentication system. With support for .Net, Java, & PHP it can be used on all the major devices and platforms software developers use today.

The clearest explanation I can find is in John Shewchuk’s post on Reimagining Active Directory for the Social Enterprise. He makes the point that every Office 365 user is signing on to Microsoft’s cloud-hosted Active Directory. And here is the big deal:

The Windows Azure Active Directory SSO capability can be used by any application, from Microsoft or a third party running on any technology base. So if a user is signed in to one application and moves to another, the user doesn’t have to sign in again.

Organisations with on-premise Active Directory can use federation and synchronisation (Shewchuk fudges the distinction) so that you can get a single point of management as well as single sign-on between cloud and internal network.

Is this really new? I posted about Single sign-on from Active Directory to Windows Azure back in December 2010, and in fact I even got this working using my own on-premise AD to sign into an Azure app.

It seems though that Microsoft is working on both simplifying the programming, and adding integration with social networks. Here is where it gets to sound even more Hailstorm-like:

… we will look at enhancements to Windows Azure Active Directory and the programming model that enable developers to more easily create applications that work with consumer-oriented identities, integrate with social networks, and incorporate information in the directory into new application experiences.

Hailstorm failed because few trusted Microsoft to be the identity provider for the Internet. It is curious though: I am not sure that Facebook or Google are more well-trusted today, yet they are both used as identity providers by many third parties, especially Facebook. Spotify, for example, requires Facebook sign-in to create an account (an ugly feature).

Perhaps the key lesson is this. Once people are already hooked into a service, it is relatively easy to get them to extend it to third-parties. It is harder to get people to sign up for an all-encompassing internet identity service from scratch.

This is why Azure Active Directory will work where Hailstorm failed, though within a more limited context since nobody expects Microsoft to dominate today in the way it might have done back in 2001.

Microsoft’s Scott Guthrie on what has happened to Silverlight

I spoke to Microsoft’s Scott Guthrie last week, during his trip to the UK for a couple of Windows Azure events in Cambridge and London.

Guthrie is now Corporate VP Windows Azure Application Platform, a job he took up in May 2011. Before that he worked on .NET technologies including Silverlight, and I asked if he had any reflections on the subject. He was scrupulously tactful.

“In terms of looking at our XAML stack right now, if you look at some of the announcements we’ve made in terms of Windows 8, Metro, Surface, tablets and desktops, and Windows Phone, XAML is alive and well and being used for more things than ever.

“Silverlight 5 shipped after I moved on to Azure. We did an update to Silverlight 5 about a month ago. For XAML developers, and developers using Silverlight or WPF XAML technologies, there is a long roadmap ahead.”

He seemed to me to be saying that even if Silverlight is dead (nobody expects a Silverlight 6), XAML lives on.

I observed that in the new (and much improved) Windows Azure admin portal, the Silverlight UI has gone, replaced by an HTML 5 user interface.

“It’s actually HTML, it’s not HTML 5. It works with non HTML 5 browsers as well.“ he said. “That was less of a technology statement, it was more that, historically Azure had 5 or 6 admin tools that were fairly disjoint. One of the decisions we made as part of the new Azure that we’re building was, let’s have a single admin tool framework that connected everything. We decided to do it with HTML, partly because we did want to get reach on tablets like iPads and Android devices.

“It was less a technology statement, it was more that we wanted a single admin tool, and we decided to go with an HTML-based approach. We still use Silverlight for some of our admin experiences like database management tools, and for streaming and other capabilities.”

It is true that Silverlight remains in the Azure database design tool, if you use the portal. It is also used extensively in System Center 2012 – yes, I have actually installed it – and in Windows InTune.

It is as if, back in 2009 and early 2010, the memo went out: use Silverlight for everything. Then, later in 2010, the memo went out: use HTML for everything; but too late for the current generation of server admin products.

Microsoft has announced that Visual Studio LightSwitch, which generates Silverlight applications, is being revised to offer HTML applications as well. I expect this process of Silverlight removal and de-emphasis to continue over the next couple of years. Note that Microsoft’s own Windows RT does not support Silverlight (as far as I am aware), nor does Windows 8 on the Metro side.