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

On Jan 30, 3:43 am, "jim" <j...@home.net> wrote:
> 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/instal...tpatching.aspx
http://www.codeproject.com/KB/IP/ApplicationUpdate.aspx
http://www.codeproject.com/KB/instal...ate_Part1.aspx

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

Thanks,

Seth Rowe [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.

--
Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote.
http://www.peterRitchie.com/blog/
Microsoft MVP, Visual Developer - Visual C#


"jim" wrote:

> 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.

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 Removed)

"jim" <(E-Mail Removed)> wrote in message
news:YMWnj.62733$(E-Mail 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
>

"Nicholas Paldino [.NET/C# MVP]" <(E-Mail Removed)> wrote in
message news:(E-Mail Removed)...
> 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 Removed)

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

"Peter Ritchie [C# MVP]" <(E-Mail Removed)> wrote in message
news:AED17E57-7DCA-4AA6-8640-(E-Mail Removed)...
> 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.
>
> --
> Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote.
> http://www.peterRitchie.com/blog/
> Microsoft MVP, Visual Developer - Visual C#

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

"rowe_newsgroups" <(E-Mail Removed)> wrote in message
news:9a7eab19-6781-4259-af49-(E-Mail Removed)...
> On Jan 30, 3:43 am, "jim" <j...@home.net> wrote:
>> 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/instal...tpatching.aspx
> http://www.codeproject.com/KB/IP/ApplicationUpdate.aspx
> http://www.codeproject.com/KB/instal...ate_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.

"jim" <(E-Mail Removed)> wrote in message
news:z_7oj.86285$L%(E-Mail Removed)...
>
> "Peter Ritchie [C# MVP]" <(E-Mail Removed)> wrote in message
> news:AED17E57-7DCA-4AA6-8640-(E-Mail Removed)...
>> 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.
>>
>> --
>> Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote.
>> http://www.peterRitchie.com/blog/
>> Microsoft MVP, Visual Developer - Visual C#
>
> 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.

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.
------------------------------------

"Nicholas Paldino [.NET/C# MVP]" <(E-Mail Removed)> wrote in
message news:(E-Mail Removed)...
> 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 Removed)
>
> "jim" <(E-Mail Removed)> wrote in message
> news:YMWnj.62733$(E-Mail 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
>>
>
>

"jim" <(E-Mail Removed)> wrote in message
news:YMWnj.62733$(E-Mail 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

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.