Tag Archives: .net

Why Don’t Windows Azure Libraries Show Up In Add Reference Dialog when Using .NET Framework Client Profile?

You are writing an application for Windows – perhaps a Console App or a WPF Application – or maybe an old-school Windows Forms app.  Every is humming along. Then you want to interact with Windows Azure storage. Easy, right? So you Right-Click on the References list in Visual Studio, pop up the trusty old Add Reference dialog box, and search for Microsoft.WindowsAzure.StorageClient in the list of assemblies.

But it isn’t there!

You already know you can’t use the .NET Managed Libraries for Windows Azure in a Silverlight app, but you just know it is okay in a desktop application.

You double-check that you have installed Windows Azure Tools for Microsoft Visual Studio 1.2 (June 2010) (or at least Windows Azure SDK 1.2 (last refreshed from June in Sept 2010 with a couple of bug-fixes)).

You sort the list by Component Name, then leveraging your absolute mastery of the alphabet, you find the spot in the list where the assemblies ought to be, but they are not there. You see the one before in the alphabet, the one after it in the alphabet, but no Microsoft.WindowsAzure.StorageClient assembly in sight. What gives?

Look familiar? Where is the Microsoft.WindowsAzure.StorageClient assembly?

Confirmation Dialog after changing from Client Profile to full .NET

Azure Managed Libraries Not Included in .NET Framework 4 Client Profile

If your eyes move a little higher in the Add Reference dialog box, you will see the problem. You are using the .NET Framework 4 Client Profile. Nothing wrong with the Client Profile – it can be a friend if you want a lighter-weight version of the .NET framework for deployment to desktops where you can’t be sure your .NET platform bits are already there – but Windows Azure Managed Libraries are not included with the Client Profile.

image

Bottom line: Windows Azure Managed Libraries are simply not support in the .NET Framework 4 Client Profile

How Did This Happen?

It turns out that in Visual Studio 2010, the default behavior for many common project types is to use the .NET Framework 4 Client Profile. There are some good reasons behind this, but it is something you need to know about. It is very easy to create a project that uses the Client Profile because it is neither visible – and with not apparent option for adjustment – on the Add Project dialog box – all you see is .NET Framework 4.0:

The “Work-around” is Simple: Do Not Use .NET Framework 4 Client Profile

While you are not completely out of luck, you just can’t use the Client Profile in this case. And, as the .NET Framework 4 Client Profile documentation states:

If you are targeting the .NET Framework 4 Client Profile, you cannot reference an assembly that is not in the .NET Framework 4 Client Profile. Instead you must target the .NET Framework 4.

So let’s use the (full) .NET Framework 4.

Changing from .NET Client Profile to Full .NET Framework

To move your project from Client Profile to Full Framework, right-click on your project in Solution Explorer (my project here is called “SnippetUploader”):

image

From the bottom of the pop-up list, choose Properties.

image

This will bring up the Properties window for your application. It will look something like this:

image

Of course, by now you probably see the culprit in the screen shot: change the “Target framework:” from “.NET Framework 4 Client Profile” to “.NET Framework 4” (or an earlier version) and you have one final step:

image

Now you should be good to go, provided you have Windows Azure Tools for Microsoft Visual Studio 1.2 (June 2010) installed. Note, incidentally, that the Windows Azure tools for VS mention support for

…targeting either the .NET 3.5 or .NET 4 framework.

with no mention of support the .NET Client Profile. So stop expecting it to be there!


Advertisements

Registration open for Boston Azure Firestarter May 8, 2010

Flaming Firestarter Logo

On May 8, 2010 there will be a Firestarter event focused on learning about Microsoft’s Windows Azure Cloud Platform. This FREE, ALL-DAY, HANDS-ON, IN-PERSON event will be held at the Microsoft NERD building in Cambridge, Massachusetts.

Here’s the idea…

You show up in the morning curious about Cloud Computing and the Windows Azure platform… and you leave at the end of the day loaded up from a crash-course/deep-dive into Azure, including a series of Azure-specific technical talks, Azure-specific programming experience (and working code), and access to resources to continue into the future…

Registration is now open!

Register at Eventbrite now.

What will be covered?

While we are still tweaking the schedule and exact contents, we didn’t want to delay opening registration. Rest assured the focus of the event is covering the most important Azure topics through a combination of informative talks and hands-on coding sessions.

We have some outstanding speakers lined up (including a keynote speaker we will announce soon).

More information on this community event – including a more complete/detailed schedule – will be updated progressively over the next few weeks on the web site of the Boston Azure cloud computing using group.

See you there!

[image credit: Firestarter logo built based on http://shaedsofgrey.deviantart.com/art/fire-45734782?moodonly=1 under Creative Commons Attribution-Noncommercial 3.0 License.]

Demystifying Prism – talk at New Hampshire .NET User Group 17-Jun-2009

Spoke at New Hampshire .NET User Group back on June 17, 2009. Talked about Prism (focusing mostly on Silverlight, a little homage to WPF), showed some code, shared a slide deck.

I will be giving an updated version of this talk at the upcoming Code Camp 12 in Waltham (Boston area) on Sat Oct 17, 2009.

A generic error occurred in GDI+ when reading from MemoryStream

I am playing with TagLib#, an Open Source library that supports reading and updating ID3 metadata from MP3 files. I ran across the following error — “a generic error occurred in gdi+” — displaying a bitmap image I pulled from the MP3 file.

   TagLib.File file = TagLib.File.Create(@"foo.mp3");
   int pictureCount = file.Tag.Pictures.Length;
   System.Drawing.Bitmap bmp = null;
   if (pictureCount > 0)
   {
      System.IO.MemoryStream pictureBitstream = new System.IO.MemoryStream(
                                                    file.Tag.Pictures[0].Data.Data);
      bmp = new System.Drawing.Bitmap(pictureBitstream);
      pictureBitstream.Close();

      string fn = "foo.jpg";

      // create thumbnail
      using (System.Drawing.Image thumb =
                      bmp.GetThumbnailImage(10, 10,
                               new System.Drawing.Image.GetThumbnailImageAbort(
                                        delegate { return false; }),
                               IntPtr.Zero))
      {
         thumb.Save(Response.OutputStream, System.Drawing.Imaging.ImageFormat.Jpeg);
      }
   }

The “a generic error occurred in gdi+” message is not very helpful. I did some googling and came up with a few helpful posts on the matter, including several that appeared to be different problems. Looks like 4 Guys from Rolla have functional code.

My problem was in closing the stream too soon, which was not obvious to me at first, though makes some sense. The fix is to defer

      pictureBitstream.Close();

until after the Bitmap object is done with its work. I was initially under the illusion that once I’d created the stream for the image it read the whole image; of course that’s not true – it is not read in until it is read in.

I would submit this is a confusing UI design. Developers deserve better affordances. Good thing an exception was thrown; otherwise, this may have blown up later in a less obvious manner or at a less convenient time.