What is the best way to update applications?

[jim]

Let's just say that I am foolish enough to code and distribute a free app to
the general public over the web.

What is the best (cheapest, smallest bandwidth, easiest to code) way to
publish updates to my .Net application?

I'd like to save bandwidth by only updating the changed portions if
possible.

Thanks!

jim

 

[rowe_newsgroups]

Let's just say that I am foolish enough to code and distribute a free app to
the general public over the web.

What is the best (cheapest, smallest bandwidth, easiest to code) way to
publish updates to my .Net application?

I'd like to save bandwidth by only updating the changed portions if
possible.

Thanks!

jim

It depends a lot on your architecture and deployment. ClickOnce offers
automatic update functionality, but I have never used it so I can't be
of too much help there. Also, if you architectured the program with
dll's you could just release a new version of the dll. Besides that,
here are a few links you might want to read:

http://www.codeproject.com/KB/install/dotnetpatching.aspx
http://www.codeproject.com/KB/IP/ApplicationUpdate.aspx
http://www.codeproject.com/KB/install/DDayUpdate_Part1.aspx

I haven't read them, but they seem to be dealing with your topic.

Thanks,

Seth Rowe [MVP]

 

[Peter Ritchie [C# MVP]]

Cheapest is probably ClickOnce, it also requires no coding.

I don't know what sort of bandwidth it uses; but that would involve
comparing to another method of updating anyway.

 

[Nicholas Paldino [.NET/C# MVP]]

Jim,

I don't think ClickOnce (as mentioned in other threads) is a good idea
here. The reason for that is that you mentioned you are going to distribute
a free app over the web.

Because of this, you might run into issues in trying to public a
ClickOnce app on your hosting server (if you don't have a dedicated server,
you might have restrictions preventing you from publishing it).

Also, the model for upgrading the app becomes cumbersome. If you have
multiple versions, and you only want to distribute the changed portions, you
will have to make a patch for every upgrade of every previous version to the
current version.

In other words, if you released version 1.1, 1.2 and 1.3, and someone
installs 1.1, and wants to install version 1.3, you have to provide a
specific patch from 1.1 to 1.3, as well as 1.2 to 1.3.

Expecting the user to go through the patches manually will create a very
ugly user experience, and deter a number of people (it would deter me).

Because of that, for the audience you are targeting, it would probably
be a better user experience if you created an install package which will
remove previous versions of your program, and then do a full install of the
current version the installer represents.

 

[jim]

Jim,

I don't think ClickOnce (as mentioned in other threads) is a good idea
here. The reason for that is that you mentioned you are going to
distribute a free app over the web.

Because of this, you might run into issues in trying to public a
ClickOnce app on your hosting server (if you don't have a dedicated
server, you might have restrictions preventing you from publishing it).

Also, the model for upgrading the app becomes cumbersome. If you have
multiple versions, and you only want to distribute the changed portions,
you will have to make a patch for every upgrade of every previous version
to the current version.

In other words, if you released version 1.1, 1.2 and 1.3, and someone
installs 1.1, and wants to install version 1.3, you have to provide a
specific patch from 1.1 to 1.3, as well as 1.2 to 1.3.

Expecting the user to go through the patches manually will create a
very ugly user experience, and deter a number of people (it would deter
me).

Because of that, for the audience you are targeting, it would probably
be a better user experience if you created an install package which will
remove previous versions of your program, and then do a full install of
the current version the installer represents.

I agree.

I think that a bootstrap application that mimics the actual appliation's UI
and performs the uninstall/install for the user would be the least
disruptive in perfroming updates to the app.

The only problem I have with this is that we will be doing LOTS of additions
in the first 3-6 months. Updates will be ready for release almost every
week (if the projected schedule holds up) - NOT including hotfixes to fix
what we screw up with this fast paced development cycle.

Most of the changes will be to our toolbox - adding more and more tools...as
fast as our bloody nubs can peck out and test the code.

Our toolbox options will change with user requests and with how the users
are seen to be using the application. It will be quite dynamic as compared
to other desktop applications.

So, we need to strike a balance. We have to get something out now (if you
wit until it is perfect it will never ship), and we have to be able to add
tools (and the code behind them) to our toolbox at will and drop hotfixes
like....well...like they're hot.

The user experience is the most important thing. That's the reason for the
constant updates and the reason I am leaning towards a bootstapped launcher.
But, I also don't want to delay the user from opening the app *too much*
with the constant updates.

Ahhh.....programming for the masses. You gotta love it.

jim

 

[jim]

Cheapest is probably ClickOnce, it also requires no coding.

I don't know what sort of bandwidth it uses; but that would involve
comparing to another method of updating anyway.

ClickOnce is the cheapest. Unfortunately it is also the msot restricitive
in terms of the .Net security model.

And, asking users to slosh through arcane instructions (to most of them
anyway) just to enable an app to save a file to the hard drive is not
something that we are comfortable with.

ClickOnce was a great idea (almost wet myself when I first heard of the
basic concept). Unfortunately, reality set in quickly upon realizing just
how basic the apps are that you can send over the internet with ClickOnce
without requiring end users to mess with stuff they are as apt to screw up
as get right.

Whatever happens, we don't want to be tagged as "the people that messed up
my PC" is a user screws around with .Net security and doesn't get it right.

Microsoft gets more thing *almost* right than any other company....ever.
And that's a shame.

Heck - activeX controls are more powerful (and easier to host) than
ClickOnce apps over the web.

jim

 

[RobinS]

It depends a lot on your architecture and deployment. ClickOnce offers
automatic update functionality, but I have never used it so I can't be
of too much help there. Also, if you architectured the program with
dll's you could just release a new version of the dll. Besides that,
here are a few links you might want to read:

http://www.codeproject.com/KB/install/dotnetpatching.aspx
http://www.codeproject.com/KB/IP/ApplicationUpdate.aspx
http://www.codeproject.com/KB/install/DDayUpdate_Part1.aspx

I haven't read them, but they seem to be dealing with your topic.

Thanks,

Seth Rowe [MVP]

I can speak for ClickOnce. It handles incremental updates automatically.
That's one of the main reason why my company uses it.

RobinS.
GoldMail, Inc.

 

[RobinS]

ClickOnce is the cheapest. Unfortunately it is also the msot restricitive
in terms of the .Net security model.

And, asking users to slosh through arcane instructions (to most of them
anyway) just to enable an app to save a file to the hard drive is not
something that we are comfortable with.

ClickOnce was a great idea (almost wet myself when I first heard of the
basic concept). Unfortunately, reality set in quickly upon realizing just
how basic the apps are that you can send over the internet with ClickOnce
without requiring end users to mess with stuff they are as apt to screw up
as get right.

Whatever happens, we don't want to be tagged as "the people that messed up
my PC" is a user screws around with .Net security and doesn't get it
right.

Microsoft gets more thing *almost* right than any other company....ever.
And that's a shame.

Heck - activeX controls are more powerful (and easier to host) than
ClickOnce apps over the web.

jim

Obviously you needed to read Brian Noyes' ClickOnce book. We are using
ClickOnce very successfully. It installs the application into the user's
profile, so it does not mess with anything else on the user's computer, and
can't mess anything up. We are deploying part of DirectX with our
application, and it does not conflict with the user's version in any way,
shape, or form. You just have to know how to get it done.

RobinS.
Goldmail, Inc.

 

[RobinS]

You are wrong about the updating capabilities and methodology of ClickOnce.

With ClickOnce, you deploy your updated versions to the same url as the
original, and when the user runs the application again, it checks and picks
up the latest version. You deploy the whole thing every time to your
webserver. When installing, ClickOnce checks the versions of any and all
included files, and only copies over the new ones that it needs.

You end up with multiple versions on your web server, but the most current
one is myapp.application, and that tells which version to actually install.
This means you can easily go back a version by copying one of the versioned
application files (like myapp.application_10_1_1_1, named that way bye
default), and you can remove old versions as you deploy more of them.

You can make the updates optional or required. You can make 6 updates in a
row optional, and then make the next one required. It's very flexible. If
you make them optional, it will come up and ask the user if he wants to
install it, or skip this version.

If you have problems, and you're putting out optional versions, the user can
even revert back one version using "add/remove programs".

ClickOnce by default deploys the files with the file extension "deploy", and
knows what to do with them when the user runs the deployment, which removes
the problem many web servers have with allowing files ending in dll, exe,
etc.

I recommend the OP try it out. It has been grossly misrepresented here. For
more info about ClickOnce, check out Brian Noyes' book about it -- it is
hugely useful.

RobinS.
GoldMail, Inc.
------------------------------------

Jim,

I don't think ClickOnce (as mentioned in other threads) is a good idea
here. The reason for that is that you mentioned you are going to
distribute a free app over the web.

Because of this, you might run into issues in trying to public a
ClickOnce app on your hosting server (if you don't have a dedicated
server, you might have restrictions preventing you from publishing it).

Also, the model for upgrading the app becomes cumbersome. If you have
multiple versions, and you only want to distribute the changed portions,
you will have to make a patch for every upgrade of every previous version
to the current version.

In other words, if you released version 1.1, 1.2 and 1.3, and someone
installs 1.1, and wants to install version 1.3, you have to provide a
specific patch from 1.1 to 1.3, as well as 1.2 to 1.3.

Expecting the user to go through the patches manually will create a
very ugly user experience, and deter a number of people (it would deter
me).

Because of that, for the audience you are targeting, it would probably
be a better user experience if you created an install package which will
remove previous versions of your program, and then do a full install of
the current version the installer represents.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Let's just say that I am foolish enough to code and distribute a free app
to the general public over the web.

What is the best (cheapest, smallest bandwidth, easiest to code) way to
publish updates to my .Net application?

I'd like to save bandwidth by only updating the changed portions if
possible.

Thanks!

jim

 

[Ian Semmel]

Let's just say that I am foolish enough to code and distribute a free
app to
the general public over the web.

What is the best (cheapest, smallest bandwidth, easiest to code) way to
publish updates to my .Net application?

I'd like to save bandwidth by only updating the changed portions if
possible.

Thanks!

jim

Well, two out of three ain't bad.

The cheapest and easiest is to re-install the entire app. This is the
way most applications are updated via the web.

If you make sure that your website gives detailed information on the
reason for a new release and whether it is critical or not, the users
can decide whether it is worth upgrading. Other solutions are going to
increase the workload (and potential for error) on you, and more
importantly, the user.

..NET apps aren't that big compared to native code.

 

[jim]

Obviously you needed to read Brian Noyes' ClickOnce book. We are using
ClickOnce very successfully. It installs the application into the user's
profile, so it does not mess with anything else on the user's computer,
and can't mess anything up. We are deploying part of DirectX with our
application, and it does not conflict with the user's version in any way,
shape, or form. You just have to know how to get it done.

RobinS.
Goldmail, Inc.

Got a copy..... Upon looking at the code security section, it is going to
take a few reads to get down to the simple "How do I....." that I prefer.

For example "How do I enable full trust for my ClickOnce application -
without scaring the crap out of potential new users to both my app and
clickonce apps?" "How do I package 3rd party controls with my ClickOnce
application?" "How do I......."

Honestly, I don't give a rat's ass about the why and internal workings of
things unless I absolutely MUST know them. I am more interested in results.
Quick, verifiable, reproducable results.

I am certain that Brian is an authority on the subject of ClickOnce. What
Brian needs is an authority on simple, powerful writing that allows busy
people to scan and do as quickly as possible - especially with the harried
schedules of developers and non-developers that are tossed into that role.

My idea of the perfect book is a 2 part volume that has a "How do I...."
Part 1 for busy people that "just need it to work, and need it to work
now" - this is for the people hovered over by bosses that think writing code
is like writing an email. And, a "This is what you just did...." Part 2
that takes each "How do I..." in Part 1 and really gets into the how and why
of it. This section is for people that really like to know (and have the
luxury of extra time to study) the ins and outs of everything they do - and
for fixing the apps forced by those bosses that make Part 1 a neccessity.

At this point, it seems quicker to just write the damned thing as an
installable application and deply entire installs as needed.

It is not the man that knows it all that is king.....but the man that can
explain it to all such that they understand it quickly and for good.

jim

 

[Tony K]

How does Microsoft do it? They have/release updates all the time. How can
we, as programmers, determine if a user has updated a piece of software
already whether it be an .exe or .dll?

Tony K

Jim,

I don't think ClickOnce (as mentioned in other threads) is a good idea
here. The reason for that is that you mentioned you are going to
distribute a free app over the web.

Because of this, you might run into issues in trying to public a
ClickOnce app on your hosting server (if you don't have a dedicated
server, you might have restrictions preventing you from publishing it).

Also, the model for upgrading the app becomes cumbersome. If you have
multiple versions, and you only want to distribute the changed portions,
you will have to make a patch for every upgrade of every previous version
to the current version.

In other words, if you released version 1.1, 1.2 and 1.3, and someone
installs 1.1, and wants to install version 1.3, you have to provide a
specific patch from 1.1 to 1.3, as well as 1.2 to 1.3.

Expecting the user to go through the patches manually will create a
very ugly user experience, and deter a number of people (it would deter
me).

Because of that, for the audience you are targeting, it would probably
be a better user experience if you created an install package which will
remove previous versions of your program, and then do a full install of
the current version the installer represents.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Let's just say that I am foolish enough to code and distribute a free app
to the general public over the web.

What is the best (cheapest, smallest bandwidth, easiest to code) way to
publish updates to my .Net application?

I'd like to save bandwidth by only updating the changed portions if
possible.

Thanks!

jim

 

[RobinS]

Got a copy..... Upon looking at the code security section, it is going to
take a few reads to get down to the simple "How do I....." that I prefer.

For example "How do I enable full trust for my ClickOnce application -
without scaring the crap out of potential new users to both my app and
clickonce apps?" "How do I package 3rd party controls with my ClickOnce
application?" "How do I......."

Honestly, I don't give a rat's ass about the why and internal workings of
things unless I absolutely MUST know them. I am more interested in
results. Quick, verifiable, reproducable results.

I am certain that Brian is an authority on the subject of ClickOnce. What
Brian needs is an authority on simple, powerful writing that allows busy
people to scan and do as quickly as possible - especially with the harried
schedules of developers and non-developers that are tossed into that role.

My idea of the perfect book is a 2 part volume that has a "How do I...."
Part 1 for busy people that "just need it to work, and need it to work
now" - this is for the people hovered over by bosses that think writing
code is like writing an email. And, a "This is what you just did...."
Part 2 that takes each "How do I..." in Part 1 and really gets into the
how and why of it. This section is for people that really like to know
(and have the luxury of extra time to study) the ins and outs of
everything they do - and for fixing the apps forced by those bosses that
make Part 1 a neccessity.

At this point, it seems quicker to just write the damned thing as an
installable application and deply entire installs as needed.

It is not the man that knows it all that is king.....but the man that can
explain it to all such that they understand it quickly and for good.

jim

Maybe in order to understand how to implement it, you need the background
info he's providing in the book. Or you need to learn to skim. I skipped the
chapter on security completely the first time I read the book.

I deploy our app with full trust. Buy a security certificate and sign your
deployment so it doesn't say "unknown publisher".

For 3rd party controls, assuming you have the dll's and that's what you want
to deploy, I put mine into a folder called something like "3rdpartydlls"
under the main project. I then made sure my references pointed to those
specific dll's, and not to the same thing elsewhere on my machine. Then I
set "Copy Local" to true on the reference. The entry that shows up under the
folder in VS should be set to have a build action of "None" and
copy-to-output-directory set to "Do not copy". It will be included because
it is referenced.

Frankly, I found Brian's book very helpful, and was able to skim it for what
I needed to know, and go back for the more complicated stuff later as
difficulties arise. If you're not patient enough to do that, your loss.
Maybe you should write your own book. It's harder than you think.

RobinS.
GoldMail, Inc.

 

[jim]

Maybe in order to understand how to implement it, you need the background
info he's providing in the book. Or you need to learn to skim. I skipped
the chapter on security completely the first time I read the book.

I deploy our app with full trust. Buy a security certificate and sign your
deployment so it doesn't say "unknown publisher".

For 3rd party controls, assuming you have the dll's and that's what you
want to deploy, I put mine into a folder called something like
"3rdpartydlls" under the main project. I then made sure my references
pointed to those specific dll's, and not to the same thing elsewhere on my
machine. Then I set "Copy Local" to true on the reference. The entry that
shows up under the folder in VS should be set to have a build action of
"None" and copy-to-output-directory set to "Do not copy". It will be
included because it is referenced.

Frankly, I found Brian's book very helpful, and was able to skim it for
what I needed to know, and go back for the more complicated stuff later as
difficulties arise. If you're not patient enough to do that, your loss.
Maybe you should write your own book. It's harder than you think.

We were justsuitting around talking about that. I do think I'll try my hand
at writing my own book

<my contents snipped on the advice of counsel>

Results are what counts - not how much you memorize or can regurgitate on a
test. The world is results-based. They don't care what you know...it's
what you can do for them that feeds the ducks.

jim

 

[RobinS]

We were justsuitting around talking about that. I do think I'll try my
hand at writing my own book

<my contents snipped on the advice of counsel>

Results are what counts - not how much you memorize or can regurgitate on
a test. The world is results-based. They don't care what you know...it's
what you can do for them that feeds the ducks.

jim

Yep. Reading Brian's book provided me with enough information to
successfully deploy my company's product using ClickOnce.

Post back when you get your book published and I will buy it.

RobinS.

 

[ShaneO]

Well, two out of three ain't bad.

Actually, my experience has proven that you'd obtain 3 out of 3 using
ClickOnce!

Apart from what's already been mentioned, ClickOnce will only download
what needs to be updated. Some of my applications use 3rd party DLL's
etc and, because of this, these application can blow-out to greater than
30 or 50MB for the initial installation. Once the application is
installed, I've found that subsequent updates only download the
"changed" items, and as this is usually just my main code, ends-up being
less than 2MB. I have many Users who have low-bandwidth Internet
connections, and these Users are very pleased that updates take no time
at all to complete.

Yes, ClickOnce would be my recommendation as it meets all of your
requirements. I distribute my apps and updates this way and would never
consider any of the other options being promoted, and I have tried other
options. Those that are criticising ClickOnce obviously haven't ever
used it!

ShaneO

There are 10 kinds of people - Those who understand Binary and those who
don't.

 

[RobinS]

If you use ClickOnce, you can force the user to update by setting a minimum
version.
RobinS.
---------------------------

How does Microsoft do it? They have/release updates all the time. How
can we, as programmers, determine if a user has updated a piece of
software already whether it be an .exe or .dll?

Tony K

Jim,

I don't think ClickOnce (as mentioned in other threads) is a good idea
here. The reason for that is that you mentioned you are going to
distribute a free app over the web.

Because of this, you might run into issues in trying to public a
ClickOnce app on your hosting server (if you don't have a dedicated
server, you might have restrictions preventing you from publishing it).

Also, the model for upgrading the app becomes cumbersome. If you have
multiple versions, and you only want to distribute the changed portions,
you will have to make a patch for every upgrade of every previous version
to the current version.

In other words, if you released version 1.1, 1.2 and 1.3, and someone
installs 1.1, and wants to install version 1.3, you have to provide a
specific patch from 1.1 to 1.3, as well as 1.2 to 1.3.

Expecting the user to go through the patches manually will create a
very ugly user experience, and deter a number of people (it would deter
me).

Because of that, for the audience you are targeting, it would probably
be a better user experience if you created an install package which will
remove previous versions of your program, and then do a full install of
the current version the installer represents.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Let's just say that I am foolish enough to code and distribute a free
app to the general public over the web.

What is the best (cheapest, smallest bandwidth, easiest to code) way to
publish updates to my .Net application?

I'd like to save bandwidth by only updating the changed portions if
possible.

Thanks!

jim