Software Deployment

You can use a Custom Action and VBscript to force a delete.

Have you tried the "RemoveFile" table with a wildcard?

You'll probably find that it doesn't work with subfolders though.

By "pure msi" I mean "without using some vbscript" :-)

WiseUser : Sure I tried the Remove table as follow :

FileKey Component FileName DirProperty InstallMode

All NewComponent1 * INSTALLDIR 2
Folder NewComponent2 INSTALLDIR 2

INSTALLDIR is a path to a test Folder I created before (e:\TEST)

This doesn't seem to work...

Did I miss something ?

I can't read your post very easily, but it seems to look alright to me?

Does "E:\Test\" have any subfolders? Is it empty after you remove the MSI?

Make sure that "NewComponent1" and "NewComponent2" don't have the "msidbComponentAttributesPermanent" or "msidbComponentAttributesSharedDllRefCount" attributes set. Also check that they're actually installed in the first place.

If you find that they did have these attributes set, try changing their component codes.

Have you tried hard-coding "ROOTDRIVE=E:\"?

I had hardcoded INSTALLDIR as e:\test\

But I just tried something else :

I hardcoded the INSTALLDIR2 Property and set it to e:\test\smthg

And then, use this property in my removeFile table.

And... it works [8|].

I don't understand why, but that's good :-)

Note : The shared bit is set, and it doesn't change anything here (I don't use .dll in these folders)

Thank you ![:D]

Following cases should be considered :

1) If your application is creating new folders / subfolders at runtime , then Removefiletable will not be of much help . You have to use custom action , I am not aware of any pure msi way of achieving that

2) If your application is creating only files at runtime then giving wildcard (*) will remove everything

3) If you application is leaving a blank folder then removefiletable will take care of removal

All cases discussed above can take following values :
File Key
Remove_[DirectoryName]
Component
[ComponentName]
FileName
*
Dirproperty
[DIRPROPERTY]
InstallMode
3

Cheers ,
V

Yes, "SharedDlls" is probably not the best name for this reference counting mechanism - it will count any (keypath) file in the component (not just binary files).

1) If your application is creating new folders / subfolders at runtime , then Removefiletable will not be of much help . You have to use custom action , I am not aware of any pure msi way of achieving that

I tried the following sequence :

1*/Execute msi : it creates a new folder e:\TEST\

2*/Create manually a new Folder e:\TEST\SMTGH

3*/Copy some files in this folder (manually)

4*/Execute msi : ALL is removed (e:\TEST no more exists)


Of course, if I create a new subfolder under e:\TEST\SMTGH\, it won't be removed... (But I should not meet this case)


So I don't understand your answer : If I know the folder which could be created, I can do it without using some vbs ? no ?

Of course.

Best practice would suggest that you include any files and folders that you know about in your package.

As software repackagers we can't always anticipate every file or folder which might be created - unless we are working in a tightly "locked-down" environment of course.

But a little bird tells me that you're not a "repackager"? If it's your own application you should know which files or folders might be created.

Yes, SharedDll is really a confusing name...

Of course

maybe viv_bhatt1 know something we don't know :-/
I don't really understand his sentence so I'll wait for his answer.

Yes you are right, I have to agree with you . As long as you know which folders your application is going to create at runtime and you can mention them in removefile table everything will work fine .

I am talking about the case where you do not know which folder your application will create at runtime . For eg:-

Application creates a new folder within e:\test\SMTGH , which is created for every new user logged on to the machine and contains the logged on users login name (A lot of CA applications do that). In this case we can't find the name of folders created by the application . Hence Removefile table entry will not work and will leave all the new folders /subfolders not covered in your package .

Again Remove file table will work in case as mentioned by you where you aren't expecting any new subfolders to be created by your application apart from the one mentioned in your msi .

Hope this helps .
Cheers ,
V

thank you for this interesting answer, I understood :-)

Are you expecting a reply for shared dll's ? I am not sure where did I mention Shared dll . I have checked it twice , please let me know .
ORIGINAL: babric

Yes, SharedDll is really a confusing name...

Of course

maybe viv_bhatt1 know something we don't know :-/
I don't really understand his sentence so I'll wait for his answer.

No no no no. We have all quickly answered so it could be confusing :-)

I was talking about :

1) If your application is creating new folders / subfolders at runtime , then Removefiletable will not be of much help . You have to use custom action , I am not aware of any pure msi way of achieving that

but you now have answered.
Topic closed ! :-)

Thanks . It was a good discussion indeed .


Cheers ,
V

A small correction from my side . Installmode flag in Removefile table should be 2 , if we are using a wildcard in filename .

Cheers ,
V