0

I noticed within the past couple of weeks my latest builds of a specific project are not showing up in Add/Remove programs.

I am using Visual Studio 2010, Windows7 64-bit (though I've also tried this over two Windows 32-bit machines). All latest service packs and updates are installed. The solution is made up of several projects with various references. The Setup and Deployment project is not the Install Shield version, but the one built in Microsoft project.

Previous versions of the software install fine, and still do... But if I pull down a tagged earlier version from CVS, and rebuild the installer for those versions, they do not work either.

I've opened the MSI in Orca, and I can see that the ARPNOREMOVE, ARPSYSTEMCOMPONENT are both set to 1. When the project gets installed, a registry entry SystemComponent Dword value is created. If I remove that registry entry, the application shows up. Based on everything I've read and researched I have found people that WANTED this functionality, but were told that Visual Studio can't do this on its own. Their solutions were to use Orca to add the ARPNOREMOVE or ARPSYSTEMCOMPONENT. At this point, all of the people who I found had my problem either had a basic default installer and they didn't know what name they were looking for in Add/Remove Programs or some other basic error that doesn't apply in my situation.

I've tried all of the following:

-Previous versions of tagged versions on CVS

-Multiple development machines

-Multiple computers to verify none show up in Add/Remove programs

-Resetting all Visual Studio settings

-Building from a clean development environment

-Removing Installer project from the solution and creating a new installer project

The weird part is that if I create a new solution and just create a setup and deployment project within, that installs fine. Can anyone having any idea about this help me out ?

Community
  • 1
  • 1
Cory
  • 21
  • 1
  • 1
  • Since I'm in desperate mode, I wrote a post build event to modify the installer... all it is doing is removing the entry 'ARPSYSTEMCOMPONENT'. I suppose I'll also need to the do the same with the ARPNOREMOVE, and the others... Surely I'm not the first person this has happened to. – Cory Jul 11 '13 at 14:12

2 Answers2

1

So this is what I found out. We are using National Instruments Measurement Studio for .Net and the legacy controls. When using the legacy controls a certain merge module gets recognized as a dependency. For whatever reason, now this merge module change the behavior of the installer that is compiled. I've contacted National Instruments and am now working with them.

Cory
  • 21
  • 1
  • 1
  • Just install Orca from Windows SDK an take a look into the MergeModule. Either they set the property directly, or they have some custom actions in the merge module. Generally, nobody, who knows MSI, recommends or work with Visual Studio for MSI setups. I work with MSI since more than a decade, and I have just started it in VS for the first time (for you :-) It's just the wrong tool to do more than a demo. – Philm Jul 12 '13 at 20:15
  • Would you be so kind and vote for the answer? My answer was correct for the main project. Of course MMs can make it more complicated. – Philm Jul 12 '13 at 20:37
  • Well, as I stated above, I have already used Orca. The properties are in there. Outside of the properties, nothing seems to be abnormal, unless you want to give some guidance on where to look. – Cory Jul 15 '13 at 11:41
  • I am not sure, if I understand, what is still your problem. As far as I have understood: You have found that you use a merge module (MM) in your build process, it contains the property ARPSYSTEMCOMPONENT with value 1 for example. (as you say). So most easiest way to load the MM in Orca , remove the line of ARPSYSTEMCOMPONENT (because it can not be relevant to merge modules, moreover it breaks best practice), save the MM and use this for your project. – Philm Jul 21 '13 at 18:49
  • 1
    But if you have still no idea where exactly the unwanted value of ARPSYSTEMCOMPONENT is coming from, then you don't need a post build event, but it would be quite easy to add a custom action of type 51 setting ARPSYSTEMCOMPONENT and the other properties to en empty value. It can be tricky where in the InstallExecuteSequence to insert that custom action. First try would be directly after "CostFinalize", if that doesn't help, maybe after "StartServices". – Philm Jul 21 '13 at 18:58
0

First, yes, you figured out the correct property name. Yes, ARPSYSTEMCOMPONENT is it which leads to an "unvisible" install under Add/Remove programs (ARP for insiders, although the name has changed post XP). And it is possible to set/change the resulting "SystemComponent" entry in registry later which is not the case for all properties.

ARPNOREMOVE just controls if the uninstall in ARP is really possible to perform.

I have looked into Visual Installer before really, because it is so limited for MSI experts, but after taking a quick look there is a .vdproj (project file) created with VS 2010, and not very surprisingly, all the MSI information is coded there. The visual setup editors you can see in the solution explorer are only a subset. Just look for "ARP" and you will find some properties set. The meanings of the values are maybe not so easy to guess, but from a rational point of view:

Either there is some setting inside there or a custom action (listed there too) which sets that property!

In my minimal test with the wizard only the ARPCONTACT property was set in the resulting msi file.

At least you could take the .vdproj file cor diffs with other checkedin versions..

Philm
  • 3,448
  • 1
  • 29
  • 28
  • The properties are not in the VDProj. The VDProj file does have some attributes which get compiled in to the MSI, but these are not a part of this. I think I'm on to something, I'll report back in tomorrow with the findings. I have a feeling a third party control suite may be getting affected by recent Windows Updates. – Cory Jul 11 '13 at 20:59