Which 64 bit operating system are you deploying to?
Are you deploying a 32 bit or 64 bit application?
Where are the shell folders pointing to in the registry.
What happens if you change the USB drive letter to something different, eg Z:\  ??

There are two possibilities - one is that the registry settings for the shell folder locations, at:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
is somehow being updated to point to your USB device when it is plugged in.
As the effect follows the drive letter you have for your USB device, I consider this the less likely option. The more likely option is that you have something in your MSI that is locating the external device and installing to it - specifically a custom action.

The next step is to generate a verbose installation log of both installs, and compare directory pointers and property values between the two logs. A quick look in the MSI's custom action table will also give you an indication of what custom actions are in your install.

Hi,

I verified that it is not the USB causing the settings for the shell folder at:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
being updated to point to the USB device when it is plugged in.

I've attached two install log files, one with having the USB attached and one without.

If you look at the file "msiInstallUSBAttached.txt" you can see the D:\ getting assigned during install.

I do not have any custom actions to do this. It mus be being set by some Wise black box function.

Any idea how to stop this using the Wise Studio?
Thanks,
B

If you do a search for "INSTALLDIR1", what entries do you find?
Would it be possible for you to attached the .wsi project file for us to have a look?

Hi Here's a screenshot from wise which shows how destination computer is targeted

It's the Users directory tree which gets installed to the external D:\ drive "D:\Users\..."
when it's connected to the destination computer. If the USB is not connected the installation proceeds correctly.

So setting ROOTDRIVE=C:\ in the Properties table would not control why Users going to the wrong drive

any ideas on how to fix this would be appreciated
Thanks,
B

According to the logfile msiInstallUSBAttached.txt you are setting ROOTDRIVE to D:\
(Line number 199 - MSI (c) (DC:08) [09:43:32:788]: PROPERTY CHANGE: Adding ROOTDRIVE property. Its value is 'D:\'.  )

So I recommend you check your property table, etc, for typos.

You really need to give use the details how the INSTALLDIR1 Directory table entry is defined as it is this directory that is set incorrectly according to "you", also any finding if you do a search for INSTALLDIR1.
One note: why is the Users "destination" folder defined in the destination "root"? seems that INSTALLDIR1 is pointing to that destination.
Are you creating the package on a computer running Windows 7 or XP?

Hi,

Would it be helpful if I attached the projects setup.wsi file?
This install package is targeting Win 7.

The reason why the Users "destination" folder is defined in the destination "root"
If I put ithe folder under Program Files>myapp\Users only the User who installed the app would be able to view the files in that folder.

The install function correctly only if no USB drive is attached to the destination computer.

Files will be installed to:
C:\Program Files (x86)\K-NFB Reading Technology Inc\Blio\
C:\Users\Public\Blio

Once the USB is attached files get installed to:

C:\Program Files (x86)\K-NFB Reading Technology Inc\Blio\
D:\Users\Public\Blio

Below is info from from the Property table and the Directory table:

PROPERTY Table output
"Description","Blio"
"ProductCode","{C008917A-F4A9-4755-8DAB-0013726C264B}"
"ProductName","Blio"
"ProductVersion","2.0.4944"
"Manufacturer","K-NFB Reading Technology, Inc."
"ReinstallFileOlderVersion","o"
"ReinstallRepair","r"
"InstallMode","Typical"
"ErrorDialog","ErrorDialog"
"Accept","No"
"WiseInitLangDefault","English,1033"
"ProductID","none"
"PALMUSERS","0"
"_WiseDialogFontDefault","{&MSSansSerif8}"
"_WiseDialogTitleFontDefault","{&Arial8}"
"WiseInitPrefix","Initializing"
"_WiseDialogSuffix","Setup"
"DiskPrompt","[ProductName] [1]"
"REINSTALLMODE","omus"
"ApplicationUsers","AllUsers"
"UpgradeCode","{DFAF1BA8-FABC-49B0-BE18-F16D1197F0F3}"
"WiseInitExistError","%s Version %s is already installed. You must uninstall the existing version before installing %s Version %s. Do you want to uninstall the existing version of %s?"
"WiseInitSpaceError","Could not create temporary file, not enough free temporary disk space. Please free up disk space and rerun this installation."
"INSTALLLEVEL","3"
"MSIINSTALLPERUSER",""""
"WiseInitSuffix","Wizard..."
"ARPCOMMENTS","K-NFB Reading Technology version 2.0.4944.0"
"WiseInitAdminError","You must have administrator rights to run this installation. Please login as an administrator and re-run this installation."
"MaintenanceMode","Modify"
"DESKTOPSCT","N"
"QLAUNCH","N"
"WiseEditorVersion","8.0.0.214"
"ShutdownOption","1"
"ALLUSERS","2"
"APPS_TEST","1"
"DOTNET35SP1FOUND",""""
"WiseCRLF","
"
"PRIMARYFOLDER","INSTALLDIR"
"ARPHELPLINK","support@knfbreading.com"
"ARPHELPTELEPHONE","877 547 1500"
"DefaultUIFont","Arial10"
"WiseLangEncode","1"
"SecureCustomProperties","INSTALLDIR;DOTNETFX;DOTNETV1.0.3705;DOTNETV1.1.4322;DOTNETV2.0.50727;DOTNETV3.0;UPGRADE_1;REBOOT;UPGRADE_2;QLAUNCH"
"MsiHiddenProperties","WISE_SQL_CONN_STR"
"ARPURLUPDATEINFO","http://www.blioreader.com"
"_WiseDebugMode","0"
"ProductLanguage","1033"
"ROOTDRIVE ","C:\"
"PIDTemplate","12345<###-%%%%%%%>@@@@@"

Directory table output:
"WindowsVolume","TARGETDIR",".",""
"TempFolder","WindowsFolder",".:Temp","Windows\Temp"
"All_Users","ProfilesFolder","AllUsers|All Users","Windows\Profiles\All Users"
"BookPlace2","Public","BOOKPL~4|BookPlace","Users\Public\BookPlace"
"CommonFilesFolder","ProgramFilesFolder",".:Common~1|Common Files","Program Files\Common Files"
"Windows","Toshiba","Windows","Windows\Profiles\Start Menu\Programs\Toshiba\Windows"
"Public","INSTALLDIR1","Public","Users\Public"
"INSTALLDIR1","TARGETDIR","Users","Users"
"Videos","Blio","Videos","Program Files\K-NFB Reading Technology Inc\Blio\Videos"
"EULA","Blio","EULA","Program Files\K-NFB Reading Technology Inc\Blio\EULA"
"PublicDocuments","Blio","PUBLIC~1|PublicDocuments","Program Files\K-NFB Reading Technology Inc\Blio\PublicDocuments"
"Microsoft","AppDataFolder","MICROS~1|Microsoft","Windows\Profiles\Application Data\Microsoft"

I have experienced this with USB drives, too. There is a custom directory in our setup that defaults to e.g. C:\Data. If I let Windows Installer handle this, this directory will be placed on the hard drive letter with the most available space, be it an USB drive or whatever (this is Windows Installer default behaviour). I fixed this by forcing the directory in a custom action to be placed on the same drive where Program Files resides.

Hi AngelD,

Attached is my setup.wsi.

Before I make changes directly to the install table could you look at the wsi file?
1. ALLUSERS property is currently set to "2"
2. Component table has no references to INSTALLDIR1

Thanks,
B

Hi JohanH,
Could you send me a copy of the CA that you're using and the location in the MSI script you applied it
e.g. User Interface,Execute Immediate,Execute Deferred and the location<br />
Thanks,

Hi blio, I can't see your reply here in the forum for some strange reason, but you asked for my custom action. I have a condition after Costfinalize with a custom action that changes the target drive to be the same as in the INSTALLDIR property (which is the main installation directory for my program). The custom action is a vbscript (I store the vbscript in a Set Property action and then call it with Call VBScript via Property):

Let's say that your custom directory is C:\Data and has the property MYINSTALLDIR.

Dim oShell
Set oShell = CreateObject("WScript.Shell")
Session.Property("NEWDRIVELETTER")=Mid(session.property("INSTALLDIR"),1,(InStr(session.property("INSTALLDIR"),"\")))

Then do a Set Directory action to set MYINSTALLDIR to [NEWDRIVELETTER]Data.

I do this in both in the User interface (so that the user sees the changed directory in the setup dialog) and in the Execute Immediate sequence (with the condition UILevel<5) if the installation is run silently.

The cause of the USB issue has not been determined as far as I can see, so I cannot see how we can find a way of avoiding the problem via the Wise IDE. If you have a solution in the shape of a CA, then would it not be more efficient to use this than to spend days or weeks trying to find the cause of the problem?
What happens if you create a new, simple, test project?

Hi  EdT,

I understand your point.  But this is a major flaw with the Wise studio.  Most people would have an attached
drive of some sort and this install behavior should be unacceptable.

I've posted the setup.wsi  in hope that someone maybe (AngelD) might see where the Wise ID is setting this.

Bottom line is no CA should need to be written \implemented for this, the installer should install only to the targeted machine.

Thanks,
B

I'm quite sure this is a Windows "feature" and not a flaw in Wise (Wise doesn't have anything to do with how Windows Installer determines the drive letters).

Windows Installer doesn't care if it is a regular drive or USB, Firewire, E-sata, iSCSI or whatever. According to SDK, ROOTDRIVE will always default to the drive with most free space, unless forced to a specific drive, either from the command line or from a property. The latter is either wrong info in the SDK or doesn't work in your case for some undocumented reason.

May I point out yet again that the logfile msiInstallUSBAttached.txt attached earlier in this thread unequivocally sets ROOTDRIVE to D:\.  Since this explains the reason for installation to the USB drive on D:\, perhaps we could focus on why or how WINDOWS INSTALLER is setting this property.
Whereas the setup.wsi posted in this thread has ROOTDRIVE set to C:\. have you checked that ROOTDRIVE is set to C:\ in the property table of the compiled MSI file ??
If for any reason the MSI does not have ROOTDRIVE set, or has it set to D:\, then that would explain the issue.

If you have the quick compile option selected (it is the default setting), I would recommend changing this to have quick compile turned off. Then delete any existing MSI and recompile.
It has been found that multiple partial recompiles can result in abberant behaviour of install packages, so turning quick compile off and recompiling a new MSI will fix any such issues.

If you have a different operating system available, such as XP, can you try the same package with and without a USB key plugged in?