A link to this example is at the bottom of the help doc for GetEnvVar http://kb.flexerasoftware.com/doc/Helpnet/installshield15helplib/GetresEnv_variable_example.htm ... View more

Look at: http://msdn.microsoft.com/en-us/library/windows/desktop/ms682653(v=vs.85).aspx SetEvironmentVariable only modifies the current processes copy of the environment variables. The above doc says to persist a change to the registry. I think at one time I used the code at: see www.installsite.org > InstallScript Samples > Operating System > Handle PATH Environment on NT. But that was a while ago and I do not know how it would play on Win 7. ... View more

To just exit the setup at the end of your function use: exit; If you want it to look like it is being canceled then use: abort; I don't recall using Do(Exit) in my many years of InstallScript, but if you want to use it then you can add the OnCanceling handler to your project and modify the behavior if you like. Phill ... View more

What you say you want to do can be done pretty easy in InstallScript without any custom dialogs. In fact since you are not installing applications, features, or components, a more general tool like a c# app or even a batch script may even be simpler. Off the top of my head (without InstallShield handy to check this) 1) Create an InstallScript project, just accept all of the defaults in the new project wizard unless you want to add localization or something. 2) Your description implies that you do not need maintenance (repair, modify, uninstall) support. If correct go to Project\Settings and on the Maintenance tab select 'no uninstall or maintenance'. 3) You can put your code at the top of the OnFirstUIBefore function and then call Exit so that the rest of that default code is never executed, since you are not installing anything. As part of your InstallShield IDE, in the Start menu (for IS2012 Spring) is a tool that demonstrates all of the built in dialogs. You can look through those choices and select the dialog that is best for your situation. It sounds like you want to: Call AskPath or SdAskDestPath (there are several other possibilities) Then call AskText and save that string. If you need to make layout or text changes to the default dialogs look at your Dialogs view and select which ever dialog you selected above and edit it. (If you decide to use skins make sure you select the skin before you make any dialog layout changes.) Then do something similar to the functional body of the WriteLine example http://kb.flexerasoftware.com/doc/Helpnet/installshield14langref/LangrefWriteLine_Example.htm The actual WriteLine example function prototype is for a MSI custom action which is not what you want. Ignore the function protoype and just use the code in your project to create the file at the path you already collected and write the line of text that you collected. Then call Exit; ... View more

Are you running it as Immediate or deferred, non-impersonated? I would expect deferred - non impersonated to run in the services winstation from which interaction with the user should not be initiated. ... View more

I launch dism.exe /online with additional switches depending on what I am doing. http://technet.microsoft.com/en-us/library/dd744582(v=ws.10).aspx http://technet.microsoft.com/en-us/library/ee441260(v=ws.10).aspx I believe that DISM.exe is the preferred method over scripting (which may be disabled) and over deprecated tools like pgkmng.exe. Phill ... View more

Did you do the steps detailed here: http://kb.flexerasoftware.com/doc/Helpnet/installshield19helplib/helplibrary/STasks-Adding.htm The question combines to issues. 1)creating a scheduled task in MSI and 2) interacting with power shell from an MSI. I would break the problem into two steps and just create a task that does not use power shell, and then focus on the power shell using info from here: http://blogs.technet.com/b/heyscriptingguy/archive/2011/01/12/use-scheduled-tasks-to-run-powershell-commands-on-windows.aspx ... View more

I do not know the answer to your issue, but the MSI link that you referenced is explaining the sequence in which those particular properties are evaluated by the msi engine that processes the in-script actions. That document in my understanding does not imply that those properties need to be on the command line in any particular order. I suspect that your issue is not related to those particular properties. I would look at the Releases view and the Setup.exe tab and check that the 'MSI Command-line Arguments field is correct (or rather does not have extra stuff). I think I would also attempt to produce a similar test project and see if the problem is reproducible. If not, as I suspect, I would then compare the broken project file to the working project file, in an XML editor (or in Direct Editor), to see if I could find the difference. In the General Information view you can set the Project File Format to XML, which I find is useful for finding strange InstallShield issues. I rather doubt that this issue will show up in the Direct Editor. Alternatively if the above field is not set in your project, you might want to set something and see how the InstallScript setup.exe passes that information to the MSI. It might be that setting that field in your project will cause the IDE to re-write that portion of the project file and correct the problem, but I am just guessing. ... View more

I imply from your comments that you are using a MSI project and that you are trying to give a user write access to a folder under the "Program Files" tree. If correct, I think the error you are seeing is because Microsoft does not want you to give users access under the program files tree. To allow users write access to that location is considered a major security breach. A file that a non-privledged user should edit should not be located in this area of the file system. Consider putting the files in the user's appdata folder. If this is not your issue, I apologize. If using MSI the help document that you referenced describes several MSI tables. From within InstallScript code call SetObjectPermissions to configure the permissions of a file or folder. But here again the OS will prevent you from changing the permissions for some of the system-defined folder locations. The call may fail or it may just not do anything when you target a system-defined folder tree (including sub-folders that you create under certian areas). http://helpnet.flexerasoftware.com/installshield18helplib/mergedProjects/installshield18langref/SetObjectPermissions.htm ... View more

The msidbCustomActionTypeTSAware flag differentiates between the user context in which your deferred (i.e. "in-script") custom action will execute. See http://msdn.microsoft.com/en-us/library/windows/desktop/aa368069(v=vs.85).aspx "Executes with user impersonation. Runs with user impersonation during per-machine installs on a server running the Terminal Server role service. Normal deferred execution custom actions, without this attribute, run with no user impersonation on a terminal server during per-machine installations. This attribute has no effect if the action also has the msidbCustomActionTypeNoImpersonate attribute." I admit that I do not have the experience launching a .bat file from a in-script custom action, but my guess is that it depends on what the CA and the .bat are doing and what the user's privileges are. When using Remote Desktop without this flag the CA will run in the context of the remote server's local system account (even if on a 'local' system it would have run using impersonation). With this flag the CA would run in the context of the user that connected to the remote server (unless the 'no impersonation' flag was also used), the same as it would run on the local system. At least that is my understanding. ... View more

This link says that Comctrl version 6 is not redistributable. http://msdn.microsoft.com/en-us/library/windows/desktop/bb773175(v=vs.85).aspx Comctrl version 5 was redistributable by licensed VB5 developers. ... View more

The example code where that snippet came from does indicate that it should be used in a MSI custom action. "Note To call this function in a Basic MSI setup, you must first create a custom action for the entry-point function, execute the custom action in a sequence or as the result of a dialog's control event, and then build the release." http://kb.flexerasoftware.com/doc/Helpnet/installshield15langref/LangrefCreateFile_Example.htm I would agree that the above note does not make it clear that the code will not work, as is, in anything other than a MSI custom action, but that is implied. If your function is not being called in the context of a custom action, then change the function prototype to reflect that there would not be a MSI handle. #define EXAMPLE_DIR "C:\\" #define EXAMPLE_FILE "ISExampl.txt" // Include Ifx.h for built-in InstallScript function prototypes. #include "Ifx.h" export prototype My_CreateFile(); function My_CreateFile() STRING szTitle, szMsg; NUMBER nvFileHandle; begin // Set the file mode to append. OpenFileMode (FILE_MODE_APPEND); ..... ... View more

I have seen similar behavior when the project includes a script-defined variable which is not initialized to a valid path prior to calling the costing function (internal to the 'Out of Space' dialog). The script-defined variable does not need to even relate to the drives that are shown, but if any script-defined variable has an invalid path the underlying costing function bombs out and the dialog uses uninitialized values as you displayed. ... View more

This example code is for an InstallScript MSI Custom Action. Is that what you are trying to create? All MSI Custom Actions have an entry point function which has a single argument typically named "hMSI" which is a handle to the MSI install instance that the Custom Action is running in. In InstallScript code a Windows handle is declared as type HWND. ... View more

I used to write windows services (which was not a setup), and actually when we started developing our product as a windows service, the boss wanted me to take a GUI mode 'server' application and launch it 'as a service' thinking it would run as a service. I currently write setup packages which deploy lots of windows services. I learned quickly that there are a number of reasons why an application written to run in GUI mode may (likely will) have problems 'as a service' and most of the problems relate to the security context differences. 1) A Windows Service runs in a separate "Winstation/Desktop" combination than the interactive Winstation/Desktop. 2) Generally a Windows Service should never try to interact with the user (except through some very specific mechanisms, such as a named pipe to a GUI mode client). 3) When a windows service launches another process using CreateProcess the spawned process ends up in yet another Winstation/Desktop. Windows messages cannot transverse Winstation boundaries, so named pipes or MMF files should be used for the processes to communicate. If a service needs to interact with the spawned process it should first do a LogonAsUser, create a Duplicate of the Impersonation Token, and pass that token to CreateProcessAsUser along with a Startup structure which is loaded with the service's Winstation and Desktop information. 4) A user's profile is only loaded when a user logs into the Interactive Winstation and is only available to processes running in that context (which does not include services). So a service must be coded to load the user's profile to gain access to that users' registry hive and user specific folders. This is just a few of the security context issues related to writing Windows Services. Clearly a tool like InstallShield (InstallScript) or even the client portion of MSI is not designed to be run in a Windows Service context. It is foolish to try and shoehorn it into that context, which will result in security problems in addition to the operational failures that you are observing. Maybe folks can get away with running a simple console type application has little interaction with the user or system resources, and launch it under a wrapper as a windows Service. But a setup.exe which was never designed to be a windows service and which provides such critical functionality I do not believe should be used in this way. Regarding your specific observations they are pretty much the kind of issues I would expect from calling CreateProcess on any application in a Windows Service context. Yes the default Service accounts have very restricted permissions on the local file system on Vista or later, and no access off the box. By impersonating another user within the service these issues can be addressed, but a setup.exe is not designed to do this. When doing /s on an InstallScript package, code 3 means that the script engine could not locate an entry for a dialog in the response file. So when your setup is run in one context you may see one set of dialogs and when it is run in another context you may see a different dialog sequence (an error message or some other dialog). This is probably what is happening to you when you are running in silent mode. Also remember that it not setup.exe that is doing this processing but the underlying engine process which setup.exe has spawned (and in an application not designed to be a service the winstation issue is probably a part of this failure). You can capture a response file doing one dialog sequence and then capture the response file doing another dialog sequence (maybe repair, or an error sequence) and then manually edit the INI format of the response file to add all of the dialog entries into a single response file which handles a wider variety of scenarios to avoid the error 3. I'm sorry for the long answer which does not give you an easy fix, but I hope it helps. I have tried to provide info to others who have reported similar errors trying to launch their setup.exe using a RunAsService wrapper with similar problems. I'm not aware of anyone that has succeeded, particularly without rewriting both setup.exe and the underlying GUI mode engine. Phill ... View more