Gregg
Thu Nov 06 19:38:17 CST 2003
Hey Guys,
Thanks for the responses. I haven't had a chance to test out the timestamp reason that you stated. I didn't think that was the
cause of problems in my environment but it may very well be. Actually if that is the case it's much easier to remedy than relying
on third party vendors changing assembly version numbers. Anyway I'll get back to you when I try this out.
> The solution that I came up with was to write a small service that returns
> to the client a list of all files on the server, their time-date stamps, and
> their assembly version numbers (if present). The client then compares that
> list to the list of files in its local store and then downloads all the
> files that are different or non-existent.
>
> This completely changed the deployment model (security zone of loaded
> assemblies and when bits are copied) but the advantage is that it always
> works. It also added some other benefits, such as the ability to download
> data files and files in subdirectories; these would not ordinarily be
> automatically downloaded from a server.
I like what you are doing Dave and I may end up doing something similar although I don't know when I'll find the time.
> IMO the current implementation of Fusion needs to be reworked because all it
> takes to break the deployment model is for someone to change the time-date
> stamp of a file on a server to an earlier date.
Agreed. We as developers need more control over when and if assemblies are deployed locally.
Thanks again,
Gregg Walker
"Dave" <noSpamdlevineNNTP2@wi.rr.com> wrote in message news:%23gb%23I6EpDHA.3732@tk2msftngp13.phx.gbl...
>
> "Gregg Walker" <gregg__INVALID_ACCOUNT__@rrmca.comXNXOXSXPXAXMX> wrote in
> message news:%23g8PFh9oDHA.3320@tk2msftngp13.phx.gbl...
> > My applications are being run using no touch deployment from a hosting web
> server. The client program calls
> > AppDomain.ExecuteAssembly to start execution of the application.
> >
> > Most of the time everything works fine. However, my applications make use
> of a third party component and everytime they make a new
> > version available they don't change their assembly version number but just
> the file version number. So whenever new features are
> > added and one of my apps begins using the new feature the no touch
> deployment of the app is broken because the newer version is not
> > detected on the web server and loaded over the previous version in the
> assembly download cache.
> >
> > Is there a way I can force ExecuteAssembly to not compare assembly version
> numbers and just overwrite all existing assemblies it
> > needs to load? I don't want all my users to have to run 'gacutil /cdl'
> every time I make use of a new version from component
> > vendor.
> >
> > Any other suggestions on how to solve this issue would be greatly
> appreciated.
> >
> Felix stated that the runtime examined the assembly version of the file on
> the server but I do not believe this is the case. The problem that you
> describe is very similar to the one that I ran into. This article describes
> the problem in greater detail..
>
http://msdn.microsoft.com/msdnmag/issues/02/07/NetSmartClients/default.aspx
>
> There's no mechanism I am aware of that forces ExecuteAssembly to always
> download the file - that would bypass all the optimizations that the Fusion
> layer uses to avoid needlessly downloading bits from a server.
>
> The solution that I came up with was to write a small service that returns
> to the client a list of all files on the server, their time-date stamps, and
> their assembly version numbers (if present). The client then compares that
> list to the list of files in its local store and then downloads all the
> files that are different or non-existent.
>
> This completely changed the deployment model (security zone of loaded
> assemblies and when bits are copied) but the advantage is that it always
> works. It also added some other benefits, such as the ability to download
> data files and files in subdirectories; these would not ordinarily be
> automatically downloaded from a server.
>
> IMO the current implementation of Fusion needs to be reworked because all it
> takes to break the deployment model is for someone to change the time-date
> stamp of a file on a server to an earlier date.
>
> Dave
>
>
>