PDA

View Full Version : Shared File Check Error



NewsArchive
06-17-1997, 12:00 AM
ISX Pro 1.11a seems to check for shared files in use in reverse logical
order.
The current order seems to be at install time:

1. Check if file is in use, if so failure
2. Check if file needs to be updated

The order should be (I assume):

1. Check if file needs to be updated
2. If so, see if in use

This can be reproduced by Using Disk Build and the Test Run, while running
Visual Basic 4.0 and COMPOBJ.DLL, OLE2NLS.DLL or STORAGE.DLL is in memory.
Since you have created the package from the system that ISX Pro will be
delivering on, these should already be the current versions and should not
have to be removed from memory.

lgardne1@csc.com

NewsArchive
06-17-1997, 12:00 AM
Only in the case of the 16 bit ole files Express uses the order you
have found out. For all the other files it works the way you expect it
to. Another point to note is that Express includes the 16 bit files
from the "16bitole" directory under Express' <INSTALLDIR>. This
means that the versions of these files included with your install are
not necessarily similar to those in the System directory of the
machine where you create the install.

--
Rajesh Ramachandran
InstallShield Corporation

Lawrence J. Gardner <lgardne1@csc.com> wrote in article
<01bc7adc$21482020$0b87aec7@galaxy>...
> ISX Pro 1.11a seems to check for shared files in use in reverse logical
> order.
> The current order seems to be at install time:
>
> 1. Check if file is in use, if so failure
> 2. Check if file needs to be updated
>
> The order should be (I assume):
>
> 1. Check if file needs to be updated
> 2. If so, see if in use
>
> This can be reproduced by Using Disk Build and the Test Run, while
running
> Visual Basic 4.0 and COMPOBJ.DLL, OLE2NLS.DLL or STORAGE.DLL is in
memory.
> Since you have created the package from the system that ISX Pro will be
> delivering on, these should already be the current versions and should
not
> have to be removed from memory.
>
> lgardne1@csc.com
>

NewsArchive
11-17-2000, 01:00 AM
Hi Mike !

Thanks a lot for your explanation ! It was what i guessed from InstallShield
but now i am sure and i will work correctly.

Bruno.


Mike Moore wrote:

> Shared means shared throughout the system.
>
> The IS setup will automatically track the components that use a file
> without setting the shared flag, so if you install a file that
> is used by 2 components, then uninstall one component
> the shared one will still be there until the other component
> is uninstalled. However, if a different setup tries to use
> the same file and you don't have the shared flag set and you
> uninstall your application, poof the file will be uninstalled
> by your setup.
>
> I do a little of both, include the file group in multiple
> components and use a component that is required by 2 different
> components. So, far either implementation has not been a problem
> with files being removed to soon. Either way I set the shared flag
> if the file has the potential to be used by another application.
> This adds a little overhead to the OS, but what doesn't in the Windows
> world.
>
> Mike
>
> Bruno Freudensprung wrote:
>
> > Hello !
> >
> > I have three questions concerning shared files :
> >
> > - In the File Groups pane, there is an attribute called "Shared". What
> > does it mean ? This file group is shared by the components of this setup
> > ? Or this file group is used by an application totally different from
> > the setup one's ?
> > - I have a File Group that is required by 2 components of my setup.
> > Should i create a "Shared Component" (that would be declared as a
> > required component for the two others) and assign it the file group ? Or
> > should i assign this File Group directly to the two components that use
> > it ?
> > - How does InstallShield will react in these two possible cases ?
> >
> > Thanks a lot. :-)
> >
> > Bruno.

NewsArchive
07-03-2001, 12:00 AM
"Jim Kang" <replytogroup@installshield.com> wrote in message
news:3b37d778$1@12.41.20.38...
> It's there in the file's property sheet, if you uncheck "use system
settings."

Is this the same kind of share that I mean? If so, why place it together
with File Attributes?
Shared is checked, but if it was the kind of share P&DW lets me create,
uninstall
wouldn't remove the file until the last app using the shared files was
uninstalled.


>
> In 3.03, however, there's a bug with file sizes and refreshing if "use
system
> settings" is unchecked. If you hit refresh after unchecking it, the file
size
> will go to zero. However, you can get it back by checking "Use System
> Settings" and refreshing (then you can uncheck it again). This is fixed in
> 3.5, which will be out soon.
>

How soon is soon?

NewsArchive
07-03-2001, 12:00 AM
"Njål Fisketjøn" <n.f@figu.no> wrote in message news:3b41866b@12.41.20.38...
>
> "Jim Kang" <replytogroup@installshield.com> wrote in message
> news:3b37d778$1@12.41.20.38...
> > It's there in the file's property sheet, if you uncheck "use system
> settings."
>
> Is this the same kind of share that I mean? If so, why place it together
> with File Attributes?
> Shared is checked, but if it was the kind of share P&DW lets me create,
> uninstall
> wouldn't remove the file until the last app using the shared files was
> uninstalled.
>
>

When will I learn? Read the help text before replying...

I can't understand why the Share attribute should be limitied to certain
file types though. :((

P&DW lets you share *any* file type, including .dat files which is the
extension
I've used in this particular case.

Will InstallShield be "fixed" to handle this?