This week, the Windows Azure AppFabricLabs was updated. The major updates are that the Service Bus labs environment now uses v2 of the Access Control Service and topics/queues have been created. This pushes the number of queueing solutions on Azure to 3:

* Queue Storage

* Message Buffer

* Queues

The main difference between the types of storage relates to size and usage patterns. Queue storage allows for messages up to 8 KB in size and is primarily intended for applications running on Azure. The service only accepts one type of credentials, and you probably don’t want to share those.

The Message Buffer stores messages of up to 60KB for about a minute. It is great for volatile queues as a short lived rendezvous point for exchanging messages. This service lives on the Service Bus and allows for authentication with the Access Control Service.

The Queues implementation in the Service Bus allows for larger messages (up to 256 KB) which can last for a longer period of time. Interacting with the queue feature is pretty simple. Go to the https://portal.appfabriclabs.com page and allocate a Service Bus namespace. The ‘Hello, World’ for the queue looks like this:

static void Main(string[] args)
{
  var sbNamespace = "your namespace";
  var credential = TransportClientCredentialBase.

    CreateSharedSecretCredential("owner", "[your key]");
  var uri = ServiceBusEnvironment.CreateServiceUri("https", sbNamespace, 

    string.Empty);
  var client = new ServiceBusNamespaceClient(uri, credential);
  var messagingFactory =
    MessagingFactory.Create(ServiceBusEnvironment.CreateServiceUri("sb", 

    sbNamespace, string.Empty), credential);
  var queue = client.CreateQueue("demo");
  var queueClient = messagingFactory.CreateQueueClient(queue);
  var sender = queueClient.CreateSender();
  sender.Open();
  sender.Send(BrokeredMessage.CreateMessage("test"));
  sender.Close();
  var receiver = queueClient.CreateReceiver();
  receiver.Open();
  var message = receiver.Receive();
  receiver.Close();
  Console.WriteLine(message.GetBody<string>());
}

There has been a small white lie that many people tell when looking at whether or not a WP7 application can directly interact with the camera. The fib looks like this:

You can only access the camera through the CaptureCameraTask. Direct access is not allowed.

It didn’t seem right when I heard that, so I did some digging around, looking for ways to find out what is really contained in the phone. Some information is out there, and if you assemble the parts, you wind up with a better view into what managed code can do on the phone. I wrote a post earlier that showed what you need to do in order to make your development environment work better. As a result of that effort, you are going to be able to use the camera in your Windows Phone 7 applications today.

Adding live support for a phone is actually pretty easy. You just need to add some references to the right assemblies, add a little markup to your page, and then write a few lines of code.

References

Go ahead and create a WP7 XAML app. Once you do that, you need to add references to two assemblies that aren’t standard issue:

* Microsoft.Phone.InteropServices

* Microsoft.Phone.Media.Extended

Why two assemblies? The first one allows you to work with the second one-nothing more.

Add some markup to display the camera

To work with the camera, live, here is what you do:

1. Add a reference to the Microsoft.Phone.Media.Extended to the page you want to display the camera output to. For example, add the following to the PhoneApplicationPage element:

xmlns:media=

"clr-namespace:Microsoft.Phone;assembly=Microsoft.Phone.Media.Extended"

2. With that in place, you can then put a CameraVisualizer on to your page. A CameraVisualizer displays the content of a camera on to a surface.

<media:CameraVisualizer Name="cameraVisualizer" Visibility="Visible" 

    Margin="64,4,99,26" Height="426" Width="593" />

Hook up the Camera to the Page

In your page’s code behind, add a Microsoft.Phone.PhotoCamera and attach it to the CameraVisualizer. You do that by calling SetSource on the visualizer. The code looks like this:

cameraVisualizer.SetSource(_camera);

 

Doing something with the Camera

From there, you can access methods telling you what is going on with the camera:

* ShutterPressed: Fires when someone presses the camera button.

* ImageSavedToDisk: Fires when the image you just took is saved to disk, passing along the path to the file.

* ThumbnailSavedToDisk: Fires when the thumbnail is saved. This one also has the image path.

When the shutter is pressed, you still need to tell the camera to take the picture. To do this, fire the CaptureImage method on the PhotoCamera instance. You can also do some cool things like set the flash setting, zoom level, and auto focus.

There are a few gotchas with the camera that do make it difficult to work with and show why it wasn’t available to all of us when the phone launched. First off, any time you use the control just a little bit ‘incorrectly’, you will see a COM exception. Second, any time that the visualizer goes off screen then back again, you need to detach any events, then hook them back up again or you will have a bad experience for your users. If you do not handle the pictures being taken in quick succession, you will have issues.

I invite you to play with the camera but be warned-it is a nasty beast to work with and you will spend quite a few cycles fixing weird little bugs. Microsoft never made a general release of this code because the code needed more QA before burning any cycles documenting the feature. They’ve already announced it will be in better shape for Mango, but if you want to use it now, I’ve given you enough rope. Have some fun (and don’t hang yourself)!!!

Thanks to Jeff Prosise for encouraging me to talk about this. We were chatting in late April at a conference when I was having some fun with a WP7 camera app I had written and he said he wanted to know how I did that.

The May 2011 AppFabric updates have shipped. You can get them all from here: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=d89640fc-c552-446e-aead-b1e0d940f31b. Coverage is exploding over at TechEd, Clemens Vasters can finally talk about topics, and it’s a grand day. So, many of you will be digging into the source and will want a CHM file that works. The that you download will be blocked from showing Internet content and when you open it, you will see something like this:

If you do see that ‘Navigation to the webpage.’ message, here is what you’ll need to do.

1. Right-click on the CHM file and select ‘properties’.

2. On the General tab, there is a button WAAAAAAYYYYYYY at the bottom labeled Unblock. Click that button so that the content from the Internet will display just fine on your PC.

3. Reopen the CHM and you’ll be able to actually view things.

WARNING: Everything I’m sharing with you is unsupported. You may or may not be able to publish WP7 applications to the Marketplace using these features. The point behind this is to satisfy hackers. This does NOT modify your phone in any way-it just makes it easier to dig into what WP7 already does. If you use these undocumented features, Microsoft may later change these APIs your applications when they choose to document these features or remove them from a future image of your WP7 phone. Microsoft does not promise to keep these APIs alive between WP7 updates. Got it?

I was curious what goodies were on the phone but not available to everyone else. I knew that people had grabbed the OS image and pulled apart the files on it already, so I figured someone had probably hacked that part already. After some searching, I found this: http://thounsell.co.uk/2010/11/avoiding-reflection-adding-the-interopservices-library-to-the-wp7-sdk/. The handy thing here is that Thomas Hounsell also dumped out all the libraries and gave a hint as to how to include these in our own applications. In there, you will find all sorts of goodies. The binaries he provides include EVERYTHING- documented and undocumented. I didn’t see complete details on how to wire up the additional, undocumented bits. Here are my extra instructions:

1. Unpack the binaries from here.

2. Copy the dlls to C:Program Files (x86)Reference AssembliesMicrosoftFrameworkSilverlightv4.0
ProfileWindowsPhone

3. Run the following commands from a VS 2010 command prompt, running as administrator (line breaks are in the right place, so copy and paste from here should work):

move GAC_CustomMarshalers_v3_7_0_0_cneutral_1.dll CustomMarshalers.dll
move GAC_Microsoft.Phone.InteropServices_v7_0_0_0_cneutral_1.dll Microsoft.Phone.InteropServices.dll
move GAC_Microsoft.Phone.Media.Extended_v7_0_0_0_cneutral_1.dll Microsoft.Phone.Media.Extended.dll
move GAC_Microsoft.ServiceModel.Channels.Mail.WindowsMobile_v3_7_0_0_cneutral_1.dll Microsoft.ServiceModel.Channels.Mail.WindowsMobile.dll
move GAC_Microsoft.ServiceModel.Channels.Mail_v3_7_0_0_cneutral_1.dll Microsoft.ServiceModel.Channels.Mail.dll
move GAC_Microsoft.VisualBasic.SR_v8_1_1_0_cneutral_1.dll Microsoft.VisualBasic.SR.dll
move GAC_Microsoft.VisualBasic_v8_1_1_0_cneutral_1.dll Microsoft.VisualBasic.dll
move GAC_System.Data.DataSetExtensions_v3_7_0_0_cneutral_1.dll System.Data.DataSetExtensions.dll
move GAC_System.Data_v3_7_0_0_cneutral_1.dll System.Data.dll
move GAC_System.Messaging_v3_7_0_0_cneutral_1.dll System.Messaging.dll
move GAC_System.Net.IrDA_v3_7_0_0_cneutral_1.dll System.Net.IrDA.dll
move GAC_System.SR_v3_7_0_0_cneutral_1.dll System.SR.dll
move GAC_System.Web.Services_v3_7_0_0_cneutral_1.dll System.Web.Services.dll
move GAC_System.Windows.debug.resources_v2_0_5_0_cen-US_1.dll System.Windows.debug.resources.dll
move GAC_System.Windows.RuntimeHost_v2_0_5_0_cneutral_1.dll System.Windows.RuntimeHost.dll
sn -Vr CustomMarshalers.dll
sn -Vr Microsoft.Phone.Interop.dll
sn -Vr Microsoft.Phone.InteropServices.dll
sn -Vr Microsoft.Phone.Media.Extended.dll
sn -Vr Microsoft.ServiceModel.Channels.Mail.dll
sn -Vr Microsoft.ServiceModel.Channels.Mail.WindowsMobile.dll
sn -Vr Microsoft.VisualBasic.dll
sn -Vr Microsoft.VisualBasic.SR.dll
sn -Vr System.Data.DataSetExtensions.dll
sn -Vr System.Data.dll
sn -Vr System.Messaging.dll
sn -Vr System.Net.IrDA.dll
sn -Vr System.SR.dll
sn -Vr System.Web.Services.dll
sn -Vr System.Windows.RuntimeHost.dll
del GAC_*.dll

4. From that administrative window, use notepad to open up

C:Program Files (x86)Reference AssembliesMicrosoftFrameworkSilverlightv4.0ProfileWindowsPhoneRedistListFrameworkList.xml

5. Within the XML add the following lines before the closing tag in the document (and save the file!):

  <File AssemblyName="Microsoft.Phone.InteropServices" Version="7.0.0.0" Culture="neutral" PublicKeyToken="24eec0d8c86cda1e" ProcessorArchitecture="MSIL" InGac="false" />

   <File AssemblyName="Microsoft.Phone.Media.Extended" Version="7.0.0.0" Culture="neutral" PublicKeyToken="24eec0d8c86cda1e" ProcessorArchitecture="MSIL" InGac="false" />

   <File AssemblyName="CustomMarshalers" Version="3.7.0.0" Culture="neutral" PublicKeyToken="969db8053d3322ac" ProcessorArchitecture="MSIL" InGac="false" />

   <File AssemblyName="System.Data" Version="3.7.0.0" Culture="neutral" PublicKeyToken="969db8053d3322ac" ProcessorArchitecture="MSIL" InGac="false" />

   <File AssemblyName="Microsoft.ServiceModel.Channels.Mail.WindowsMobile" Version="3.7.0.0" Culture="neutral" PublicKeyToken="969db8053d3322ac" ProcessorArchitecture="MSIL" InGac="false" />

   <File AssemblyName="Microsoft.ServiceModel.Channels.Mail" Version="3.7.0.0" Culture="neutral" PublicKeyToken="969db8053d3322ac" ProcessorArchitecture="MSIL" InGac="false" />

   <File AssemblyName="Microsoft.VisualBasic" Version="8.1.1.0" Culture="neutral" PublicKeyToken="969db8053d3322ac" ProcessorArchitecture="MSIL" InGac="false" />

   <File AssemblyName="Microsoft.VisualBasic.SR" Version="8.1.1.0" Culture="neutral" PublicKeyToken="969db8053d3322ac" ProcessorArchitecture="MSIL" InGac="false" />

   <File AssemblyName="System.Data.DataSetExtensions" Version="3.7.0.0" Culture="neutral" PublicKeyToken="969db8053d3322ac" ProcessorArchitecture="MSIL" InGac="false" />

   <File AssemblyName="System.Data" Version="3.7.0.0" Culture="neutral" PublicKeyToken="969db8053d3322ac" ProcessorArchitecture="MSIL" InGac="false" />

   <File AssemblyName="System.Messaging" Version="3.7.0.0" Culture="neutral" PublicKeyToken="969db8053d3322ac" ProcessorArchitecture="MSIL" InGac="false" />

   <File AssemblyName="System.Net.IrDA" Version="3.7.0.0" Culture="neutral" PublicKeyToken="969db8053d3322ac" ProcessorArchitecture="MSIL" InGac="false" />

   <File AssemblyName="System.SR" Version="3.7.0.0" Culture="neutral" PublicKeyToken="969db8053d3322ac" ProcessorArchitecture="MSIL" InGac="false" />

   <File AssemblyName="System.Web.Services" Version="3.7.0.0" Culture="neutral" PublicKeyToken="969db8053d3322ac" ProcessorArchitecture="MSIL" InGac="false" />

   <File AssemblyName="System.Windows.RuntimeHost" Version="2.0.5.0" Culture="neutral" PublicKeyToken="31bf3856ad364e35" ProcessorArchitecture="MSIL" InGac="false" />

And that’s pretty much all you need to do in order to get access to the other DLLs within VS 2010.

It seems that, over the last several months, people have become convinced that WPF is dead. Having seen the pace of change in previous desktop UX technologies, I think this concern is unfounded. Has the talk about WPF declined since it launched? Of course. Adoption is no longer a concern. Anyone who needs a desktop application knows WPF exists, books and training are available, and the knowledge is out there. Microsoft doesn’t really need to work hard here at this point in time. So, why the angst around WPF?

It seems that the fundamental concern is around the fact that many vendors have stopped fighting for the desktop and have resumed the fight at the browser, saying my HTML5 is better than theirs. The desktop war has gone quiet again and Microsoft still owns that platform, so they’ve visibly shifted investment from the desktop to where the battle is: in browsers and HTML5. That doesn’t mean that they’ve stopped building WPF, or WinForms, or WebForms, or MFC. But, Microsoft has visibly reduced its investment in those areas. The current set of big bets has been expensive: Azure, WP7, XBox, and Bing. A large part of the Azure investment involves moving server platforms to the cloud. That investment is particularly expensive because now everything has to work on premises and in Azure. Microsoft has limited resources and trying to get significantly more desktop functionality in the next several years just doesn’t make sense from a fiduciary point of view. The WPF team still lives, it’s just smaller than in 2005.

To appreciate the pace of innovation in WPF, take a look at this ScottGu post from 2009: http://weblogs.asp.net/scottgu/archive/2009/10/26/wpf-4-vs-2010-and-net-4-0-series.aspx.  I expect a similar amount of forward momentum in .NET 5 to add Windows 8 features for WPF developers. WPF is now a mature, stable, technology. Like other libraries in .NET, innovation is no longer around building the perfect class library but instead on enhancing the library’s usability and utility. The same things are happening in WCF, System.Transactions, System.Net, System.Security, and other namespaces that we never hear about but that we know haven’t been abandoned.

As .NET developers, we need to articulate these facts to project sponsors. When they say “I hear WPF is dead” have them look at WPF and how it has grown. Look at what it does. Explain that the investment in WPF has declined because the amount of work to get done today is incremental– support video cards better, add support to match Windows Shell innovation, improve drawing. The library is still being enhanced. http://dotnet.uservoice.com/forums/40583-wpf-feature-suggestions/topics/41002-i-suggest-you-/filter/hot tells the story of what people want and what is being accepted into the next version of WPF.

If that’s not enough, remind the naysayer that even MFC is still being enhanced.