I'm building a visual studio extension that needs to be installed via MSI (so that the icon type shows up in Explorer, primarily).
When I run it from the debugger in the experimental instance, everything is fine. But when I install it in the main VS instance, the extension shows up in the list of extensions, but it's marked as [Disabled].
I've verified that:
The directory is being created in Visual Studio\12.0\Extensions, and that it has the appropriate content.
The Registry key HKCU\Software\Microsoft\12.0\ExtensionManager\EnabledExtensions) has an appropriate value containing the directory name;
The registry key HKCU\Software\Microsoft\12.0\ExtensionManager\ExtensionTypes has an appropriate value containing Microsoft.VisualStudio.VsPackage;
I've run devenv /setup manually before checking.
No matter what, the extension is marked as disabled.
What am I doing wrong?
Be aware that the VS Extension Manager cannot enable or disable MSI-based extension.
http://msdn.microsoft.com/en-us/library/vstudio/dd393694(v=vs.100).aspx
You can try to build/deploy your MSI-based extension by using one of the methods debated in the following links and see if helps.
How to programmatically enable visual studio extension
How can I automatically enable a VSIX extension, when installing?
http://social.msdn.microsoft.com/Forums/en-US/5ccaa3a8-be13-4b3d-859a-0fd5d0dc7214/visual-studio-extensions-not-getting-enabled-automatically-after-installation?forum=winformssetup
Related
We're working in quite a large project and is having a hard time getting people to configure their Visual Studio correct (tabs instead of spaces etc.). We found a great solution in using the EditorConfig extension for Visual Studio.
However there are still some developers that seems to ignore our request to install this extension to their Visual Studio and hence I'm wondering if there is any way to force an extension to be installed before a solution can be opened, maybe some setting in the .sln file?
No there is no such option built-in. If your machines are domain joined, you could push out the installer through System Center or domain logon scripts.
You could cheat and create a solution level pre-build step. Create a target file named: before.{solutionname.sln}.targets and store it next to your solution file. Check it into source control. In the targets file you can use standard MsBuild to see if the extension is installed (you'll need to check the file system probably) and if not present force the installation by calling vsixinstaller.exe to trigger the install.
Anyone had a need ( or more importantly, know how ) to move a Visual Studio Add-in from one machine to another? Of course it would be easy if I had access to the .vsix, but that's in a bit bucket somewhere. I tried poking around the registry and File Explorer, but didn't see anything likely.
Doing a Tools / Import and Export Settings got part of it - there's a placeholder on the toolbar that has the add-in's name, but none of the buttons show, and, unlike the original machine, the new machine's dropdown to Add / Remove buttons shows nothing.
First you need to find an .AddIn file that declares an add-in for Visual Studio. Usually it is located in the "c:\Users[user_name]\Documents\Visual Studio 2013\Addins\" directory, but can be in any Add-in File Paths listed in Options - Environment - Add-in Security.
In the .AddIn file there is an Assembly entry that contains a .dll name that implements the add-in.
You need to copy both files (.AddIn and .dll) to a new machine, plus optional auxiliary add-in files.
(BTW .vsix is not used to deploy add-ins.)
I recommend using the guide - Syncing Visual Studio Extensions and Settings with Dropbox :
http://www.larswilhelmsen.com/2012/01/08/syncing-visual-studio-extensions-and-settings-with-dropbox/
and complete it as you did with the Import and Export Settings (as noted in the guide too).
Other than that, there is not VS2013 extension for exporting VS extension, the only extention which work well is for VS2010 - ExtensionSync.
Source: https://visualstudiogallery.msdn.microsoft.com/dbaf0ac9-fb7b-4fb3-b34d-ea2269276d3c
Is there a way to disable the warning prompt that pops up when vs2010 finds a dll file locked by another user during a build? I'm using visual studio 2010 with TFS 2008.
By default, TFS disables shared check-outs for binary files - this is enforced for any user, including the build process.
If you wish to enabled shared check-outs for all files, you can update the file extension list for mergeable files: see the Managing File Types article on MSDN.
I'm gonna try Edward's solution once i have proper rights on the TFS but for now I've changed my settings as follows:
This way it avoids the prompt, and also checks out any files i edit once i save em.
I created a multi-project template using the example from vsix.codeplex.com
When I hit run, the extension is installed and works in the Experimental Instance of Visual Studio 2010.
When I try to install it (to the non experimental instances), despite the installation succeeded message and the files being copied to:
%LocalAppdata%\Microsoft\VisualStudio\10.0\Extensions
I can not find the extension in the "Extension Manager" or see the template in the "Add New Project" dialog.
After uninstalling from experimental instance and deleting copied files,
I noticed that after installing files are copied to both
%LocalAppdata%\Microsoft\VisualStudio\10.0\Extensions
and
%LocalAppdata%\Microsoft\VisualStudio\10.0Exp\Extensions
and the extension appears in the experimental instance's extension manager, but not in the regular instance's extension manager.
VS's activity log states extension is loaded and enabled.
Extension works on non-experimental instance on another PC.
Perhaps there is another extension/add-on that I have that overrides this one?
Tried changing snk files and GUIDs, didn't help.
After installing my regular instance's extensions to experimental instance (redownloading them one by one), and running my extension after every few installations, I found that indeed a specific extension prevents my extension from loading (despite log files state it was successfully loaded).
So if you have this problem you can use this workflow:
Make a list of all extension you have installed in VS2010.
Load your extension's sln, configured to run experimental instance of VS.
Run (Ctrl+F5).
Uninstall your extension, install other extensions.
Close experimental instance of VS.
Run (Ctrl+F5).
If your extension appears in extension manager, goto 4, if not goto 8.
Try uninstalling one of the latest installed extensions from experimental instance of VS.
Close experimental instance of VS.
Run (Ctrl+F5).
If your extension now appears you have found the colliding extension. If not goto 8.
Use this link and repair you will then see the MVC 4 project.
http://www.microsoft.com/en-ca/download/confirmation.aspx?id=30683
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.