Visual Studio Installer - Registry keys being overwritten by COM - visual-studio

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

Related

Creating custom registry settings during installation of Office addins

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)

Deploy a VSPackage to create a new project type using Setup Project

I create a new custom project type using a VSPackage project inheriting of MPF library (http://mpfproj11.codeplex.com/). As a result I obtain a .vsix but I need add this project type using a .msi. I'm using the Visual Studio 2010 Setup projet for it. In my setup project I add the content of the VS Package in the same directory where the .vsix put then, but I think Ineed to put in the registre the new type of project because when I use the setup , the project template does not come out in Visual Studio and when I give double click the file with extension of the type of new project and does not recognize it. When I look the registry after install the vsix, this was one of the things that I found diferent. I add this entries in my setup project but It's not working yet.I'm missing something else?
In the projecttemplatedir is the directory where I put the .dll of the project type, the vsixmifest and pkgdef. The project template is in [User]\Documents\Visual Studio 2013\Templates\ProjectTemplates\[Name of new Project Type]\[projecttemplate.zip]
Best Regards
PS: The project type is for VS 2013 but I'm using the VS 2010 Setup project ;)
OK, so first the "don't"s of doing this:
In general, if you are installing via MSI you shouldn't be doing anything user-specific -- no writing in HKEY_CURRENT_USER, nor writing within their Documents folder, LocalAppData, or Visual Studio folders, etc. If you see yourself writing files or registry keys in either of those places, that should be your hint that there's a better way to do what you're trying to do. For what you've shown so far, this raises more than a few red flags for me.
Second, don't ever go writing keys into 12.0_Config. That part of the hive is nothing more than a cache that's built up from other parts of the registry and on-disk .pkgdef files from extensions. It's rebuilt in any number of senarios, including installing new extensions. Any writes there you should presume will get blown away at any time. If you need to write things there you should either (a) write in HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\[version] and run devenv /setup or (2) [preferred] put your keys in a .pkgdef inside your extension which gets merged into 12.0_Config for you automatically.
Now the dos:
You said you already had a .vsix produced by the SDK: you can put project templates in there. You can then register those templates in the .vsixmanifest and those will pull in. That's far easier than mucking around with files in Documents -- that's the user's directory...don't go playing with that.
Once you have a .vsix that does most of what you need, you should simply take the files within that and install the files in a folder within C:\Program Files [(x86)]\Microsoft Visual Studio 12.0\Common7\IDE\Extensions. Even better, you might just want to WiX toolset to build your installer, since it has built-in support for installing extensions. It also has built-in support for invoking the "/setup" process if that's what you need to do as well. Visual Studio Setup projects are no longer supported in newer versions of Visual Studio, so you're better off starting with a technology that isn't already obsolete. WiX is even what we use at Microsoft to do the setup work for Visual Studio itself, so it's definitely up to the task.
Last point: almost everything when it comes to Visual Studio extensibility can be done with a VSIX directly, so presume there's a good way to do something that way before falling back to an MSI. Internally, we can register the entire C# and VB language services with just a VSIX -- they're quite powerful.
I found the answer in this link Registering Project and Item Templates. I set projecttemplatedir entry with
[User]\Documents\Visual Studio 2013\Templates\ProjectTemplates[Name of new Project Type][projecttemplate.zip] that is where i put the project template.

MSI prevent registry key repair

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.

How to include ignored files when using Publish tool in VS2010?

I have a directory /media/fonts in my asp.net mvc project which contains fonts for my website. When I use the "Publish" tool in Visual Studio this folder is ignored even though it is included in my project. Other folders /media/images and /media/css are included just fine.
Is there any way to tell Visual Studio to not ignore this folder on publish?
Select your font files and Change Build action as Content from Properties Window.
You can fix this permanently by modifying the default Build Action for font file extensions (.eot, .ttf, etc)
http://blog.andreloker.de/post/2010/07/02/Visual-Studio-default-build-action-for-non-default-file-types.aspx
The link has been assassinated by the cruel march of time, so here's a copy/paste of its contents:
The default build action of a file type can be configured in the registry. However, instead of hacking the registry manually, we use a much better approach: pkgdef files (a good article about pkgdef files). In essence, pkdef are configuration files similar to .reg files that define registry keys and values that are automatically merged into the correct location in the real registry. If the pkgfile is removed, the changes are automatically undone. Thus, you can safely modify the registry without the danger of breaking anything – or at least, it’s easy to undo the damage.
Finally, here’s an example of how to change the default build action of a file type:
[$RootKey$\Projects{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}\FileExtensions.spark]
"DefaultBuildAction"="Content"
The Guid in the key refers to project type. In this case, {FAE04EC0-301F-11D3-BF4B-00C04F79EFBC} means “C# projects”. A rather comprehensive list of project type guids can be found here. Although it does not cover Visual Studio 2010 explicitly, the Guids apply to the current version as well. By the way, we can use C# as the project type here, because C# based MVC projects are in fact C# projects (and web application projects). For Visual Basic, you’d use {F184B08F-C81C-45F6-A57F-5ABD9991F28F} instead.
$RootKey$ is an abstraction of the real registry key that Visual Studio stores the configuration under:
HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0_Config
(Note: Do not try to manually edit anything under this key as it can be overwritten at any time by Visual Studio).
The rest should be self explanatory: this option sets the default build action of .spark files to “Content”, so those files are included in the publishing process.
All you need to do now is to put this piece of text into a file with the extension pkgdef, put it somewhere under
%PROGRAMFILES(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\Extensions
(on 64-bit systems) or
%PROGRAMFILES(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\Extensions
(on 32-bit systems) and Visual Studio will load and apply the settings automatically the next time it starts. To undo the changes, simply remove the files.
Visual Studio does publish font files. In a special case we renamed extensions from .ttf to .jpg and they got published.

Registering dll's in the GAC using Visual Studio Installer

I want to register/unregister my project's assemblies in the GAC using Visual Studio's Setup installer project.
I am thinking of using a custom installer to utilise the Install() and Uninstall() methods to write commmandline (in code) commands via the gacutil.exe.
Is there an easier way - or is this the way you would do this? Please keep responses within the scope of using Visual Studio tools (not Installshield or WISE etc)
Cheers.
You cannot rely on gacutil.exe, it will not be available on the target machine. Only machines that have the Windows SDK installed have it. The Visual Studio Setup project supports registering assemblies in the GAC without any custom tool. Right-click "File System on Target Machine" and select "Global Assembly Cache Folder".
You can install assemblies to the GAC by adding a Global Assembly Cache folder as part of the destination file system.

Resources