Automatic web deployment and updates

[James A. Fortune]

On page 36 of the book:

Advanced C# Programming
McGraw-Hill 2002
Paul Kimmel
ISBN: 0-07-222417-7

he states:

"If you are able to dynamically load and use assemblies, you can take
advantage of thin client programming by loading assemblies over HTTP
connections, which supports automatic deployment and updates of
Windows Forms-based applications."

I understand how Reflection will allow the program to load and explore
assemblies. How much beyond using the web simply to download update
files to a certain directory is he when he talks about 'automatic
deployment and updates'?

Thanks,

James A. Fortune
(e-mail address removed)

 

[Arne Vajhøj]

On page 36 of the book:

Advanced C# Programming
McGraw-Hill 2002
Paul Kimmel
ISBN: 0-07-222417-7

he states:

"If you are able to dynamically load and use assemblies, you can take
advantage of thin client programming by loading assemblies over HTTP
connections, which supports automatic deployment and updates of
Windows Forms-based applications."

I understand how Reflection will allow the program to load and explore
assemblies. How much beyond using the web simply to download update
files to a certain directory is he when he talks about 'automatic
deployment and updates'?

If the assembly is loaded dynamically over the network via HTTP then it
is uptodate every time the app starts (assuming that the location it is
retrieved from is uptodate).

Arne

 

[James A. Fortune]

If the assembly is loaded dynamically over the network via HTTP then it
is uptodate every time the app starts (assuming that the location it is
retrieved from is uptodate).

Arne

Arne,

Thanks for the response. It seems that a self-extracting WinZip file
should work perfectly when it is determined that an update is needed.
If I understand correctly, it's similar to a way I sometimes use to
keep databases up to date. In startup code, if the current version
doesn't match the value from an online data store (such as SQL
Server), I know that the database is out of date.

James A. Fortune
(e-mail address removed)

 

[Arne Vajhøj]

Thanks for the response. It seems that a self-extracting WinZip file
should work perfectly when it is determined that an update is needed.
If I understand correctly, it's similar to a way I sometimes use to
keep databases up to date. In startup code, if the current version
doesn't match the value from an online data store (such as SQL
Server), I know that the database is out of date.

That model will work fine.

Send HTTP request for expected version of DLL, compare that with
current version of DLL, if out of date, then download ZIP file
with new version and tell user to update.

But I don't think that is what the book is talking about. If I read
the text correct (I am not 100% sure, maybe I am just thinking too
much Java), then it is talking about not having the DLL at all
on the client PC, but retrieving it via HTTP every time it has
to be loaded.

Arne

 

[James A. Fortune]

That model will work fine.

Send HTTP request for expected version of DLL, compare that with
current version of DLL, if out of date, then download ZIP file
with new version and tell user to update.

But I don't think that is what the book is talking about. If I read
the text correct (I am not 100% sure, maybe I am just thinking too
much Java), then it is talking about not having the DLL at all
on the client PC, but retrieving it via HTTP every time it has
to be loaded.

Arne

Apps written in C# tend to be much, much smaller than the database
apps I'm accustomed to, so the possibility of downloading a file each
time is not as much of a shock as it first seemed. Your guess
satisfies the idea of automatic updates and fits in with the context
of the quoted text, so it seems reasonable. However, for a DLL of any
significant size, I think the conditional download you outlined is
better. Thanks for your input.

James A. Fortune
(e-mail address removed)

 

[Arne Vajhøj]

Apps written in C# tend to be much, much smaller than the database
apps I'm accustomed to, so the possibility of downloading a file each
time is not as much of a shock as it first seemed. Your guess
satisfies the idea of automatic updates and fits in with the context
of the quoted text, so it seems reasonable. However, for a DLL of any
significant size, I think the conditional download you outlined is
better.

My experience is:

dll byte size = 15 * raw line count source

so 10000 lines will only be around 150 KB, which is pretty
small after today's standard.

Anyway the technique of loading that way is not very much
used in .NET, so not much point in focusing on it anyway.

Arne

 

[James A. Fortune]

My experience is:

dll byte size = 15 * raw line count source

so 10000 lines will only be around 150 KB, which is pretty
small after today's standard.

Anyway the technique of loading that way is not very much
used in .NET, so not much point in focusing on it anyway.

Arne

Arne,

Some of my database front ends are over 40 MB, so it will take awhile
for me to get used to the sizes of typical C# DLL's. Thanks for the
rule of thumb for estimating DLL sizes. I see your point better now.
Also, thanks for giving me an idea about that technique's frequency of
use. I don't anticipate the need for Reflection for any of the
projects on my current list of things to program, but it's nice to
know that it's there and how it can be used, even if the author had to
stretch a little into an uncommon use to illustrate its potential.

James A. Fortune
(e-mail address removed)