|
[VB] Good tool to determine & resolve dependencies
I read a bunch of samples on Planet Source Code to check updates from the Net, and took a look at Squealer (http://www.addisonsw.com) to determine dependencies since DependencyWalker (http://www.dependencywalker.com) looks interesting (but after reading the help file, it doesn't look like it's able to find all dependencies reliably, and it doesn't work with OCXs, only EXEs so...
do you know of any add-on, ideally a single DLL, that would
1. At launch time, check the EXE's dependencies recursively (ie. the EXE has such and such dependencies like the VB run-time, Common Controls, etc., which, themselves, may have other dependencies)
2. If any dependency is missing or incompatible (the user has installed another app that replaced one of the dependencies with a different version), it will
3. Check if the user has an Internet connection (if 56Kbps, will offer to launch a connection to their ISP)
4. Download dependencies or updates from a www, preferably through a dynamic script, so as to avoid having to remember to generate a static list for each file uploaded to the web server
5. Restart the EXE, or resume its operation
? :-)
Generally speaking, for those of you developing with OCXs (standard DLLs are a non-issue since we can just keep a copy in the app's dir), how do you handle dependencies issues past the initial install?
Thank you
Frederic Faure
Wednesday, December 17, 2003
Fredric,
In general, you can't do that from within the application. By the time your code gets to run, the dependency already needs to be loaded. You typically need another program that runs before or after your program that does the check.
To be honest, in the bad old days when I was using OCX controls the company I was working with never did find a workable solution. We found that an OCX was a nightmare waiting to happen and abandoned Visual Basic because of it. That firm eventually moved everything to web applications, where only a single server need to kept up to date. Myself, I moved to C and C++, with OCXs strictly banned from my work.
Clay Dowling
Wednesday, December 17, 2003
I thought about this (moving to PowerBasic), but we have neither the skills nor the time to eg. write a grid that would offer the same features as VSFlexGrid. Very strange that MS didn't offer the possibility of first looking in the app's directory for an OCX before looking it up in the Registry, thus solving the problem.
Frederic Faure
Wednesday, December 17, 2003
OCX's are just DLL's with a different file name and some added entry points (interfaces).
Frederic, since you can't check the dependancies of the main Exe from within the main Exe, make a "startup" exe whose only job is to show a splash screen while running the process that you describe on the main Exe.
Check out http://www.mvps.org/emorcillo
There is an example called "Get info about EXEs, DLLs, OCXs and any other PE (portable excutable) files" on this page: http://www.mvps.org/emorcillo/cod/general.htm
and another one called "Enumerating installed ActiveX Controls" on this page: http://www.mvps.org/emorcillo/cod/com.htm
Also, there is a program from vbAccelerator.com which opens an compiled "Active X" file (OCX, DLL, Exe) and shows you type library information about it. (Source code is free).
Wayne
Wednesday, December 17, 2003
Here's how we finally conquered the OCX problem.
First, we implemented a "tester" function that tries to load every OCX we know we are going to need. If any OCX has trouble, it displays a specific message to the user (usually "you need to reinstall CityDesk.")
The very first time CityDesk runs, the tester is run through once to make sure SETUP was OK.
After that, to save time, it only runs when CityDesk has an unhandled exception. That way if the exception was caused by the failure to load some OCX, we'll find out about it and give the user specific instructions to fix.
It is important, of course, to understand exactly what DLLs and OCXs you rely on. This took some trial and error. For example we didn't realize where the regular expressions library we used was coming from. 99.9% of users had it in the right place, since it has been a part of every Windows install since 1998, but the rare user had actually gone to the trouble of deleting VBScript on their machine and that's where it was.
Joel Spolsky
Wednesday, December 17, 2003
Oddly we haven't had a big problem with this for a while.
For VB apps it's relatively trival to sort what OCXs you need (open up the VBP in notepad) and then provide a OCX checker as Joel describes.
The worst offenders for downgrading OCXs and other DLLs where Office 95 & 97 which tended to just shove on the version they wanted.
It's also worth testing on Win95 so you can find out what you're missing. Various odds and sods often rely on stuff which is installed with IE.
On Win2K and WinXP machines the issues with the MS V6 programming tools are
Peter Ibbotson
Wednesday, December 17, 2003
Actually, it's not _that_ trivial :-)
Between OCXs which themselves have dependencies (I rely on VB's PDW to check this), OCX which exist in different versions depending on the version of Windows (the unfamous COMCTL, but later versions seem to have solved this issue), and those that have the same CLSID even though they really are different versions... what a pain :-)
Hopefully, my copy of Appleman's door-stop on writing ActiveX controls in VB6 will be in my mailbox soon enough. Thx everyone for the useful tips.
Frederic Faure
Wednesday, December 17, 2003
http://www.dependencywalker.com/
coresi
Wednesday, December 17, 2003
Looks like Desaware's VersionStamper provides a component that can take care of checking an EXE's dependencies, check that they're available, and download them from the www if not:
http://www.desaware.com/VersionStamperL2.htm
Thx again
Frederic Faure
Wednesday, December 17, 2003
>>
I read a bunch of samples on Planet Source Code to check updates from the Net, and took a look at Squealer (http://www.addisonsw.com) to determine dependencies since DependencyWalker (http://www.dependencywalker.com) looks interesting (but after reading the help file, it doesn't look like it's able to find all dependencies reliably, and it doesn't work with OCXs, only EXEs so...
<<
Um, did you read the first sentence on the Dependency Walker page -- "Dependency Walker is a free utility that scans any 32-bit or 64-bit Windows module (exe, dll, ocx, sys, etc.) ..."? I've been using Dependency Walker for years and it's perfect for this sort of thing. It will most certainly detect OCXs. There are two ways to use it -- one lists static dependencies and the other runs like a debugger to detect 'dynamic dependencies (such as OCXs). Every once in a while I'll meet a Windows developer who doesn't know about Dependency Walker and it shocks me because it's such an important tool.
So to summarize:
http://www.dependencywalker.com
Download it, learn how to use it.
SomeBody
Wednesday, December 17, 2003
Yes, as explained way above, DW is nice... but I'm looking for a similar tool that I can embed in an EXE, so that it checks its dependencies in Main(), and download those missing or which have been replaced since the last time.
Frederic Faure
Wednesday, December 17, 2003
Frederic, I've got some people working on a similar problem at present.
They have only just ordered these tools, so I can't yet comment on their effectiveness, but the following look like candidates for you to consider:
Squealer
www.addisonsw.com
AppVerifier (Application Verifier)
www.microsoft.com
HeWhoMustBeConfused
Wednesday, December 17, 2003
http://peach.ease.lsoft.com/scripts/wa.exe?S1=visbas-l&X=-
Wednesday, December 17, 2003
HeWhoMustBeConfused >>
Thx about the links :-) I know about Squealer, but, like DependencyWalker, it doesn't come in the form of a DLL that could be called from Main() to dynamically check an EXE's dependencies, and resolve them. I'll go check MS' AppVerifier.
According to DependencyWalker's help file, checking dependencies seems pretty complicated... I assumed all it took is analyzing the app's source code or EXE, along with its binary dependencies, but obviously, it's more intricate :-)
Thx again
Frederic Faure
Thursday, December 18, 2003
 Recent Topics
Fog Creek Home
|
