I have IS2013 SP1 installed on a VM (Win7 Professional x86) which is connecting to our network through my host connection. Our Verisign file is located on the network as multiple projects use this file. Normally, about 9 out of 10 ten times, I shutdown my VM so that when I go to build it's a fresh session. I dislike suspending the VM as I've had it corrupt an image before, long story. Everytime I go to do a batch build I get the "Parameter is incorrect" error and none of my files are signed. Originally the link to the Verisign file was a mapped drive. I changed it to the actual network address and I still get "Parameter is incorrect". I literally have to relink them, as I have 3 releases I have to relink 3 times, and select the absolute path options and magically it finds the file. General Annoyance #1: When I go to relink the "Digital Certificae File" with the actual path I must do this twice. I select the browse icon double-click on the *.pfx file and select OK. I then select the last option, absolute path, and select OK. I then am prompted with the File Select dialog where I need to select the *.pfx file again. I then select the last option, absolute path, and select OK. General Annoyance #2: I must go through General Annoyance #1 for each release within a project. I must do this for every project. Coming from Suspend mode, Snapshot with VM powered on or off, and coming from general startup (using current image). Granted this takes a few minutes but this bug is more than annoying since I must do it EVERYTIME FOR EVERY PROJECT AND EVERY RELEASE WITHIN A PROJECT. I cannot be the only one experiencing this but I'm not sure if it's a VMWare-only issue or if others are having it on their host systems. ... View more

Upgraded our installer from 2010 to 2013... pure Installscript project Everything on x86 works perfectly with almost no changes. No issues that I am away of. When installing on a x64 OS our two .NET DLLs are not being registered (via regasm.exe). If we manually register them everything works perferctly just like on a x86 OS. Installshield is running on a x86 Win7 VM. I noticed that in the .NET tab there are two textboxes for the location of RegAsm & InstallUtilLib. The x64 location is disabled. I'm wondering if this is part of the issue? Everything works as expected on a 32-bit OS with no changes but does needs to be manually registered on a 64-bit OS. I should say that the same files are installed on a x86 and x64 and that the component this is set to is "Sefl-Register" and "Local Assembly" and "Dependencies". ... View more

So the Devs removed some files and then added new ones, not named the same, and it was completely out of my hands... This is the code for trying to update the current installation: function OnMoveData() . . . begin . . . //--- If we are updating... elseif (DetermineIfUpgrade()) then //--- Set the installation directory to the %ALLUSERSPROFILE% TARGETDIR = GetCurrentTargetDirectory(); //--- Make sure to select any NEW features FeatureSelectNew( MEDIA, TRUE ); FeatureReinstall(); //--- Set appropriate StatusEx static text. Sprintf(sFormattedMsg, @IDS_STATICTEXT_MAINTUI_UPGRADE, @IDS_READABLE_VERSION_STRING); SetStatusExStaticText(sFormattedMsg); . . . end The Devs want to use the Component directory (dir that is dynamically linked to a Component) as a dumping ground for all current files. The code above allows me to get the new files installed but the old ones are still present and I need the gone. Originally I used FeatureSetupTypeSet(MEDIA, "Complete") followed by FeatureRemoveAllInLogOnly() which basically uninstalls the current installation instead of just remove the files that were installed previously, so that the new ones can be installed. So all in all I have to be able to remove the old files within the Component/Feature and install the new ones from the running installer, always in every case. Assume Deleted file names: OldFile_01 Assume New file names: NewFile_01 Assume Feature name: Feature_01 Assume Component name: Comp_01 OldFile_01 is present in v1.1 NewFile_01 is not present in v1.1 NewFile_01 is present in v1.2 OldFile_01 is not present in v1.2 v1.1 is installed on the system and they want to upgrade to v1.2 OldFile_01 and NewFile_01 are in the same Feature/Component which pulls from the same directory (OldFile was deleted from said dir and NewFIle was added to the said dir) When user upgrades OldFile_01 needs to be removed from the system and NewFile added, dynamically*. When user reverts NewFile_01 needs to be removed from the system and OldFile_01 added, dynamically*. *By "dynamically" I mean that the installer has NO knowledge of the change made pre-build... tl;drThe Feature in questions contains only 1 Component that holds a large number of config files (sort of). I need to remove all files that are not present in the currently running installer and make sure to add any new files present in that running installer. ... View more