After the windows 10 anniversary update Install packages created using Visual Studio 2015 with InstallShield 2015 LE which contain project outputs which need to have the installer class option checked in the output properties COM & .NET Settings Fail to install with an Error 1001. In my case I have several windows services and some MMC Snap-In’s which need to use the Installer Class Option fail to install now.
I set up a clean system with Windows 10, visual studio 2015 (w/ updates and patches) and InstallShield 2015 LE only. I created a base windows service project added the project installer in the service project and compiled. I added no code to the service. I then created an install shield project added the primary output and checked the installer class option in the output properties. Created the install and tested the install, which was successful and the services was installed and available in services.
After updating the windows 10 system with the windows 10 anniversary update and rebuilding the install for the project, the install fails with error: 1001. I am aware of the InstallShield Service section of the install project, but using this workaround does not address the failure on installing my MMC Snap-In’s, I have this issue on multiple windows 10 systems now and with every project which contains a windows service or MMC Snap-In. I would hate to recreate all my installs and go back to the Microsoft setup and deployment project since it does not seem to have this problem.
We're having the same issue. One of our VM's upgraded itself overnight to Windows 10 Anniversary and now the MSI's build from that VM will not work because of Custom Actions.
We're not installing services, but have some logic in an installer library that needs to run. Before the anniversary update the builds ran fine. Looking at the MSI created between a build that works (pre anniversary) and one that doesn't (post-anniversary), there's a number of details missing in the new MSI that relate to the Installer Class.
This is quite an issue for us. We had the same issue when .Net was updated on an InstallShield 2012 LE inatallation a year ago which required us to either rollback the .Net install or upgrade to 2015. Is there any resolution to this?
It's a little concerning that there's no response after 20 days of the OP.
I think I have seen this behavior before on certain environments.
The workaround was create a windows service in visual studio as a separate project and create an InstallShield project. Then, add the service file not as "primary output" but just select the file by itself. In the service section, create the service referencing that file.
I am not sure why the anniversary update would change the behavior at the moment. Some more tests will be needed to narrow down the issue.
