Oooh, I just found something I love with Update Service!

[Brad_Peterson]

Heh, I tend to complain more than I should in these forums, so I want to explain something I'm *really* happy for.

I can have Update Service query the installed files, and easily check out info on it such as the version, date, or size, or if it even exists. That way, I can target updates on a file by file basis. This is a *huge* time saver for me, and I'm surprised the folks here at Update Service don't advertise this more. Here is why it saves time. My old process of delivering an update consists of the following:

1) Wait for the perfect time to stabalize the code, and then compile all necessary .dlls and .exes to be updated for all applications.
2) Open up my InstallShield program (in my case, Express X), and manually design patches for all our applications in a UI that makes it time consuming, redundant, and annoying.
3) Create the MSI patches.
4) Send the updated patches to the file server.
5) Go into the Update Service web page, and specify that I have a new update.

The new way helps save time on #1, and saves me from having to do steps #2 and #3.

With a file by file update, I do not have to wait to get all stabalized code for all .dll's and .exe's before making a patch. I can just have various programmers control their dll's, and then let them send out updates for their files when needed. They do not have to coordinate with the person who controls the patching, and they don't have to wait for this patcher to schedule in a new patch date. They can simply add their .dll to the list of files to update. And if we have multiple products that all share the same .dll, he can deliver that .dll update to all products at once, instead of having the patch designer create multiple patches for multiple products that will need that new .dll

This also saves me (the patch designer) time by not having to use the InstallShield Express X Patch creater, which I cannot stand. I had little respect for it before, but now, I hate it. I just ran into a bug with the InstallShield patch process in which you cannot have more than 15 patches of a file. I'm left then with two alternatives. 1) Use MSI patches, and release 15 minor upgrade patches followed by 1 major ugrade to reset my minor patch count or 2) Use a file by file update system. Luckily, #2 turns out to be faster and better.

So the new way is this:
1) Let a programmer compile his .dll or .exe when he is finished testing it.
2) Copy the .dll or .exe to the file sevrer
3) Go into the Update Service web page, and specify that a new .dll is available for all applications that have an older version of that .dll

The only drawback I have is that I have to design my own update screen, because I'll need to manually handle and process each file I download. Luckily, the Update Service API has enough flexibility to tell me what updates are available for my system, and let me find out what the download URL, the size of the file, and any other notes I want to attach with it. Then, I'll just use all this info to have our programs download and process the individual file on their own without InstallShield's help. It would be nice if Update Service gave me more fields to work with, such as letting me specify the target dir for that update, or some free fields that let me put in whatever internal data I want to transmit along with the update. It would also be nice if Update Service gave me a downloadable screen that lets me handle mutliple file updates my own way, instead of having it auto process them (I don't want to write an auto processor for each file). But oh well, just having a flexible API and a file by file update system is a huge time saver and welcome relief from the pain of MSI patching.

[Brad_Peterson]

I do have one question I'd like a developer to help me with.

If I manually place new file to the users computer, and I put that new file in the installed application folder, will Update Service recognize it is there for future checks?

For example, lets say I send version 1.0.0.0 of new.dll to our app's folder in C:\program files. A month later, I release version 1.1.0.0 of new.dll. So my question is this: In Update Service, if I ask it to see if new.dll is version 1.0.0.0 or less, will it work? Or will Update Service not know it is there, since the installer has no knowledge of new.dll?

Essentially, what I want to stay away from if at all possible is MSI patching. I'd hate to have to create an MSI patch to add files. If there was a way I could query for installed files in the app path's folder, that'd be perfect. Because it seems right now, if Update Service doesn't automatically check in the app path folder, then I can only query for files in the Winsysdir folder and the common files folder. Perhaps if I can't yet query for files manually placed in the app path folder, the next version of Update Service can add "InstallDir" as a third folder to look for files in (with the first two already being WinSysDir and Common Files)?

[KellyF]

I'm not sure I follow your question exactly, but it sounds like you want a condition for your update....
Log into the publisher and create an update (to test)
On Step 4, create a condition of "A file exists with a certain version".

Options in this are version equal, less, greater, etc. For more detail, you can hit the ? icon there to get the inline help, or check the web-based help for more details. (Basically, you can tell it where the file would be or to search your installation logs)

Regards,
Kelly

Sorry I can't write volumes about it, but I'm swamped this week.

Brad Peterson wrote:
I do have one question I'd like a developer to help me with.

If I manually place new file to the users computer, and I put that new file in the installed application folder, will Update Service recognize it is there for future checks?

For example, lets say I send version 1.0.0.0 of new.dll to our app's folder in C:\program files. A month later, I release version 1.1.0.0 of new.dll. So my question is this: In Update Service, if I ask it to see if new.dll is version 1.0.0.0 or less, will it work? Or will Update Service not know it is there, since the installer has no knowledge of new.dll?

Essentially, what I want to stay away from if at all possible is MSI patching. I'd hate to have to create an MSI patch to add files. If there was a way I could query for installed files in the app path's folder, that'd be perfect. Because it seems right now, if Update Service doesn't automatically check in the app path folder, then I can only query for files in the Winsysdir folder and the common files folder. Perhaps if I can't yet query for files manually placed in the app path folder, the next version of Update Service can add "InstallDir" as a third folder to look for files in (with the first two already being WinSysDir and Common Files)?

[Brad_Peterson]

Thanks for the reply KellyF. I understand you're swamped, I'm the same way too.

Here is my problem. Lets say I manually place the file called newfile.dll in the main app's install directory. For most machines, it may be c:\program files\mainapp\newfile.dll. For others, it might be f:\special work files\mainapp\new.dll.

If I want to have update service check against that file for updates, how do I tell it to find that file?

Publisher gives 2 options. First, if I search by files installed by the product, then that doesn't work, because this file was manually placed there by me, not by the installer. So, in my scenario, if I were to specify "new.dll" as the filename, it won't know where new.dll is located on the users machine. Second, if I search by search the users file system, I can only search in CommonFiles or WinSysDir. That won't work either.

So my suggestion, is that in the option to search the users file system, add an "InstallDir" option along side CommonFiles or WinSysDir. That way, I can tell it to search the "InstallDir" folder for new.dll, and then it can go into the users installation info, find where the user installed the app to (such as C:\program files\mainapp\ or f:\special work files\mainapp\) and find the specific file in there.

[KellyF]

Brad,

I'm probably not the best to respond to your query then, as I'm somewhat weak on the client-side of things (I'm more of a server-side guy). If you place the file there, do you log it anywhere? (registry, file, etc.) If so, I believe you could write a quick vb script to find that location. As for installdir, perhaps I'm not fully thinking about the circumstances in which you call it, but the agent wouldn't know about InstallDir on the client machine, would it?

Just a reminder: if you do feel strongly about having this alternate search feature added, be sure to submit it via the feedback mechanism. Yeah, you knew I'd say that too.... 🙂 :rolleyes:

Regards,
Kelly

[Brad_Peterson]

Thanks for all your help so far KellyF.

Logging it somewhere is something I'd like to stay away from. I'd have to have one log for every file. Also, I don't believe I could log it's location in a file, because then Update Service wouldn't know how to get that information and use it as a path. For example, I couldn't log C:\program files\MainApp\new.dll in a registry setting, and then ask the Update Service's publisher to read that regestistry setting, obtain that value (the file path), and then do further checks on that file.

What seems easiest to me is simply asking it to checking in the InstallDir, which all InstallShield apps should already know. I know in my Express X patch creater, it lets me add new files to the InstallDir. This makes me believe that the InstallDir is stored somewhere in a way that Update Service can access it. Besides, Update Service already knows how to look for files installed by the installer. So it seems from an outside observer that obtaining the InstallDir could be easily impelmented.

Anyways, since you don't work on client side stuff much, you've probably helped me out as far as you can go. Thanks again for the help you give in these forums. I'll submit my request via the feedback mechanism.

[KellyF]

About InstallDir, we've typically tried to be neutral so that we have no dependence upon any particular installer. But who knows, maybe this would be enough of a benefit for it to be included. In the near-term, client-side callouts may provide some needed flexibility for you.

Over time I hope to become more fluent in the agent side of things....

Regards,
Kelly

[Brad_Peterson]

Nevermind, it appears you can set this up reasonably using VBscript.

All I need is 1 registry setting explaining where my installdir is. Then, I can use these VBScript functions, and I'm set.

GetRegVal (RegKey, ValueName, Value)
GetFileVersion (ProductCode, FileName)
GetFileDate (ProductCode, FileName)

This is simple enough that I think the installdir suggestion probably isn't needed.