problems with .NET deployment methods

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Tim Mackey - 23 Oct 2003 11:41 GMT

Hi,
Please disregard my last post. I found the meaning of oldversion and
newversion in the docs.
this post is long-ish but its quite a fundamental issue that i'm
struggling to find an appropriate solution in .NET for. any help is
GREATLY appreciated.

i'm still a little unsure what is the best way for me to deploy
updates to my winforms app. its an intranet scenario, and i foresee
several updates over the coming months and hence i want the client
apps to self-update whenever i put new dlls on the intranet web
server. i've tried several scenarios but found problems with each:

1. smart client deployment: a COM component i use caused exceptions
and wouldn't load through IExec. so i opted for a .MSI installation.
also, smart clients never download config files automatically when
they change.

3. Assembly.LoadFrom: i'd have to re-write all the 35k lines of code
in the app using reflection, which to me is not pretty programming.
and it would make updates much slower to develope, without the
advantage of intellisense etc.

3. BITS: its completely UI-less, i don't want users waiting even 20
seconds for a large dll do come through the pipes. also, since my app
is server-dependant, i need to force the client apps to update if the
server has changed, BITS won't garauntee an update every time the app
runs, because it only uses idle bandwidth.

4. Custom file udpater: i've developed a simple dll updater via web
services, that runs on start up of the client app, and checks for new
assemblies on the server and streams them to the client machines. this
works, quite nicely too, with a progress bar, and the size of the file
being downloaded. however, when i build an updated dll, i have to give
it a new version no. to be picked up by the web service. this breaks
the version dependency on other assemblies, so i need to re-build all
the depending assemblies and get the client app to download them all
together. this is not a problem, but wasted downloads perhaps, when
the updated assembly is in fact backwards compatible and the other
assemblies shouldn't need to be downloaded. am i missing some other
simpler way of getting clients to update themselves? i the codebase
element in dependent assemblies of app.config, but i'm not sure if
that will trigger an update for a new version.

many thanks for reading this, and for any advice.
tim mackey.

/* 67d0ebfec70e8db3 */

Reply to this Message

Paul Hetherington - 23 Oct 2003 23:18 GMT

I havn't tried smartclient with COM yet, but have with pure managed samples.
You mentioned that this is in an Intranet environment.
Did you try upgrading the .net security zone settings for the Intranet Zone?
You also might still need to register the COM component after it is 'smart'
deployed to the client's machine.

-paul

Reply to this Message

Dave - 24 Oct 2003 10:55 GMT

When you sign assemblies with a strong name then by default the assemblies
that reference them require a specific version - this can be a benefit or a
hindrance, depending on your needs. You can redirect the bindings through
various means (app config, machine config, hooking the AssemblyResolve
event, etc) or you can ensure the correct versions are all present when your
app is run.

The approach I took was to ensure the correct version of all assemblies were
always downloaded to the client machine. I could not use the default
mechanism because when using LoadFrom to a server the runtime uses a http
command to update the assembly only if the time-date stamp is later then the
time stamp on the copy in the local download cache - if the time stamp was
not later then it never got downloaded, even if the internal version
changed. This was unsuitable for our needs.

I wrote a small service that returned a list of file names with the versions
and time-date stamps to the client, and a layer on the client that copied
the files from the server to the client if the files were different. The
advantage here is that it could copy whatever it needed, including data
files, config files, assemblies, etc. and could recurse into subdirectories
as needed. This client-side layer currently runs when the user initially
connects to the server but it could also be run from a service that
periodically checked for updates to files on the server. Once all the files
were present I created an appdomain, pointed the appbase to the subdirectory
where the files were copied, and did a LoadFrom and then invoked a method
in one of the assemblies.

There's more to it then that but that's the basic idea. It's worked pretty
well for us to date.

> Hi,
> Please disregard my last post. I found the meaning of oldversion and
[quoted text clipped - 44 lines]
>
> /* 67d0ebfec70e8db3 */

Reply to this Message

Ice - 24 Oct 2003 15:47 GMT

Inline...

ice

> When you sign assemblies with a strong name then by default the assemblies
> that reference them require a specific version - this can be a benefit or a
> hindrance, depending on your needs. You can redirect the bindings through
> various means (app config, machine config, hooking the AssemblyResolve
> event, etc) or you can ensure the correct versions are all present when your
> app is run.

One of the reasons why I chose strong name my assemblies is so that I can
use the strong name as a security identifier when using the default smart
client implementation. Are your assemblies strong-named? It would seem to
me that you don't run into security issues with your custom downloader or am
I wrong?

> The approach I took was to ensure the correct version of all assemblies were
> always downloaded to the client machine. I could not use the default
[quoted text clipped - 3 lines]
> not later then it never got downloaded, even if the internal version
> changed. This was unsuitable for our needs.

I'm curious to know how you had a new file with an earlier version? I
understand how it could be done, but what kind of situations prompted this?

> I wrote a small service that returned a list of file names with the versions
> and time-date stamps to the client, and a layer on the client that copied
[quoted text clipped - 59 lines]
> >
> > /* 67d0ebfec70e8db3 */

Reply to this Message

Dave - 25 Oct 2003 01:48 GMT

inline

> One of the reasons why I chose strong name my assemblies is so that I can
> use the strong name as a security identifier when using the default smart
> client implementation. Are your assemblies strong-named? It would seem to
> me that you don't run into security issues with your custom downloader or am
> I wrong?

All of our assemblies are strong named. We originally used LoadFrom
specifying a remote host which caused the assemblies to be loaded into the
internet or intranet security zone. To increase our permission grant we
created a custom code group using our strong name as the membership
condition and gave our assemblies full trust (at install time). After I
converted the code over to using the custom download we no longer really
needed the custom code group but I decided to leave it in there so that we
could later do things like create a security sandbox that would restrict
third party assemblies but so that our own assemblies would still have full
trust. Strong names also allows us to tightly couple the assemblies so that
only assemblies of the correct version would run together.

> > The approach I took was to ensure the correct version of all assemblies
> were
[quoted text clipped - 8 lines]
> I'm curious to know how you had a new file with an earlier version? I
> understand how it could be done, but what kind of situations prompted this?

The first time it created a problem was when one of our testers loaded up a
later version of the app, tested it, and then decided to go back to an
earlier version. He uninstalled the latest version on the server and then
installed an earlier version. When the client connected to the server the
runtime did not download the earlier version because the time-date stamp was
older then the version that was installed on the client. As soon as some
data objects tried to get exchanged we got loads of exceptions due to the
version mismatch. This was unexpected as we thought the runtime would
always ensure the correct version was loaded...we were wrong.

In actual use I would not expect our customers to run into this often, but
it is still conceivable that a customer could get a newer version to try
out, decide she didn't like it, and try to go back to the previous version.

What it boils down to is that anyone who sets the time-date stamp of a file
could play havoc with the versioning/binding system. As our assemblies are
tightly coupled we need to ensure that the correct versions are always
present.

Reply to this Message

Rate this thread:

problems with .NET deployment methods

Free Magazines