auto update feature vb.net

[marfi95]

I want to implement into my application a mechanism to retrieve the
"latest updates" to my app. I'm looking for various ways to accomplish
this and how to get around the fact that you are running the app and
when you download/copy a new version, the app is in use.

How do you get version info of the new one (without running it) to even
determine if a new one needs to be retreived ?

Should I: (once I have determined a new one is needed)
1) download the new one
2) create a batch file to copy
3) shell out to the batch file
4) close down the app so when the batch runs, the app will be down and
the copy can be done.

Just looking to see how others have done this.

Thanks,
Marc

 

[marfi95]

I should add to this that this is on a Intranet, so a shared folder is
acceptable. It can't be run from the shared drive though because of
firewall issues. It has to be run on a persons desktop. It is not a
big download/copy, just a simple .exe and the pdb. It does not need to
be a complicated process. I looked briefly at the .net application
blocks for updaters and it looks like overkill for what I need. This
is just to prevent me from having to send out emails when I update this
app.

Thanks.

 

[Adam Goossens]

Hi,

If you want to get the version info, you could get the metadata of your
EXE. Since an EXE is still just an assembly, you can do something like this:

---
Dim assNewExe as Assembly
assNewExe = Assembly.LoadFrom("\\Path\To\Your\Drive\App.exe")

Dim verAttrib as AssemblyVersionAttribute
verAttrib =
CType(assNewExe.GetCustomAttributes(GetType(AssemblyVersionAttribute),
False), AssemblyVersionAttribute())(0)

' verAttrib.Version contains the string representation of the assembly ---

Then you compare it with the version of user's copy of the application.

The only drawback to this method is that it requires you to load all of
the types defined in that assembly in order to read it's version
attribute. That chews up copious amounts of memory that your application
never makes use of. And that really sucks. Perhaps there's a better way
I dont know of

The solution to that problem is to load the assembly in a 2nd AppDomain
and then unload that AppDomain when you're done checking the version
data. This way you free all of the memory that was claimed by loading
that assembly to check it's version.

As for the problem of updating the executable, I have no experience with
that. Sorry

Regards,
-Adam.

 

[Cor Ligthert]

Mafi,

My prefered way.

Start a seperated program and close your main program
Use a windowservice in that seperated program to determ what are the newest
assemblies
Download the newest ones just with a command as downloadclient(url,path)
(with not running names)
Rename your older programs to dummy names
Rename your new programs to the actual
Delete your older programs with the dummy names.

(When you have to update the update program you have to create an special
routine by downloading that and creating a very small commandline program
that after the update program has had enough time to close, renames the old
one, renames the new one, deletest the old one and start the new one)

In the next version of VBNet this kind of procedure will be implemented as
"click once update",

However the above just as idea

Cor

 

[Herfried K. Wagner [MVP]]

I want to implement into my application a mechanism to retrieve the
"latest updates" to my app.
[...]
Should I: (once I have determined a new one is needed)
1) download the new one
2) create a batch file to copy
3) shell out to the batch file
4) close down the app so when the batch runs, the app will be down and
the copy can be done.

<URL:http://www.google.com/search?q=application+updater+block>

 

[marfi95]

I got this all working except now I realize why I need to load the
"checking" version into a 2nd domain, but I'm having problems getting
it to work. I'm using Load from the new domain object, but it gives me
a filenotfound exception, yets its there. if I just change it back to
using assembly.loadfrom (file), it works fine.