cornerg wrote: I have a project which works fine. It includes a .dll which is installed via the predefined folder [GlobalAssemblyCache] One user reports a fail to install as the install fails to write to the GAC on his machine. In an attempt to diagnose I searched InstallShield to see if I could see what [GlobalAssemblyCache] translates to as a disc location. But it does not appear in the Path variables tab, and the value is greyed out if you right click to see the list of Predefined Folders. Does the value of [GlobalAssembyCache] get fixed by the version of .NET Framework on the build machine, or is InstallShield clever (??) enough to work it out at run-time on the client machine? At .NET Framework up to 3.5 the GAC is at C:\Windows\Assemblies after 4.0 it is at C:\Windows\Microsoft.NET\Assemblies GlobalAssemblyCache is used as a build-time flag to let InstallShield know how to populate the MsiAssembly and MsiAssemblyName tables. You will need to have the component set to, ".Net Scan at build", and at least Properties for this to work. If it's not set at the component level, these GAC targeted assemblies will end up on the root of the drive with the most writable free space. ... View more

Interesting question! It seems like it's a compiler option, which (as near as I can find) doesn't have implications on legacy platforms that don't support ASLR. So of course, InstallShield would have to implement this in a new release. But, it seems like a pretty significant value for the amount of work it takes (at least on the surface). ... View more

I cannot help you decipher that log, because it does not contain information about the cause of the error. You need to track down the *.installstate and similarly named files which according to this will be created in the location of the assembly you're installing. I would also like to stress again that you should consider a move away from installer classes, primarily because the install log will contain the actual cause of the install error then. (There's also fewer points of failure this way) ... View more

Error -1001 wraps every possible error with an installer class (this is the fault of Microsoft's InstallUtilLib.dll they released for integrating into Windows Installer). IIRC it means that you have to find the installer class logfiles to see what the inner exception was. I don't recall where those live, but maybe where the installing assembly is located? As I posted in another thread, you're money ahead if you don't use installer classes and instead figure out how to implement all that configuration functionality into the installer. At least when it doesn't work right then, you get a meaningful error in the actual MSI log--but there's a lot of other reasons why it's advantageous to not use installer classes. ... View more

You might be waiting a while. For the most part, the product is mature as it is going to get. The underlying engine (Msiexec.exe) for the most part has stopped being updated by Microsoft, because everyone is moving to Cloud platforms. The latest package formats don't require a sophisticated packaging tool because of how they work (webdeploy, docker, kubernetes, xcopy, etc.) and so some superficial support was added for some of these, but there's not likely to be much more that can be done with IS. ... View more

Run through the release wizard, using the Network release type. ... View more

esterel wrote: Hello, I am working with InstallSHield 2015, with a Basic MSI project. I am trying to open a Custom Dialog (which just contains a text and a button OK to close it) from a Deferred Custom Action. But it Failed, the desired dialog is not displayed. I am asking if it 's possible during the execution of a deferred CA to display a Dialog? Thank for you help Regards --Jean-Luc Yes. You are going to need to roll your own in whatever language you're writing the custom action in, though. Don't forget to check the UILevel property to avoid showing the dialog during silent installation! And of course, you have to get this value through via CustomActionData ... View more

If you're using an MSI based project, check this out: https://msdn.microsoft.com/en-us/library/windows/desktop/aa370109%28v=vs.85%29.aspx If a substring of the form "[\c]" is found, it is replaced by the character without any further processing. Only the first character after the backslash is kept; everything else is removed. So, try something like: [\[]123[\]] ... View more

As a rule of thumb, don't use installer classes. You really want to do all that configuration work in the installer, and not in .Net code--because the installer has all kinds of functionality provided for it--install, modify, rollback, etc. service registration, GAC installation, etc. In fact, once upon a time, adding a new installer class to a .Net project would include in the template code a bug which would produce -1001 errors on modify/repair. (I don't know if this is still the case, tbh) Other reasons to avoid installer classes: -It's hard to get to the root of a -1001 error (usually not logged in the MSI log; have to chase down the installer class log, and have the good fortune to have it logged there) -Almost all errors show up as -1001 errors, despite having a variety of causes -Registration is dependent on the application having everything in order at the time of registration (may not be if you have dependencies in the GAC) My advice is to make a list of all the stuff you need to do, and one by one look up how to accomplish it in native installer functionality. It may be more work figuring it out if you're much more a .Net dev than an installer dev, but it's going to be easier to live with in the long run. ... View more

As far as I know, it is not possible to disable the size in ARP. ReserveCost you can populate dynamically by inserting temporary records using a custom action (lots of examples out there on how to do this, but mostly used for ComboBox values), so if you have some way of estimating what's already on the machine, this might still be an option. If you are going this route, make sure you sequence the CA in the Exec/UI sequences and condition accordingly, and ensure it's before CostFinalize. There is one other possibility, which will be a lot of work. The properties like size and such are populated by the Windows Installer engine, and so you may be able to get your own custom entry which doesn't contain the size value. Note that there's probably packages in ARP which don't display their size--that is because they use an *.exe installer which manages the ARP entry, and which doesn't set the flag to tell it to use Windows Installer to manage it. So, you could set ARPSYSTEMCOMPONENT for your *.msi package and wrap it with some sort of *.exe that either you write yourself, or use something off the shelf like an InstallScript project or a Wix Bootstrapper application. If you are really, really stuck on this, and it's very, very important, you can always submit a per-incident to Microsoft support. (They will charge you for it, and there's no guarantee they will provide a solution that is easy or satisfying--but they built the Msiexec.exe engine). Good luck! ... View more

Hey Paul, I just came across this thread and based on the few lines of sample code you are trying to do the same thing as me: Wire up Azure Powershell to an Install for some reason or another. I'm writing my own Powershell support from scratch in Wix DTF however. Let's keep compare notes sometime! ... View more

You want to manually populate the ReserveCost table using Direct Editor: https://msdn.microsoft.com/en-us/library/windows/desktop/aa371226(v=vs.85).aspx ... View more

Generally, languages that the installer engine doesn't natively support (and InstallShield doesn't provide a solution to support) require you to either use script or a SystemSearch/EXE custom action to find the command line interpreter (probably javaw.exe, yes?) and pass in the path to the file to execute. This solution prevents you from accessing the MSI API, which lets you do things like read/set property values, write to the log file, etc. If you're just starting this is probably not that onerous of a limitation. If this is a dealbreaker, there's the enticing possibility of finding (or writing) an ActiveScript bridge to Java, which would let you host the Java engine under Msiexec.exe. But that's expert level stuff, and I've never found any pre-existing ActiveScript bridge that did anything but crash when loading under Msiexec.exe. (There's a couple of exceptions: VBScript and Javascript, both of which are natively supported already...) ... View more

There's no built in function in InstallScript for it, but you could write create a Mutex if one doesn't already exist during OnBegin using Windows API. Check out this thread: https://community.flexerasoftware.com/showthread.php?217331-call-Winapi-OpenMutex-from-InstallScript-problem ... View more

I would add as well, thinking about it: It's unusual that your setup requires the *.msi for uninstallation. It may be that you can fix this problem itself. Check the uninstall log for "ResolveSource" to see what is triggering it. You shouldn't need this action firing off unless there's a good reason. The default for new projects is to have a condition on the action in the sequence to prevent this very thing. ... View more