Hello,

In the situation you describe, I think the null reference occurs when the Update Controller attempts to reference the hosting application. In your case, the managed assembly is hosted through COM interop from Internet Explorer. The Update Controller will not be able to reference the hosting process (Internet explorer) because it is unmanaged.

With AppLife Update, once an update process is initiated, you can do almost anything you need to do during an update process. Keep in mind, the process hosting the Update Controller does not necessarily need to be the assembly that is going to be updated. In your scenario, you might consider using a surrogate process to control the update. This would get you out of the Internet Explorer process while performing the update. To do this, you could create a basic executable with no user interface except for the update process. Call it the surrogate.exe The surrogate hosts the Update Controller. When you want to check for updates from your IE toolbar, you simply launch the surrogate in its own process from your BHO. When launched it performs the update work. The surrogate update process can do all the work necessary to update your BHO. There are GAC actions that you can use here.

http://www.kineticjump.c...lt.aspx?g=posts&t=5

For versioning, you can set the version on the Update Controller in the surrogate.exe programmatically to the assembly version of your BHO dll and not even replace the exe during the update process. Alternatively you could set the version within the surrogate and replace it with each update. There are other options too.

You could prompt the user to restart IE from the surrogate app, or create an AppLife Update custom action to do it for them during the update process.

Also, obviously your users will need elevated privileges to perform these types of update actions. If that is a concern for you, don't forget about the AppLife Update Service.

I think this concept would provide a sound updating solution for a BHO.

This error was a result of a dependency on version 1.0.0.13 of the update engine within the GAC actions assembly. This dependency prevented proper operation with version 1.0.0.14. The dependency has been removed and the GAC actions reposted. These actions will now operate properly with all released versions of AppLife Update.

thanks for all the info, i also would like to ask you about how to supress any update dialog, i want to simulate an autoupdate but witout user intervention.

grettings

Hello mr brian, i have another problem that i hope you can help me:

I need to set (in visual studio 2005 installer) two properties for the applife merge module, Path and public key. my situation is, that i have a single program which executes and does all the work for the updating of my BHO, as we discussed, this process does all the work outside of internet explorer.

My problem is that if i want to enable updates of my BHO in a multiuser machine i should place my surrogate executable in a directory where all users have access so they can execute it, i chose c:\program data ( in vista) where all user with a password can access and execute programs.

The problem with this is that there are no visual installer properties that help me out to point to this directory in the target machine

i believe the CommonApplicationData enviroment enum variable in csharp gets the correct path of c:\program data\ but there are no [CommonApplicationData] in visual studio 2005 installer.

I believe my solution would be to put programaticly the PATH in the merge module propertie using custom actions where i could run csharp code, but i don't know how to acomplish this.

Or maybe you could tell me a way i can change the value PATH, once the merge module gets installed correctly in the target machine but with a wrong PATH value, and with a custom action overriding the commit event i could put code to change this value to the correct path of my surrogate exe. Maybe a registry entry? a configuration file?


best regards