I created an MSI setup via Visual Studio 2008 for my application, and added a registry key to windows\run for automatic startup, but also implemented a function in my application to disable automatic startup. However, when the application is restarted, the key is automatically repaired.
How to prevent MSI from repairing the key??
Thank you!
The registry key is repaired because it was installed by your package and Windows Installer knows that it should be present. Some possible solutions are:
Move the entry in a separate component which doesn't have a Component ID. This way the component is not registered with Windows Installer.
Use a custom action to create the registry entry during install.
Related
My IT dept. is telling me that usually apps copy the install MSI to ProgramData\PackageCache and updates the registry key to point to this location. They want me to do this. The registry shows this for other apps:
My apps are not doing it like that as you can see.
How do I get my apps to copy the MSI to the Package Cache folder and change the InstallLocation registry key? Is there a setting for this in the Setup Project or do I have to do these two steps with a custom action to copy the file and a registry action to edit the key?
This is the first time for me making installers so I'm a little new to it.
The behavior you are describing comes from installing an installation package (like an MSI) via a WiX Bundle. If you aren't using a Bundle, you shouldn't find your package in the "Package Cache".
i have created an outlook add in and a setup project for that add in using VS setup. I have changed the properties of the setup project "InstallAllUsers" as true.
It successfully generates the .msi and .exe file.
I run the .exe file or .msi as admin an the add in is registered for a single user only. registry entry is only visible in the HKCU hive not in the HKLM hive.
I am on windows 8.1 , Office 2013.
cheers,
Saurav
I have changed the properties of the setup project "InstallAllUsers" as true.
The InstallAllUsers property doesn't affect the registry hive where the add-in is registered. You need to choose an appropriate windows registry hive manually.
The Deploying an Office Solution by Using Windows Installer article describes all the required steps for creating an MSI installed for Office add-ins (including per-machine).
Is there a way to inject a custom registry setting during installation of Office plugins? Using Visual Studio 2013 and regular "publish" method that generates an .MSI file
You have 2 options for installing: Click Once and Windows Installer (.msi)
Are you sure Publish is creating an .MSI, because in a previous version of Visual Studio it makes a ClickOnce installer which is totally different from an .MSI.
Start here: http://msdn.microsoft.com/en-us/library/bb386179.aspx
I don't think the ClickOnce option gives you the ability to add your own registry settings. If you go the ClickOnce route then it would probably be easiest to add the registry setting in your addin code, assuming the registry location is something like HKCU that the user would have access to. If you need to write to HKLM hive then that requires admin privileges and you shouldn't try doing that from your addin, it will need to be added in a .MSI that runs with admin rights. You can use the InstallShield LE as mentioned in the article, or you could obtain the just released addin for Visual Studio that brings back the old Setup Project (http://blogs.msdn.com/b/visualstudio/archive/2014/04/17/visual-studio-installer-projects-extension.aspx)
In my Visual Studio installer project, I have a dll set to register with COM. I also want to modify a key that is part of the COM registry (The InprocServer32 key). But if I make an entry into the Registry Settings in Visual Studio, the entry gets overwritten by the COM registration.
I used to use a MSI transform to add a registry key to the end of the registry table, where it would overwrite the COM one. However, this was very error-prone, so I decided to switch to the Registry settings in Visual Studio.
How can I make a Registry entry that will overwrite an entry made by the automatic COM registration (i.e. later in the registry table)?
You can't with visual studio projects. This is one of the many limitations of that tool that has caused Microsoft to kill it in the next release of Visual Studio. They reccomended going to InstallShield Limited Edition instead.
If you are going to stick with VDPROJ then the post build processing ( which could include perm. applying the transform to the MSI or using SQL commands to update the table ) would be the way to go. Another approach would be to factor the component out into a WiX merge module that is consumed by VDPROJ. This would give you better control over the component authoring.
Redemption of Visual Studio Deployment Projects
I'm creating a setup pacakage in Visual Studio 2008 to register a COM component and one of the actions is to add a few keys to the registry.
The odd thing about it is when I run the installer it creates the key hierarchy correctly but the last key in the hierarchy it creates has the wrong GUID... whereas its right in the installer... has anyone run into this or have any suggestions on what is going wrong?
Thanks
I had the same (or a similar?) problem, my solution is here: How to register COM from VS Setup project?
Basically I just created the registry keys manually and added them to the setup project as a .reg file :)