Windows 8 and ClickOnce : the definitive answer revisited

Since I posted the article titled Windows 8 and Click Once: the definitive answer, it became clear that it was not actually the definitive answer.

I got a ping on twitter from Phil Haack from GitHub telling me that this did not fix their Smart Screen filter problem.

After talking to him, and seeing his build and signing commands, I discovered they recently changed their signing certificate. For those of you who remember the early days of ClickOnce (2005) when you changed the signing certificate and everybody had to uninstall and reinstall the application, this seemed too likely an indicator to ignore.

Reputation

I didn’t talk in my article about “reputation” (and I should have, so I duly apologize here for that). In my first conversations with Microsoft, they mentioned that an application had a reputation, and this reputation had some bearing on the appearance of the Smart Screen Filter, and this reputation was built based on how many people had installed your application.

When I asked how many people had to install your application before the Smart Screen filter stopped interrupting the running of the application, I could not get a clear answer. Of course, this makes sense that they wouldn’t want to make their algorithm public, because you could publish your app, install it X number of times yourself, and make it reputable. (I’m not suggesting you do that, but if you do, please post back and tell us your results. Inquiring minds want to know.)

Since we’ve been in business for a few years, and have well over a thousand customers (probably thousands) who have installed the desktop application, this didn’t impact us. The reason I didn’t mention it in the blog post is because I created a new Windows Forms test application and deployed it solely for the purpose of testing the information in the article, and had no problem with the Smart Screen Filter. I installed the application maybe a dozen times while messing with the build commands, so I figured, “Wow, the number of installs required is pretty small.” Haha!

So on behalf of Phil, I pinged my contact at Microsoft, and he went off to investigate. After a bit of research, he found some information internal to Microsoft. I won’t quote it directly in case I shouldn’t, but the gist of it was this: The digital certificate information may be taken into account when determining the reputation of the application. A-HA! I thought to myself (and immediately started humming that song, “Take On Me”.)

So the problem at GitHub is probably due to the certificate being updated right about the same time they start signing their assembly for customers using Windows 8. I expect that fairly soon, as people install or get updates (if they are using automatic updates), their reputation will be sterling and nobody will ever see the Smart Screen Filter again when installing GitHub.

Knowing this, it makes sense that my test application didn’t get stopped even though it was a brand new application. I signed it with my company’s signing certificate, which has been in use for several months.

Which leads me to another issue I noticed when talking to Phil. I noticed that rather than using PostBuild or BeforePublish commands, he was using AfterCompile commands to sign his executable. I asked him about it.

PostBuild, BeforePublish, and AfterCompile, oh my!

Apparently when Phil signs his executable using PostBuild or BeforePublish commands, when the user installs it, he gets the dreaded “exe has a different computed hash than specified in the manifest” error. He found that using AfterCompile instead fixed the problem.

I went back to Microsoft, and they soon verified the problem, and said it is due to WPF applications having a different set of targets and execution order, so the standard AfterBuild/BeforePublish commands don’t quite work. So the bottom line is this: The signing of the exe doesn’t work right with BeforePublish or PostBuild if you are using VS2012 and you have a WPF application. In that case, you must use AfterCompile. So in the original post, use case #3, but put in AfterCompile instead of BeforePublish.

If you are using VS2010, OR you have a Windows Forms or Console application, you can use PostBuild or BeforePublish with no problem.

Hopefully we now have the definitive answer to handling the Smart Screen filter and signing a ClickOnce application that will be run on a Windows 8 machine.

Thanks to Zarko Hristovski and Paul Keister, who also reported the problem with the BeforePublish command, and who verified that AfterCompile worked for them. Thanks to Phil Haack for the answer to a problem I didn’t know existed yet. And thanks to Saurabh Bhatia at Microsoft for his help with Windows 8 and ClickOnce.

Tech Days San Francisco, 2-3 May 2013, through Azure-colored glasses

Living in the San Francisco Bay Area is awesome if you work in tech. There are so many companies springing up all the time and so many interesting places to work. The hard part of working in tech is keeping up with the current technologies and learning the new skills that can help you advance your career. A great way to do that is to keep your eyes open for conferences, dev days, tech days, etc., in your area, sign up and go. There are so many great opportunities being offered by the community leaders in your area.

A really interesting opportunity is coming up in the San Francisco Bay Area in early May – Tech Days SF. While primarily for IT Pros, there are also sessions that will be interesting to developers. What developer couldn’t benefit from knowing more on the IT Pro side? I was recently talking to another Azure MVP, and we agreed that now with all of the features in Windows Azure, it would behoove us to learn about virtual networks and some of the other IT-type features we never had to know when just doing software development.

There are some great speakers coming, which I doubly appreciate, because I managed to poach Glenn Block from Microsoft to speak at the Azure Meetup in San Francisco the night before (5/1) about mobile services (official announcement coming soon). And there is going to be a wide variety of topics; here is a random selection that just coincidentally seem Azure-related or Azure-useful:

• Windows Azure
• Managing the Cloud from the CmdLine
• Microsoft IT – Adopted O365 and Azure
• Windows Azure Virtual Machines (IAAS)
• PowerShell Tips and Tricks (You can use PowerShell scripts with Windows Azure)
• Manage Server 2012 Like a Pro or Better, Like an Evil Overlord (I like the title)

This is just one of many opportunities available to keep your skills up-to-date. So check it out, sign up, and go expand your knowledge!

(Reminder – There’s also a Global Windows Azure Bootcamp in San Francisco on 4/27!)

Windows 8 and ClickOnce : the definitive answer

There have been a lot of copies of Windows 8 sold since it came out a few months ago, and the Surface Pro was just released. (In fact, I’m writing this on my brand new Surface Pro, which I really like, but that’s a subject for another time.)

If you’re using ClickOnce deployment, you’re probably wondering how (or if) it’s going to work with Windows 8. I’ve worked with Saurabh Bhatia at Microsoft to ensure that this article will cover what you need to know. We use ClickOnce at GoldMail (whose product is now called Point Across) for our desktop product and VSTO applications, as well as several internal utility applications, so I’ve also tested this on our products to make sure it’s accurate.

If you are hosting your deployment on a file share or on an intranet, you won’t have to make any changes. You can go get ice cream now while the rest of us soldier on.

If you are hosting your deployment on the internet, you will eventually get calls from your customers who have upgraded to Windows 8 or purchased a Windows 8 machine. So let’s talk about that.

I’m not going to talk about the bootstrapper right now; that’s going to come up later. For now, let’s concentrate on the ClickOnce application itself. When a user installs a ClickOnce application on Windows 8, here’s what happens:

• ClickOnce gets the manifest, checks the certificate, and shows the ClickOnce prompt with “trusted publisher” or “unknown publisher” (depending on your signing certificate).
• The user clicks the Install button.
• It checks the certificate on the executable. If it’s not signed, the Smart Screen Filter is triggered.

So here’s what the user experience looks like when you install a ClickOnce application on Windows 8:

You get the standard install prompt:

The publisher is known because I am signing the deployment with a signing certificate purchased from a Certificate Authority – in this case, Verisign.

If you click Install, it shows the standard install dialog and actually installs the application. But then it shows a blue band across your screen saying, “Windows SmartScreen prevented an unrecognized app from starting. Running this app might put your PC at risk.”

There is a small “More Info” link under the warning, and a big “OK” button on the bottom of the dialog. Which one would you click? Which one would your customers click? Most people will click the OK button.

If the user clicks OK, the dialog closes, and nothing else happens. Now let’s say the user goes to TileWorld (I’m borrowing David Pogue’s name for the new Windows 8 interface formerly known as Metro). The user can see the application there in the list of apps because it actually got installed. If he clicks on it to run it, nothing happens. So congratulations! The user has installed your application, but he can’t run it.

What happens if the user clicks “More Info” instead of “OK”? He sees the following screen, and he can choose “Run Anyway” or “Don’t run”.

For “Publisher”, it says “Unknown publisher” – this is referring to the executable, which is not specifically signed. Only the manifests are signed. This has never been a requirement for ClickOnce deployments. Until now.

If the user chooses “Run Anyway”, it will run the application. Yay! And when he goes back to TileWorld and tries to run it from there the next time, it will work and will not prompt him again. Yay!

So let’s say he clicks “Run Anyway”, and now he has no problem running your application. What happens when an update is published and he installs it? Uh-oh. The smart screen filter interrupts again, and he has to select “More Info” and “Run Anyway” again.

Is there a way to circumvent your ClickOnce application being captured and stopped by the Smart Screen Filter? Yes. Otherwise, this would be a much shorter (and depressing) article. All you have to do is sign the application executable after building it and before deploying it. For this, you need your signing certificate and signtool.exe, which is one of the .NET Framework tools. There are three points in the build/publish process at which you can do this:

1. Post-publish

2. Post-build

3. Pre-publish

#1: Signing the application executable post-publish

To do it post-publish, you have to do the following:

• a. Publish the files to a local directory.
• b. Use signtool to sign the exe for the application.
• c. Use mage or mageUI to re-sign the application manifest (.exe.manifest).
• d. Use mage or mageUI to re-sign the deployment manifest (.application).
• e. Copy the files to the deployment location.

If you’ve already automated your deployment with a script and msbuild, this may be the choice you make. If you publish directly from Visual Studio, the other two options are easier.

#2: Signing the application executable post-build

To do this, you define a post-build command in your project. Assuming your certificate (pfx file) is in the top level of your project, you can use something like this:

"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\signtool.exe" sign /f "$(ProjectDir)TestWin8CO_TemporaryKey.pfx" /p nightbird /v "$(ProjectDir)obj\x86\$(ConfigurationName)\$(TargetFileName)"

• The double quotes are required.
• “C:Program Files (x86)Microsoft SDKsWindows\v7.0A\bin\signtool.exe” is the path to the signtool application, used to sign the executable.
• $(ProjectDir) points to the top directory of the project. The subfolder “\obj\x86” will vary depending on your build output path. The above was created and tested on VS2010. On VS2012, my subfolder is just \obj.
• $(ConfigurationName) is the build configuration name, such as Debug or Release – this is required because it signs it in the obj directory and has to know which folder to use.
• $(TargetFileName) is the name of the application executable.
• TestWin8CO_TemporaryKey.pfx is the name of my certificate file, which is in the top folder of my project.
• /p nightbird – this is the password for my temporary certificate

I have specified the full path to signtool.exe. I tried to do this with one of the msbuild variables that points to the location of the .NET framework files, but it doesn’t work – it doesn’t translate the variable until after it executes the statement. If you print it out in the post-build command, it shows the right location in the Visual Studio output window, but gives you an error that it can’t find it when it actually runs this statement. I’m saving you some time here, because I messed around with that for quite a while trying to get it to work, and after asking Saurabh at Microsoft, he couldn’t get it to work without specifying the whole path, either. So if you get it to work with a msbuild variable, let me know how.

After you’ve created your version of the post-build command, you need to put it in the project properties. Double-click on Properties and click on the Build Events tab. Put your command in the Post-build event command line box.

Now build the project, and the output window will show the results.

If you now publish the application and put the files in the deployment directory, the user can install it and will not see the Smart Screen Filter. Yay!

What if you have multiple programmers working on the application, and they all build and run the application? Every programmer must have signtool.exe in the exact same location for this post-build command to work for everybody. If you have a 32-bit machine, the folder for the “Microsoft SDKs” is under “C:Program Files”, without the “(x86)” on the end. And someone might actually install Windows to a drive other than C. If their signtool.exe file is not in the same location, they can’t build and run the application, which means they can’t put in changes and test them.

Only the person publishing the application really needs this build command to work. So how do you execute this only for the person publishing the application? You can set up a pre-publish command.

#3: Signing the application executable pre-publish (recommended solution)

The pre-publish command is executed after building the application and right before publishing it. There is no box for this under Build Events, so you have to add it to the project yourself. (Be sure to clear out the post-build event command line before doing this.)

To add a pre-publish command, right-click on the project in Visual Studio and select “Unload Project”.

Now right-click on the project again and select “Edit yourprojectname.csproj”.

It will open the csproj file in Visual Studio so you can edit it. Go down to the bottom and add a new section before the </Project> line. You’re going to put your pre-publish command line in this section.

<Target Name=”BeforePublish”>

</Target>

So what do you put in this section? You are going to specify a command to execute, so you have to use Exec Command, and put the command to execute in double quotes. Since you can’t put double-quotes inside of double-quotes (at least, not if you want it to work), you need to change the double-quotes in your command to &quot; instead. So my build command from above now looks like this:

<Exec Command="&quot;C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\signtool.exe&quot; sign /f &quot;$(ProjectDir)TestWin8CO_TemporaryKey.pfx&quot; /p nightbird /v &quot;$(ProjectDir)obj\x86\$(ConfigurationName)\$(TargetFileName)&quot;" />

After making this match your parameters, save the csproj file and then close it. Then right-click on the project and reload it:

Now if you build your project, you won’t see anything about signing the application executable in the output window. It will only do it if you publish, and there won’t be logging letting you know it signed it. How do you know if it worked? Go to the folder you published to, and look in the Application Files folder. Locate the application executable in the folder for the new version. Right-click on it, choose properties. Look for a tab called “Digital Signatures”. If it’s not found, it’s not signed. If you do see it, go to that tab; it will show the signature list and the signer of the certificate. You can double-click on the signer and then view the signing certificate.

How will the application work after publishing it with a signed executable?

If you sign your executable and your deployment with a valid certificate from a Certificate Authority like Verisign using one of the methods above, when the user clicks install, it will install without stopping and showing the SmartScreen filter, and updates will do the same. Yay!

Do I have to use a certificate from a Certificate Authority to circumvent the Smart Screen Filter?

Yes.

Is there any workaround?

No.

If you try the old tried and true “install the certificate in the trusted publishers store on the client computer”, you will find that this does not circumvent the Smart Screen Filter. You must have a certificate from a valid Certificate Authority. Without one, your customer will get the Smart Screen filter when he installs the application, and every time he installs an update.

What about the bootstrapper (setup.exe)?

The bootstrapper (setup.exe) is signed the same way as the ClickOnce deployment; this happens when you publish. When run, this installs the prerequisites and then calls the ClickOnce application installation. If your certificate is not from a valid CA, the Smart Screen Filter will catch it. This isn’t as critical a problem as the ClickOnce deployment itself because in most cases, your users will only run this the first time.

What about VSTO applications?

If your VSTO application is deployed via a file share or the intranet zone, you will not be impacted. If your VSTO application is deployed via the Internet zone, you may be impacted.

There is no executable for a VSTO application, just an assembly, so you don’t have to do any extra signing. However, the following is true:

If you sign your deployment with a certificate from a CA, everything will work fine, and the Smart Screen filter will not interrupt either the setup.exe or the vsto file from installing the app or keep the app from running.

If you are using a test certificate, setup.exe will be caught by the Smart Screen filter. If you click ‘Run Anyway’, it will install the prerequisites, but it will not let you install the VSTO application.

If you install the test certificate in the Trusted Publishers store, setup.exe will still be caught by the Smart Screen filter, but the VSTO application can be installed and run. This is strongly advised against, as installing the certificate on the user’s machine introduces a significant security risk.

Which method to you recommend?

The advantage of the post-build command is that it is transparent. You can easily go into the Build properties and see there is a post-build command. A pre-publish command is kind of hidden in the project file. However, everybody has to have signtool.exe in the same place, and for us that’s a non-starter. Also, if I did leave the post-build command in there, someone might change it to match their path and check in the change, causing a problem when we actually try to build the application for production.

I used the post-build methods to test my build command until I got it to work, and then ported it to a pre-publish command. 

To summarize, a flowchart:

In summary, here’s a flowchart to help you easily see whether your users will get the Smart Screen filter when they install your application on Windows 8.

One last note: The first version of VS2012 had a bug where the bootstrapper created when publishing a ClickOnce application would not work on a Windows XP machine. This problem was fixed in the first update.

[edit: Fixed build paths, some \’s were missing. Added recommendation. –Robin 2.26.2013]

[edit: After publishing this article, I heard from a couple of people who were still having problems. Please check out the next blog article about this if you are still having problems with the Smart Screen filter, or getting the dreaded “exe has a different computed hash than the manifest” error. –Robin 4.14.2013]

Windows Azure Conference Streamed Live Wednesday 11-14-2012

I’m really excited about the upcoming Windows Azure community event this Wednesday. It’s a full day of Windows Azure sessions streamed live on Channel 9. It starts with Scott Guthrie’s  opening keynote. Scott’s a Corporate VP at Microsoft who can actually write code, and gives a very impressive demo. That will be a great start to a very interesting day, with developers showing you some of the things they know about Windows Azure that will help you develop applications on Microsoft’s awesome cloud platform. I think that’s one thing that’s really cool about this conference – it’s not the usual “here’s what windows azure is”, etc. – it’s *how* to apply all those great Windows Azure features in real-world situations.

The schedule for the individual sessions is here. They have sessions on:

• the new Windows Azure Mobile Services,
• building Windows Azure applications with HTML5 and Web Sockets,
• how to handle throttling and transient faults in Azure services,
• security and compliance challenges with hybrid clouds,
• how to achieve great performance at low cost,
• building cross-platform media applications using the Windows Azure Media Services,
• building elastic, autoscalable solutions, and
• Node.js.

Some of the Windows Azure MVPs are also speaking. Michael Collier (twitter: @MichaelCollier) will show you how to automate the deployment of your new cloud solutions. Magnus Martensson (twitter: @noopman) showing how to achieve continuous delivery. Andy Cross (twitter: @andybareweb) will talk about Windows Azure and embedded devices.

Now, you might wonder about the cost of all this Azure greatness. Hard as it is to believe, it’s free! Just register here and all will be revealed to you.

Silicon Valley Code Camp, Scott Guthrie, and me

What do Silicon Valley Code Camp, Scott Guthrie, and I have in common? We’ll all be in Los Altos Hills in the Silicon Valley area this weekend (10/7-10/8).

Yes, that’s right, Scott Guthrie is speaking at SVCC this Sunday 10/7 at 9:15 a.m. PST. Scott is a Corporate VP of Microsoft’s Server and Tools business, and I can personally say that since he’s been put in charge of Windows Azure, things are hopping even more than they already were. A year ago, who would have thought they would ever let you run Linux on Microsoft’s premier cloud computing platform? And yet, that’s what’s happening, in addition to adding a lot more exciting features and options that make the cloud accessible to everyone, not just those developing on the Microsoft stack. Scott is going to give you an overview and do a bunch of demos. He’s a great speaker, and you shouldn’t miss this if you can help it. I hope to see you there!

If you’re looking to learn something about Azure on Saturday 10/6, I’m speaking at 3:30. I’m going to do a robo talk about Windows Azure development, and show how to create a WCF service that accesses SQL Azure (and Windows Azure Table Storage, if I have time), and uses blobs and queues and web roles and worker roles and diagnostics. You should come just to see if I can squeeze the whole talk into 1:15. I’ll also take general architecutre questions and answer questions about my company’s successful migration to Windows Azure.

At 5:00, I’ll talk about how everyone can use blob storage – it’s not just for use in Windows Azure. You can use blob storage in your web application or desktop application without ever touching anything else in Windows Azure. Come see how! I know it’s the end of the day, but I promise you won’t fall asleep!

Host your ClickOnce deployment in Azure for pennies per month

A while back, I wrote an article that shows you how to host your ClickOnce deployment in Windows Azure Blob Storage. The article assumed that you already had a Windows Azure account.

Since prequels are so popular in Hollywood (Star Wars I-III, anyone?), I thought I would write a prequel to explain how much it costs to host your deployment in Azure, and how to sign up for an Azure account and create the storage account. Hopefully, this article will be more popular than Jar Jar Binks.

Show me the money

How much does it cost to host your ClickOnce deployment in Windows Azure Storage? Well, for a pay-as-you-go account, here are the costs as of today, which I found by going to here and clicking on “Pay-As-You-Go”.

Windows Azure Storage

• $0.15 per GB stored per month
• $0.01 per 10,000 storage transactions

  Data Transfers

  • North America and Europe regions
    • $0.15 per GB out
  • Asia Pacific Region
    • $0.20 per GB out
  • All inbound data transfers are at no charge.

Let’s take an example. Let’s say we have a deployment consisting of 150 files and a total size of 30MB. We have 100 customers, and we are going to publish a new version every month, starting in January, and all 100 customers are going to update to every version. At the end of the year, how much will this have cost us?

Put your mathlete hats on and get out your calculators. Ready? Here we go…

The storage cost for one month = $0.15 / GB * 30MB * 1GB/1000MB = $.0045. So January will be (1*value), February will be (2*value) because we’ll have two versions. March will be (3*value), and so on until December when it hits (12*value) because we have 12 versions stored. After calculating that out for the whole year, the total cost of storing the deployment files for the year will cost $0.2475. This is affordable for most people.

Let’s talk about the storage transactions. If you have a file bigger than 32MB, it is one transaction per 4MB and one at the end of the list of blocks. If the file is smaller than 32MB, it’s 1 transaction for that file. All of the files in our case are less than 32MB. So when we upload a new version of the deployment, here are the costs:

Storage Transaction cost when uploading once = 30 files * $.01/10000 = $0.00003.

Data Transfer costs are free going up, so nothing to calculate there. How about coming back down to your customer?

Transaction cost when downloading once = 30 files * $.01/10000 = $0.00003.

Data transfer cost when downloading once = 30 MB * 1GB/1000MB * $0.15/GB = $0.0045

Now you’re wishing you’d paid attention in all of those math classes, aren’t you? And we’re not done yet. Let’s calculate our total for the entire year.

• $0.00036 = Storage Transaction cost for uploading 12 versions throughout the year.
• $0.00 = Data Transfer cost for uploading 12 versions.
• $0.2475 = Storage for 12 versions uploaded once per month and retained throughout the year.
• $0.036 = Storage Transaction cost for downloading 12 versions for 100 customers.
• $5.40 = Data Transfer cost when downloading 12 versions for 100 customers.

So our grand total is $5.68386, which is an average of 47 cents per month.

For more detailed information on Windows Azure storage costs, check out this blog entry from the Windows Azure Storage Team; it was written before they eliminated the Data Transfer cost of uploading to blob storage so don’t include that cost. Thanks to Neil McKenzie for clarification, and for providing the link to the Windows Azure Storage Team blog.

Hook me up with an Azure account

You have three basic options.

1. If you have an MSDN subscription either through your company or because you are a bizspark customer, you probably get an MSDN benefit that more than covers your ClickOnce deployment costs. The basic mechanism for signing up will be similar, but the way you set up your storage account will be the same, so that information below should work for you as well as for those who have no MSDN account. You will have to give your credit card to cover any charges over the free usage benefit.
2. If you want to try this out for free without giving your credit card, you can sign up for a free 30-day Azure pass. At the end of 30 days, you will have to delete the storage account and set it up on a real account if you want to continue using it. (If you use the same storage account name on the new account, the URL will be the same and your users will be able to pick up updates even though you changed accounts.)
3. If you sign up for a pay-as-you-go account, you have to give your credit card, but you get a free benefit which would make my deployment example free for the first 3 months. Then at the end of 3 months, it will start charging your credit card, and you will not have to move your storage account. Let’s take a look at how to sign up for this type of account.

Go to
http://www.microsoft.com/windowsazure/offers/
This should take you to the Windows Azure Platform Offers shown in Figure 1.

Figure 1: Windows Azure Platform Offers

Click on the Pay-As-You-Go tab and then click the Buy button on the right. Next, you will be given a choice to sign up for a new Windows Live account, or use one you already have (Figure 2).

Figure 2: Sign up or sign in.

They are going to send you e-mail on this account, so be sure it’s an account you actually check periodically. After logging in with your Windows Live account, you will be prompted for your profile information (Figure 3).

Figure 3: Profile information.

Fill in your address and phone number and click the Next button. You will be prompted for company information (Figure 4). I think you’ll find that a lot of people work for “n/a”. I doubt Microsoft looks at that information, but you can amuse yourself by putting in the name of the most popular fruit in America, just in case someone IS looking at the company names — give them a surprise. Although, it is widely reported that Apple uses Windows Azure Storage for their new iCloud service, so it might not surprise them at all. (Google would definitely surprise them!)

Figure 4: Company information

Now they will ask for your Service Usage Address. (You can check the box to use the information you filled in on the profile page.) This is displayed in Figure 5.

Figure 5: Service Usage Address.

Fill in the information and click Finish. Next you will get directions to close this page and go to the Services page. You will find yourself at the Customer Portal for the Microsoft Online Services (Figure 6).

Figure 6: Customer Portal for Microsoft Online Services

Now you get to pick a plan. If you pick the Windows Azure Platform Introductory Special, they provide some benefit for free for the first 90 days. This benefit covers our ClickOnce deployment example above, so it would be free for the first three months, and then would cost you as noted above. If you’re nuts and you don’t like free stuff and just want to pay now, You can select the Windows Azure Platform Consumption. Click the Buy Now button on your selection; you will be prompted to log in again and then taken to the Pricing and Online Subscription Agreement screen (Figure 7).

Figure 7: Pricing and Online Subscription Agreement.

Fill in your subscription name. Pick something that you like and can remember. Then read the Online Subscription agreement as carefully as you read all of these things, check the box and hit the Next button. If you don’t read it carefully, and Microsoft comes to your house to pick up your firstborn child, don’t say I didn’t warn you.

Next comes the hard part. Fill in your credit card information and click the Submit button. If your credit card information is correct, you will be sent to the Azure portal (Figure 8).

I now have an Azure account! How do I set up my new storage account?

This is the Windows Azure Portal, which you can reach through this URL:
http://windows.azure.com

Figure 8: Windows Azure Portal

This screen is where you manage all of your Azure services. You can define services, set up databases, and set up storage accounts, which is what we’re here to do. Click on the ‘New Storage Account’ icon at the top of the screen as shown in Figure 9.

Figure 9:Create a new storage account

Next you will be prompted for your new storage account name (Figure 10). This will be used in the URLs for accessing your deployment, so you should probably think twice before making it something like “myapplicationsux” or “mypornpix”. The name must have only lowercase letters and numbers. After you fill it in, it will tell you if it’s already used. If it doesn’t give you any errors, it’s available.

In regards to the region, you will be asked to either choose a region, choose an affinity group, or create a new affinity group. This is not something you can change later, so choose wisely. (Unlike Walter Donovan in Indiana Jones and the Last Crusade, if you choose poorly, you will not instantly grow ancient and disintegrate.)

Figure 10: Create a new storage account

An affinity group is basically specifying a location and naming it. You can then choose the affinity group when setting up other services to ensure that your compute instances and your data are in the same region, which will make them as performant as possible.

Just in case you ever want to use this account  for something other than Blob Storage, I recommend setting up an affinity group. Select the radio button for “Create or choose an affinity group”, and then select the dropdown. Then you can select the location – be sure to use the dropdown. Mine defaulted to “anywhere in the US”, but it’s better to select a specific region, such as North Central or South Central, or whatever region is closest to you. Then click OK to go ahead and create the storage account. You should now see your storage account in the Windows Azure Portal (Figure 11).

Figure 11: Storage Account

You can assign a custom DNS entry to your storage account by clicking the Add Domain button on the top of the screen and following the instructions.

The URL for accessing your blob storage is on the right side of the screen. Mine is robindotnet.blob.core.windows.net. On the right are also the View buttons for retrieving the primary access key that you will need to set up a client application to access your blob storage. With these two pieces of information, you should be able to view your data.

For uploading and maintaining your files in blob storage, I use Cloud Storage Studio from Cerebrata which is excellent, but not free. There are free storage explorers available, such as the Azure Storage Explorer from CodePlex and the Cloudberry Explorer for Azure Blob Storage.

You should be good to go. Now go read the article on how to actually put your ClickOnce deployment in your new storage account, and start racking up those pennies.

How to host a ClickOnce deployment in Azure Blob Storage

Now that Microsoft Azure is becoming more widely used, I’m going to do some blogging about it, since I’ve had an opportunity to work with it quite a bit. What better place to start than to do a crossover blog entry on both ClickOnce deployment and Microsoft Azure? So I’m going to show you how to host your ClickOnce deployment in your Azure Blob Storage.

To do this, you need an application that you can use to manage blob storage. I use the Cloud Storage Studio from cerebrata in my example. A free application recommended by Cory Fowler (Microsoft Azure MVP) is the Azure Storage Explorer from codeplex.

Here  is the GoldMail that explains this process in detail, complete with screenshots. There is a summary below.

View in browser

To summarize:

Create a container in blob storage for your ClickOnce deployment. You’ll need the container name when setting your url. I selected ‘clickoncetest’. The only characters allowed are lower case letter, numbers, and the hyphen (-).

In your project properties, set your Publishing Folder Location to somewhere on your local drive. Set the Installation Folder URL to the URL that will point to the container in blob storage that is going to host your deployment.

For example, I set the first one to E:\__Test\clickoncetest. My account is goldmailrobin, so my installation URL will be
http://goldmailrobin.blob.core.windows.net/clickoncetest/

Publish your application. Then go to the local folder and copy the files and folders up to the container in blob storage. When you are finished, in the root of that container you should have the deployment manifest (yourapp.application file) and the bootstrapper (setup.exe) (and publish.htm if you included it). You should also have a folder called “Application Files”.

In “Application Files”, you should see the ‘versioned folders’ that contain the assemblies for each version of your application that you have published.

When doing updates, you need to upload the versioned folder for the new update, and replace the files in the root folder (yourapp.application, setup.exe, and publish.htm).

If you have any problems, you can check the MIME types on the published files and make sure they are right. These can be changed for each file if needed. With ClickOnce deployments, you should definitely be using the option that appends .deploy to all of your assemblies, so you should not have any files with unknown extensions. If you want to double-check, the MIME types for a ClickOnce deployment are explained here.

Remember that with Blob Storage, it is not going to be storing the files that is going to be the biggest cost factor, it is going to be the transfer of the files to and from the client.

How about a bootstrapper package for SQLServer Express 2008 R2?

When publishing a ClickOnce application, you can open the Prerequisites dialog and select any of the packages to be installed prior to the ClickOnce application. You would probably select the .NET Framework that your application targets and Windows Installer 3.1. You would also select the SQLServer Express 2008 database software if you are using a SQLExpress database in your application.

Last summer, Microsoft released SP-1 for SQLServer 2008 and several people posted to the MSDN ClickOnce Forum and Stack Overflow asking where they could get a new, updated bootstrapper package. I decided to pursue it and see if I could track it down.

I’ll just ask Microsoft.

Saurabh Bhatia, who’s kind enough to help me answer the most difficult ClickOnce questions, routed me to the SQLServer Express program manager, Krzysztof Kozielczyk. Krzysztof said he totally agreed that Microsoft should release a new version of the bootstrapper package every time they updated SQLExpress, but they were busy working on the upcoming releases and he did not have the resources to work on it. It’s hard to know what to say when you tell someone “You should have this” and they say “You’re right, we should, I’m sorry we don’t.” (I’m going to have to remember to use that on my boss in the future.)

According to Krzysztof, the problem is that they can’t just create the package and release it. They have to create the boostrapper package and test it in a bunch of combinations or different variables, such as operating system version, SQLServer Express version (to test that the upgrade works), .NET version, number of olives in a jar, and kinds of mayonnaise available on the west coast, among others. Then if it passes mustard (haha), they have to find somewhere to post it, make it available, and then keep it updated. So more people are involved than just his team, and at that time, everyone in DevDiv at Microsoft was working on the upcoming release of VS2010.

Persistence is one of my best qualiities, so I continued over the following months to badger try to convince Krzysztof to at least help me create the package and provide it to the community, especially after R2 came out. Every time someone posted the request to one of the forums, I would take a screenshot and send it to him. He was unfailingly kind, but stuck to his guns. There’s even been a bug filed in Connect for this issue. (On the bright side, Krzysztof did answer the occasional SQLExpress question from the forums for me.)

Success! (and disclaimers)

Well, we’ve had quite a bit of back and forth lately, and I’m happy to report that I now have a bootstrapper package that I can use to install SQLServer Express 2008 R2 as a prerequisite to a ClickOnce application. (I skipped 2008 SP-1). Krzysztof did not provide the solution, but by peppering the guy with questions, I have finally created a working package. So big thanks to Krzysztof for continuing to answer my questions and put up with the badgering over the past few months. Now he doesn’t need to avoid me when I go to the MVP Summit at the end of this month!

Disclaimer: This did not come from Microsoft, I figured it out and am posting it for the benefit of the community. Microsoft has no responsibility or liability for this information. I tested it (more on that below), but you must try it out and make sure it works for you rather than assuming. Legally, I have to say this: Caveat emptor. There is no warranty expressed or implied. Habeas corpus. E pluribus unum. Quid pro quo. Vene vidi vici. Ad infinitum. Cogito ergo sum. That is all of the Latin-ish legalese I can come up with to cover my you-know-what. (I have more sympathy for Krzysztof now.)

I tested the package as the prerequisite for a ClickOnce application with both 32-bit and 64-bit Windows 7. I tested it with no SQLExpress installed (i.e. new installation) and with SQLExpress 2008 installed (to test that it updates it to R2). I did not test it with a setup & deployment package, but I’m certain it will work. Maybe one of you will try it out and let me know. I did not try it all of the combinations listed above for Microsoft testing, although I did eat some olives out of a jar while I was testing it.

Enough talk, show me the goods

Here are the instructions on creating your own SQLServer 2008 R2 prerequisite package. You must have a SQLServer 2008 Prerequisite package in order to do this. If you don’t have one, and you don’t have VS2010, install the Express version (it’s free). I think you can also install the Windows 7 SDK and it ill provide those prerequisite packages (I’m guessing, since they show up under the Windows folder under SDKs).

I didn’t post the whole package because there is a program included in the bootstrapper package called SqlExpressChk.exe that you need, and it is not legal for me to distribute it. (I don’t think my Latin would withstand the scrutiny of a Microsoft lawyer.)

First, locate your current bootstrapper packages. On my 64-bit Windows 7 machine, they are under C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages. If you don’t have the \en\ folder, presumably you have one for a differeng language; just wing it and substitute that folder in the following instructions.

1. Copy the folder called “SQLExpress2008” to a new folder called “SQLExpress2008R2”.
2. Download the zip file with the product.xml and package.xml you need from here and unzip it.
3. In the new \SQLExpress2008R2\ folder, replace the product.xml file with my version.
4. In the \SQLExpress2008R2\en\ folder, replace the package.xml file with my version.
5. Delete the two SQLExpr*.exe files in the \SQLExpress2008R2\en\ folder.
6. Download the 32-bit install package from here and put it in the \SQLExpress2008R2\en\ folder.
7. Download the 64-bit install package from here and put it in the \SQLExpress2008R2\en\ folder.
8. Close and re-open Visual Studio. You should be able to go to the Publish tab of your application and click on the Prerequisites button and see “SQLExpress2008R2” in the list.

Do NOT remove the SqlExpressChk.exe file from the \SQLExpress2008R2\ folder, or the eula.rtf from the \SQLExpress2008R2\en\ folder.

If you’re using ClickOnce deployment, don’t forget that it does not install updates to the prerequisites automatically – it only updates the ClickOnce application. You will either have to have your customers install the prerequisite before they upgrade the ClickOnce application (just ask them to run the setup.exe again), or programmatically uninstall and reinstall the application for them, including the new prerequisite. (The code for that is in this MSDN article.)

How do I programmatically find the deployed files for a VSTO Add-In?

You can use ClickOnce deployment to install Office Add-ins for Office 2007 and Office 2010. It is very similar to deploying a desktop application, but not identical. With all types of ClickOnce deployments, you may include resources that you need to access programmatically. Files with a file extension of .xml, .mdf, and .mdb are assumed to be data and are deployed by default to the ApplicationDeployment.CurrentDeployment.DataDirectory, but non-data files will be found in the folder with the deployed assemblies.

With a non-VSTO application, you can programmatically find the location of the deployment by either accessing System.Windows.Forms.Application.StartupPath or by checking the Location of the executing assembly. With a VSTO application, the location of the executing assembly does not match the location of the deployment files.

The dll for a VSTO add-in is copied from the deployment directory into a separate location, and it is loaded by the host application from there. I would guess that this happens whenever you run the host application (such as Outlook), and this is why the Office add-in can be uninstalled, reinstalled, updated, etc., without impacting the host application. The changes don’t take effect until the host application is closed and reopened. So when you retrieve the executing assembly’s location, it points to the dll in the run location, and you can’t use that to track down the deployment files.

So how do you find the location of the deployment? You have to examine the CodeBase property of the executing assembly. This comes across as a URI, so you have to retrieve the LocalPath from the URI. It also includes the file name of the main assembly, so you have to retrieve just the directory name specifically.

Here’s the code in VB:

'Get the assembly information
Dim assemblyInfo As System.Reflection.Assembly = System.Reflection.Assembly.GetExecutingAssembly()

'Location is where the assembly is run from 
Dim assemblyLocation As String = assemblyInfo.Location

'CodeBase is the location of the ClickOnce deployment files
Dim uriCodeBase As Uri = New Uri(assemblyInfo.CodeBase)
Dim ClickOnceLocation As String = Path.GetDirectoryName(uriCodeBase.LocalPath.ToString())

Here’s the code in C#:

//Get the assembly information
  System.Reflection.Assembly assemblyInfo = System.Reflection.Assembly.GetExecutingAssembly();
                    
  //Location is where the assembly is run from 
  string assemblyLocation = assemblyInfo.Location;

  //CodeBase is the location of the ClickOnce deployment files
  Uri uriCodeBase = new Uri(assemblyInfo.CodeBase);
  string ClickOnceLocation = Path.GetDirectoryName(uriCodeBase.LocalPath.ToString());

When you compare these values for a non-VSTO ClickOnce application, the directories are the same. When I run this code for my Outlook Add-In, I get these values:

assemblyLocation =

C:\Users\Robin\AppData\Local\assembly\dl3\VBJZ5WH8.6NJ\HRZA3JXN.LVG\b0520efe\3a5b99ef_2e21cb01\GoldMail Outlook Add-In.DLL

ClickOnceLocation =

C:\Users\Robin\AppData\Local\Apps\2.0\ZMBZ82EH.TDG\WHXVWE4L.GZ7\gold..vsto_7a251ffffc558391_0002.0000_10ff9c34a357cc30

If you’ve ever looked at the ClickOnce cache, the ClickOnceLocation will be familiar to you, being in the same format as and location as other types of ClickOnce applications.

So the assemblyLocation is where the dll is actually being run from by the hosting application (Outlook in this case), and the ClickOnceLocation is the location of the other deployment files. Any files that you deploy with your VSTO add-in and want to access programmatically can be found there.

MIME Types for ClickOnce deployment

When you are hosting a ClickOnce deployment on a webserver, you need have certain MIME types defined so the server knows how to handle the files. You can host a ClickOnce deployment on any server regardless of the operating system. So you can host a ClickOnce deployment on an Apache server just as easily as a server running Microsoft Windows Server. You just need to set up the right MIME types.

When you install the .NET Framework, it registers the MIME types automatically. This is why you don’t have to set up MIME types if you install IIS on your desktop machine and test your deployments by deploying to localhost. Carrying that forward, if you have the .NET Framework installed on your server, the MIME types should already be registered.

This is generally one of the first things to check when you’re having problems downloading the deployment. A definite sign that your MIME types are not set up correctly is if your customers try to install the application and it shows the XML of the deployment manifest (the .application file) in Internet Explorer rather than installing the application.

Here are the basic MIME types you need for every ClickOnce deployment:

.application –> application/x-ms-application
.manifest –> application/x-ms-manifest
.deploy –> application/octet-stream

If you are targeting .NET 3.5 or .NET 4.0, you need these as well:

.msp –> application/octet-stream
.msu –> application/octet-stream

If you are deploying an Office application (VSTO add-in), you need this one:

.vsto –> application/x-ms-vsto

If you are deploying a WPF application, you need these:

.xaml –> application/xaml+xml
.xbap –> application/x-ms-xbap

Click one of these links to see how to set MIME types in IIS 6 or IIS 7.

If your application is hosted on an Apache webserver, you can set up your own MIME types by putting entries in the .htaccess file in the root folder of your deployment. The syntax for adding the MIME types is this:

AddType Mime-type file-extension

For example, for the first three MIME types above, you would add these lines to your .htaccess file:

AddType application/x-ms-application application
AddType application/x-ms-manifest manifest
AddType application/octet-stream deploy

You can create the .htaccess file simply by opening notepad or some other text editor and adding the lines above to it, and saving it with the file name of .htaccess. Then copy it to the root of your deployment folders, and those MIME types will work for that folder and all of its subfolders.

For more information than you ever wanted to know about .htaccess files, check out this article.