The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

DLLs/OCXs in Install dir - Development Problems

Hello,

I wrote some time ago asking about the benefits of installing all of the support DLLs and OCXs to the Application directory instead of the System Directory (this is for Windows).  City Desk does this and the benefit is that you always use a known version of those files.  Great, I get that.

I tried to do this in Visual Basic and I ran into an annoying problem.  When I installed the application on my development computer, that app worked fine but when I went into VB, the references for the DLLs and OCXs switched from the Windows System ones to the installed ones.  Why is this?  I am guessing it is because when the files were registered, those were now considered the "latest" ones and were used.  Apparently you cannot explicity choose the exact file (i.e. the path) you want to reference.

The bigger issue is if I uninstall the application, the references are lost and VB now cant find those references.

Anyone have an idea of how I could correctly do this?  I want to eventually install files in the app directory but find a way to not have these reference issues.

Ideally I would like to have a folder called 'redistribute' that has all the files to include in the app and use those in the development.

Thanks!
Nick Koranda Send private email
Tuesday, September 27, 2005
 
 
You should only install *your own* support files in the app dir.  You should *never* install system files in your app dir (and register them, no less).

An argument could be made that you should *never* install system files, period.  If your app depends on system files that are not installed, then it should prompt the user to install the *component* that includes those files.

That may be too restrictive, however, in some cases.  For example, my co. distributes an app that requires MSCHRT20.OCX.  This is part of VB6, but we don't want to require every user to install VB, so we install it for them (if its' not already installed, and if our version is newer).

A good discussion of what to install (and how) can be found here: http://www.jrsoftware.org/isfaq.php

Also see following for MS's  recommendations:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnanchor/html/anch_setup.asp
BillT Send private email
Tuesday, September 27, 2005
 
 
Nick Koranda > I wrote some time ago asking about the benefits of installing all of the support DLLs and OCXs to the Application directory instead of the System Directory (this is for Windows).  City Desk does this and the benefit is that you always use a known version of those files.  Great, I get that.

No. You should install your very own, personal COM servers in the application directory, but install standard COM servers in SYSTEM32, upgrading them if necessary. Needless to say, that will only work if the user is logged on with the necessary access rights, or Windows will silently discart the upgrade, and revert to the previous version.

> I tried to do this in Visual Basic and I ran into an annoying problem.  When I installed the application on my development computer, that app worked fine but when I went into VB, the references for the DLLs and OCXs switched from the Windows System ones to the installed ones.  Why is this?

Because that's what it says in the Registry: The last registered version wins. Some apps solve this problem by keeping all their COM servers in the application directory, and re-registering them every time the app is launched. Uncool.

> I am guessing it is because when the files were registered, those were now considered the "latest" ones and were used.  Apparently you cannot explicity choose the exact file (i.e. the path) you want to reference.

MS introduced a hack with W2K: For each COM server, create a zero-byte file of the same name with the extension .local: This is a signal to Windows that it should first look in the local directory before proceeding. Just like non-COM DLL's.

> Ideally I would like to have a folder called 'redistribute' that has all the files to include in the app and use those in the development.

Just run a batch file that registers all the COM servers in the redistribute directory :

for %f in (*.ocx *.dll) do regsvr32 /s "%f"

OR

for /r %i in (*.ocx) do regsvr32 /s "%i"
Fred
Tuesday, September 27, 2005
 
 
Bob Riemersma
Friday, October 07, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz