I faced a similar problem as some of my colleagues are building the solution as me, but I am the only one who has got an InstallShield license (given the price, my employer thought 1 IDE license would suffice). So the ISPROJ was building fine on my machine, but not on my team-members' machines. Here is a description of one possible resolution. Unfortunately, I don't have the files with me right now and I might not remember everything, so take this description with some caution. To solve my problem, the idea is to import the right InstallShield.targets file if it is present, and import a dummy targets file if it isn't. This dummy ".targets" file contains a "Build" target that only displays a message. So here we go: I created a NoInstallShield.targets file and saved it in the same folder as the ISPROJ. I don't remember the exact content, but this NoInstallShield.targets file mainly contains one "Build" target that displays a message. Useless to say, I added this file to the source-control. Now in the ISPROJ file: I added a condition to the import element, something like: It means the InstallShield.targets is only imported if it exists. Then I added the following line, just below the import I've just mentioned. This one imports the NoInstallShield.targets if the InstallShield.targets file does not exist. The only remaining problem is a message that Visual Studio displays when opening the solution on a machine that does not know what to do with ISPROJ (ie a development machine without any InstallShield installed), but it's something we can live with. In any case, you can easily reuse the idea to resolve your problem: Import one InstallShield.targets file if it exists Import the other InstallShield.targets file if it exists. If none of them exist, import a dummy target file. So your imports in your ISPROJ would look like this: HINT: Instead of copy-pasting the whole path of the target everywhere in your ISPROJ file, you could define an MSBuild property. ... View more

Why don't you show us the error messages you are getting? Or even better create a dummy solution that shows the error and attach it to this thread? ... View more

I think your question is more related to Visual Studio than InstallShield, but here we go... Why don't you create several solution configurations, then set the projects to build for each solution configuration? So let's assume you have the following solution/project structure (see image 1) Now, you go in the configuration manager, and create some more solution configurations, all based on the "Release" solution configuration, like Release01, Release02, Release03. Then you set which project to build for each solution configuration (see images 2, 3 & 4) Now, you need to pass the solution configuration as "Configuration" property on the command line: msbuild /t:Build /p:Configuration=Release01 MyDeploymentSolution.sln. You should see the following lines in the output: Does that help? ... View more

Hi there, Please correct me if I'm wrong, but I am under the impression that what you are trying to do applies to Web Deployment Projects in Visual Studio. I don't think that the InstallShield.targets knows what to do with the items. So, I'm a bit confused about your question. Do you want to tell us a bit more about what you are trying to achieve and what type of project you are working on? As for the logs, you can add a task pretty much in any target you want. See here for more info: https://msdn.microsoft.com/en-us/library/6yy0yx8d.aspx If you build your project by calling MSbuild from the command line, your message will appear in the console window. If you build your project with a build server, it will appear in the log file. But you need to set the right verbosity level either as parameter of your msbuild command (/v:diag), or by setting some attributes of your build definition when launching a build. The verbosity level is directly related to the importance of your message: the message task has an "importance" attribute. Have you tried to set it to "high"? I hope that helps. ... View more

Is your MSI a 64 bit package? You are saying that it crashes. But does msiexec.exe really crash? Or does the installation just fail? What about logging the installation? msiexec /i MyPackage /L*vx C:\TempLog.txt Analyzing the logfile should allow to point you in the right direction. ... View more

Calling ISCmdBld.exe from our MSBuild script, using an task was our first idea, before we understood that this mechanism was already available thanks to the InstallShield integration with MSBuild. Here is a bottom-up explanation: You might notice that the InstallShield setup added the following file: C:\Program Files (x86)\MSBuild\InstallShield\2013\InstallShield.targets This file contains everything needed to call IsCmdBld.exe with all the required parameters. You might notice the InstallShield task in this file: The ISPROJ file I mentioned in my earlier post imports this InstallShield.targets file. Your ISPROJ also refers your ISM file, and this ISPROJ is part of a VS solution. This mechanism allows to call IsCmdBld.exe when building your solution. Now let's summarize it, this time from top to bottom: You call MSBuild /t:Build /p:Configuration=Release MySolution.sln MSBuild builds your projects in your solution. MSBuild executes the "Build" target of your ISPROJ. Your ISPROJ will execute the "Build" target defined in the "InstallShield.targets" file. This will call IsCmdBld.exe and build your Installation package. Pros: You don't need to worry about what executable needs to be called, and how to call it. You don't need to worry about the path of IsCmdBld.exe (which might vary on a build server where only IS Standalone Build is available) When you upgrade to the next release of InstallShield, all you need to do is: Upgrade your ISM file (which you do anyway). Change the path of the InstallShield.targets file in the ISPROJ file. Cons: There is not much documentation available about how to customize your ISPROJ file, which properties and items you must define to choose the Release/Product Configuration you want to build, override the merge module paths override some MSI properties override some path variables... You might need to analyze the InstallShield.targets file to find that out. ... View more

I assume you already have your ISM file. I would start by integrating in project in a Visual Studio solution. This will create an ISPROJ file. This file refers your ISM file, and allows to build your InstallShield project when building your solution (e.g. MyInstallationSolution.sln). This ISPROJ file can then be tweaked to change MSI properties, override Path variables, add a Merge Module Path... It looks a bit like a VCXPROJ, or a CSPROJ file, with some MSBuild Items and Properties. Once you have your InstallShield project integrated into your solution, you need to be able to build your solution from the command line with MSBuild: MSBuild /t:Build /p:Configuration=Release /p:SomeMSBuildProperties=Blabla MyInstallationSolution.sln To do this, I recommend to launch a Visual Studio 20xx Command Prompt x86 as Administrator. You can then create your own MSBuild file to build your whole application and your installation solution (e.g. ApplicationBuild.msbuild). Your build definition will then refer this msbuild file. You will find a whole section about the integration with Team Foundation Server in the InstallShield User Guide (http://helpnet.flexerasoftware.com/installshield21helplib/helplibrary/TFS-Overview.htm). Here are some more hints. They only reflect my humble opinion and some people might prefer to do it differently: Do create a separate solution for your InstallShield project(s). This allows to isolate your installation solution from other projects that developers are working on. I am not a fan of how the InstallShield integration in Visual Studio creates new components for the new CSPROJ or VCXPROJ we add to our VS solutions. I don't like how the InstallShield integration in Visual Studio creates new releases in my ISM file when I change the Solution configuration (debug/release...). So I avoid editing my Installation project through Visual Studio. I stick to InstallShield for editing the ISM file. It might be worth spending time learning how to use MSBuild. How to use properties, items, tasks and targets, etc... ... View more

Hi, Your post is not very clear. Does your application stop working after you've installed InstallShield 2013? Or after you have installed it on a PC that previously had Office on it, knowing that you built its setup with InstallShield 2013? I assume you are talking about the latter. I would assume that your setup simply broke one or more Office component. You can either go through all the components you are installing and see whether they could interfere with Office. Or you can enable Windows Installer logging in the registry, then log what the Office setup automatically repairs. You should be able to see what Office component was broken by analyzing the log file. ... View more

Hi there, I agree with you: the major upgrade has a few drawbacks, but it allows you to do what the minor upgrade does not support: you can remove components/files in a new version of your product. You are facing the usual problem with dynamic links: you want InstallShield to automatically generate components for all files and subfolders that are present in a source folder, but you have to support minor upgrades, so you are not allowed to remove components/files. Because you are using dynamic links, you will not even notice when a file is removed, which in turns will provoke errors in your minor upgrade scenarios. If you really want to use dynamic links and stick to minor upgrades, then you need to perform validation so that you are notified of such problems (see my previous post) If the validation detects that some files have been removed, then you have to change your ProductCode, which brings you to the major upgrade scenario. As for the drawbacks of Major Upgrades: The feature state: there is a standard action called MigrateFeatureStates. More about it here: http://msdn.microsoft.com/en-us/library/aa370034%28v=vs.85%29.aspx As for the installation path, you can actually implement a custom action that will only run when the major upgrade takes place. This custom action can detect the installation path of the previous installation by calling MsiGetProductInfo, and call MsiSetTargetPath to set INSTALLDIR accordingly. By default the user experience of a major upgrade is nearly the same as a first installation (http://helpnet.flexerasoftware.com/installshield20helplib/Content/helplibrary/MajorUpgrade.htm). But you can customize the behaviour of your installation during a major upgrade. You can hide the feature selection dialog, you can also hide the target folder selection dialog. That's up to you. Last but not least, you can actually update the ProductCode with every build: If you are running a build script, you can use the IS automation. If your build is based on MSBuild, you can override the ProductCode property at each build. ... View more

Yep, you need to define some component conditions. See the screenshot below. You must define a condition that uses the "VersionNT" (and/or "VersionNT64) property. See here: http://msdn.microsoft.com/en-us/library/aa372495%28v=vs.85%29.aspx I hope that helps. Regards ... View more

Hi there, We faced the same issue a few years ago. The assembly precompilation during installation is a buggy feature that has not been fixed since it was integrated in InstallShield. We ended up implementing our own mechanism to queue the assemblies in the ngen queue. So we now have a simple way to add components to a list of assemblies that will be added to the precompilation queue. If we want to precompile one assembly that we install, all we need to do is add it to one custom table. Here is a brief description: Add an NGenAssembly table. The key column is "Component_" which points to the first column of the "Component" table. The other columns nearly map 1:1 to the options of ngen.exe For installation Add a custom action (scheduled for immediate execution) that iterates through this table, and add all assemblies to a list with the relevant options for ngen. Add a custom action (scheduled for deferred execution) which uses the list you previously created. This custom action will actually call ngen with the relevant options for every listed item. Add a custom action (scheduled for rollback execution) which remove the assemblies from the ngen queue. This is needed because you need to be able to rollback any action that modified the target system. For deinstallation Create 3 custom actions that do nearly the opposite from the ones above. It took me a while to implement it, but it was worth it, as I can now simply add or remove assemblies to the precompilation list by adding rows to the NGenAssembly table. I wish the InstallShield team had thought of such a mechanism instead of creating buggy custom actions. ... View more

Hi, What type of project are you working on? InstallScript? Basic MSI? InstallScript MSI? Maybe you can define some Component conditions? And may I just ask (I'm just being nosey): what is your use case? I understand the need to install some files depending on which OS is installed, but your application will not work correctly if your customers upgrade their OS. Regards, ... View more

Hi Ralf, We did exactly the same as you while our product was under development. We used Dynamic File Linking for resources that were likely to be quite volatile (images, texts, config files). Using Dynamic Files is great in one way, because you don't have to worry about changes in the amount of files that are added to your installation package. But it has a hell of a drawback: You won't notice if a file is removed. And the point is: you are not allowed to remove a file (or rename it) in a minor upgrade scenario. There is a workaround: in theory you could use the RemoveFile table to list the files that have been removed between 2 builds, but that's precisely the sort of things you are trying to avoid by using dynamic files. Moreover, the component and file keys in the resulting MSI database are random for dynamic files, which makes it practically impossible to handle in the RemoveFile table. So you can do 2 things: Bare in mind that you may not remove files if you want to perform a minor upgrade.There are 3 steps that will allow you to get notified if a file has been removed: [LIST=1] Make sure all dynamic links use the "Create best practice components" setting. Under "Media->Upgrades->Prepare Setup for Upgrade Scenarios->Upgrade Windows Installer Setup", add a Minor Upgrade Item which will allow to perform validation against the previous build of your package. Under "Media->Releases->Build", use the "Previous Package" setting to point on the previous build of your package. This will allow to keep the dynamic file keys consistent across releases. Forget about Minor Upgrades and go for a Major Upgrade. I hope that helps. ... View more

Hi Josh, Thanks a lot for your answer! I wish the support technician had escalated the corresponding incident to you. It would have saved me a long time finding a way to isolate this bug. But there is something I have missed there: according to the release notes of IS 2012 Spring SP1, this bug should have been resolved in the version I'm using. ... View more

Hi there, Thanks for the link Marek22! I did a few tries with the UseAPIRegistryHooks registry value, and it helped to point me in the right direction. So, it took me a very long time to nail that one down. With the help of Tech Support, I finally managed to isolate the problem by following this procedure (in a VM) Install Windows 7 x64 Install Visual Studio 2010 and its SP1, but do not start Visual Studio yet. Install InstallShield 2012 Spring with its SP1 Build the affected MSI package --> The COM extraction works fine. Start Visual Studio. When started for the first time, it asks what sort of project it will mostly be used for (Choose your default environment settings). In my case, I usually choose Visual C++ Development Settings. Then Visual Studio loads the user settings. Build the affected MSI package --> The COM extraction is erroneous. From there, I analyzed what happened in the Registry when starting Visual Studio for the first time. When starting VS (not launching it as Administrator), it creates some user-specific registry entries under the following keys: [HKEY_CURRENT_USER\Software\Classes\Interface] [HKEY_CURRENT_USER\Software\Classes\TypeLib] [HKEY_CURRENT_USER\Software\Classes\Wow6432Node] Once these entries exist, the COM extraction at build no longer works in the same way, and the resulting Registry table is erroneous. If you delete (or rename) the above registry keys, the COM extraction at build works fine again. So, it looks like a bug in InstallShield 2012 Spring SP1 to me. And it has nothing to do with registering my COM server on my development machine. I could register or unregister my COM server on my machine, the COM extraction was still erroneous. So the title of this thread is a bit misleading... Funnily enough, this issue seems to be fixed in InstallShield 2013 SP1. What I would still like to know is: Was that a known issue in IS 2012 Spring SP1? Is there a hotfix available? ... View more