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 a video that explains this process in detail, complete with screenshots. There is a summary below.
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.
Tags: ClickOnce, WindowsAzure
RobinDotNet's Blog 
February 14, 2011 at 3:20 pm |
[…] How to host a ClickOnce deployment in Azure Blog Storage (Robindotnet) […]
February 14, 2011 at 4:51 pm |
[…] Read this article: How to host a ClickOnce deployment in Azure Blob Storage … […]
February 18, 2011 at 3:35 am |
Can we use private blobs instead of public blobs. If so how authentication need to be implemented?
February 22, 2011 at 1:31 pm |
Yes, you can. This is not something I can explain in a couple of sentences. There are whole articles written about this topic. This should get you started. After that, Bing is your friend.
July 18, 2011 at 5:49 pm |
[…] in Azure for pennies per month By robindotnet 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 […]
July 20, 2011 at 2:06 pm |
[…] in Azure for pennies per month in a 7/18/2011 post: 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 […]
August 8, 2011 at 10:17 pm |
Great post. Really got me going quickly!
Regarding using private blobs instead of public… I have been trying to get this to work. I now know how to set the access policy on my blobs and containers and how to create a signed url to access the files. This much works great… right up to the point where I plug in my signed url into a browser and the publish.htm file is rendered. However, when I try clicking the Install button, it fails immediately because the ClickOnce deployment process can’t find the other deployment files. I’m pretty sure this is because it is trying to retrieve those files without authentication i.e. without using the signed URL.
I had hoped that by specifying the full signed URL as the deployment url when building the deployment files locally, I could coerce the ClickOnce deployment process into using the signed URL for each file retrieval, but it seems that ClickOnce is ignoring the authentication parameters and just trying to access the files directly without authentication.
Are you sure that this can actually be made to work? Unless I’m missing something, It seems that ClickOnce will need to be updated to know about Azure Access Policy signed URL parameters, or at least pass through the parameters when attempting to retrieve the files it needs for the deployment.
Rick.
August 8, 2011 at 10:43 pm |
Yes, indeed, it worked right off the bat for me. For my security on the blobs, I have the ACLs on the container set so the container is private but the blobs are public. I figured it meant that you can see the blobs if you have a link, but people can’t browse the folder. I don’t think you can get this to work with private blobs, because you would have to access them and pass a security key with them (or whatever it’s called, you know what I mean).
August 9, 2011 at 11:47 am |
Sorry, I didn’t make myself very clear. When I asked whether “this can be made to work”, I was referring to Biju’s comment from back in February, where he asked if we could use private blobs. You said “yes” at that time, but it now seems like you believe (as I do) that it’s not currently possible to make ClickOnce work with private blobs because the ClickOnce process would need to pass through the “signature” argument (security key) on each subsequent retrieval. I don’t see any reason why it couldn’t do this, but it appears that it doesn’t. Hopefully Microsoft is watching your blog and will implement that in a future update of ClickOnce.
For now, I agree that as long as the container private and only the blobs themselves are public, it’s not likely that anyone who shouldn’t know about the application would ever be able to find it anyway. So it’s fairly secure in terms of “security by obscurity”, but prefer not to rely on that too much. Hopefully we will be able to use private blobs in the future.
It occurs to me that I could further improve security by giving my container a long random name (such as a GUID) and specifying HTTPS for my storage account. E.G. rather than just http://storageaccountname.blob.core.windows.net/clickonce/publish.htm, the URL would look like: https://storageaccountname.blob.core.windows.net/clickonce936F6DEA-3F25-4BAA-A5DD-AEC064DCCECD/publish.htm. I’m no security expert, but I don’t offhand see how that could be hacked into easily. It seems almost as good as using a private blob, but without some of the finer features such as the ability to specify different types of access for different users, expiration dates etc.
September 7, 2011 at 11:38 pm |
I know a lot more about Azure Blob Storage now than I did back in January. 🙂 I do believe the blobs have to be public, but the container can be private. You COULD change the file name of the publish.htm and maybe even the deployment manifest (.application — you couldn’t change the file extension), but you’d have to re-sign the manifest after doing so, using mage or mageUI.
July 27, 2012 at 9:08 pm |
Hi Robin,
Thank you for this article. I know it’s been a long time since you published this article, but I was wondering –
do you have any thoughts on how to sign the deployment (using a code-sign certificate) to avoid the annoying security warning?
Thanks,
Assaf
July 28, 2012 at 1:32 pm |
Hi Assaf,
We sign the deployment when we publish it. You can specify it in Visual Studio in the Signing tab.
Robin
October 11, 2012 at 7:58 am |
Very good article thanks, I tried using the azure storage explorer because its free:) everything was great until i tried to upload the application files dir, it does not do that so I had to revert to using clodberry
December 10, 2013 at 2:51 pm |
How do I get this to work for a VSTO excel addin?
I get the install working, but updates complain about some file in a place within my visual studio solution!
Normal install from a network share works fine.
Has anyone managed to publish (and update) a VSTO addin?
Lots of Greetings!
Volker
February 21, 2014 at 3:06 pm |
Be sure the file it is complaining about is being deployed with the rest of the files.
January 20, 2014 at 7:57 am |
Thanks very much. Very clearly written. I just implemented such a solution and plan to use this in many apps. A self updating app is really cool and a must in today’s environments.
I actually am very interested in having it check every few hours as many times people leave such apps running for long periods of time. I’m interested in learning how to stage deployment or roll back to a prior version in case of problems.
I should mention that I found that one step that was required to make this work for me was to set the publish directory at the bottom of the Publish…Updates… page (e.g. Update location (if different) to match the blob storage http location. I noticed I was getting File not found errors and that was corrected.
This only came into play when I published to a different machine because I think the manifest points to the local directory (C:/E:) . It was very confusing because it worked on my development machine (probably because the same files were in the directory prior to uploading via Cerebrata.
February 21, 2014 at 2:50 pm |
If you want to check for updates, you can do it programmatically instead of relying on the customer (or in addition). I don’t know what you mean by “stage deployment” — can you be more specific? You can’t install two apps with the same assembly & deployment name. You can change those two values and people can run them side-by-side. The only way to roll back is if you are not pushing the updates as required. The app will install whatever version is specified by the .application file on the server. So to roll it back, just copy the .application file (deployment manifest) from the previous “application files_a_b_c_d” folder and put it in the root.
February 21, 2014 at 3:14 pm |
Perhaps I used the wrong word “stage” but I want to “roll out gradually” and be able to gracefully roll back in case of problems. I also want to force all users to upgrade and will look at inserting a programmatic check every few hours.
Since I wrote my prior message, I have become more used to doing this. One area where I ran into problems was the ability to retain settings (e.g. workstation id, personal settings getting overwritten each time I published). I got that working using the App.settings and now seems to be working..
If I am reading what you said about rolling back, if I put a previous version back (say v1.16) and the user is running 1.20) it will force them back. I was thinking it would compare to see if your version was < current version and indicate you need to update. It is good to know it goes both ways.
February 21, 2014 at 3:18 pm |
I don’t know that anything is graceful with ClickOnce. There’s always a risk when you’re rolling stuff back — for example, if there are database changes involved, you’re in trouble.
Also, you don’t compare versions to see if you need to update. You call the ClickOnce API and ask if there’s an update, and it will tell you yes. I don’t think it gives you the version number.
As for settings, if they are settings you are writing for the user, you really want to think about not putting them in the ClickOnce deployment itself. Checked out this article about keeping your data safe during updates.
If the settings don’t change, and go with the deployment, it’s fine to include them.
February 21, 2014 at 3:30 pm |
Is there a way to automate the Cerebrata publish to Azure? When I publish, it puts the current copy in a folder on my desktop. I then have to load Cerebrata, select all files in that folder and navigate to my blob container and paste to my Azure blob storage. Each time I have to specify overwrite. do for all etc… Not a big deal but seems like you should be able to do this with a simple command like “copy x to y” or as part of the publish process.
July 17, 2014 at 7:48 pm |
[…] wrote a blog article showing how you can host your Click Once deployment in Azure blob storage very inexpensively. (It’s even cheaper now.) The problem is you have to get your deployment up to […]
September 16, 2014 at 6:04 pm |
[…] top of that, RobinDotNet has a wonderful blog entry walking you through the […]