Some years ago we made a Visual Studio Add-in, which uses the build events as trigger for the action. The Add-in was working in the IDE and the Command Line mode. To load the Add-in for command-line builds, you had to set the <CommandLineSafe>1</CommandLineSafe> option.
The migrated extension works in the IDE mode, but the extension is not loaded during command-line builds.
How is the configuration to load the extension for command-line builds?
Information about loading Visual Studio extension packages can be found here: https://msdn.microsoft.com/en-us/library/bb166762.aspx and here: https://msdn.microsoft.com/en-us/library/microsoft.visualstudio.shell.provideautoloadattribute.aspx
You can mark your package class with the ProvideAutoLoadAttribute in combination with an UI context, for instance:
[ProvideAutoLoad(UIContextGuids.EmptySolution)]
public class MyCustomPackage : VSPackage
{
...
}
It´s possible to have more than one attribute specified. Available UI contexts are defined by the UIContextGuids type.
In one of my extension I use a combination of the following UI contexts to assure that my package always loads irrespective whether there´s a solution loaded, or not: EmptySolution, NoSolution, SolutionExists.
Related
How does Visual Studio (2015) work with external tools like NPM and Typescript compiler (tsc.exe) etc.? I guess, at the time of building the solution or project, something must be telling MSBuild to run these extra tools. I want to understand this under the hood operation.
It all depends...
Visual studio has multiple services and features that interlink here:
Language Services - Visual Studio can be extended with so called language services, these provide intellisense, syntax analysis, highlighting etc. For Javascript and Typescript Microsoft provides a Language service that provides such information.
MsBuild - Underneath most of Visual Studio projects lives an MsBuild project. If you search your Program files directory you'll find an MsBuild folder and underneath that there are a number of target files. This includes one for Typescript which will transform your .ts files during build. These targets files either directly use the exec MsBuild task to run tools or provide a custom MsBuild task in the form of a .NET Assembly that implements specific interfaces. These tasks can either implement the required action themselves or shell out to a tool to have it perform the action.
Roslyn - For C# and VB.NET the parsing of the projects and the background compilation of the sources is handled by a new compiler called Roslyn. This actually runs in the background while you type and has a very powerful in-memory model of all your code in your project. Roslyn supports add-ins as well in the form of analyzers and refactor action that either provide the user with feedback on common errors or provide ways to automatically rewrite/change the code.
Task Runner - The Visual Studio Task Runner is a plugin for Visual Studio that first shipped as an extension and is now part of Visual Studio. It reacts to events in the IDE (build, test, etc) and can associate actions in your package.json or grunt or bower etc scripts. The plugin will make sure your script commands are executed at the right point in time during the builds.
Test Runners - The Visual Studio Test Window has support for extensions as well, so the Mocha and the Chutzpah extension in your project will be picked up and during the test execution these plugins will be asked to first list and later execute the tests. These runners act as a kind of proxy, feeding back the list of tests and their status after execution.
Custom extensions - There are many other ways in which some vendors extend Visual Studio by providing a generic extension. These extensions may contain any of the above elements or may just listen to the events generated by Visual Studio while you do your work and react on them.
You can see the references to the typescript items if you open the .csproj
with a text editor (or from visual studio : unload the project, right-click on the project and choose edit myproject.csproj )
You'll see the typescript resources :
<ItemGroup>
<TypeScriptCompile Include="src\config.ts" />
the target for the build :
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.targets" Condition="Exists('$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.targets')" />
The external tools, are configured in Tools/Options :
There is a bug in the WiX plugin for Visual Studio where file locks on referenced DLLs are not properly released. Therefore, you have to restart Visual Studio every time you want to recompile a custom extension DLL or any assembly referenced by it.
This is a known bug, but the issue was closed because there seems to be a solution / workaround:
You can force the WiX .exes to run out-of-process to avoid the lock
MSBuild has.
I don't understand how to achieve this. I checked...
the properties of my WiX setup project
the properties of the extension assembly (C# class library)
all Visual Studio settings
the available command line arguments of candle.exe
...but did not find anything. What am I missing? How do I apply this workaround?
I'm using WiX 3.10 and Visual Studio 2013.
The example that I've seen several times around the web is to add <RunWixToolsOutOfProc>true</RunWixToolsOutOfProc> to the Wix Installer's project file within a property group. Unfortunately, documentation of this feature has thus far eluded me.
I have created a project using specflow, so I have a new feature file saved as a class library project, when I try and run the project I get the error: 'A project with an Output Type of Class Library cannot be started directly. In order to debug this project, add an executable project to this solution which references the library project. Set the executable project as the startup project'
I think it's an error with the way I have added the n-unit and specflow references to the project. I have noticed I could install specflow via NuGet packages or extensions and updates. So what the difference between adding packages in these two ways?
They are two different things.
the Specflow extension extends the visual studio ide to support specflow. Specifically:
it adds syntax highlighting support for gherkin syntax
it allows the tests to be generated from .feature files
it adds the file templates to the file types so you can add new feature files/step bindings
it adds the additional context menu options to allow steps to be generated and the navigation between steps in the feature file and steps in the code.
it allows integration with the visual studio unit test windows
and probably a few more things that I've neglected to mention. Without this writing specflow tests in visual studio would be more difficult and the generation of the unit test cases themselves would be not be done.
the nuget package allows an individual project to use specflow. This adds the necessary references to the project so that you can consume the types which specflow uses. without these being referenced the projects which try and use specflow would not compile.
As for your issue, this is not related to specflow in any way. A project which builds a dll cannot be started, it needs something to be hosted in in order to be used any project which is a library will give this error if you set it as the startup project regardless of if you use specflow or not.
When I try to use an extension method in the Immediate or Watch windows, I get the following error:
{method} is not a member of {class}
I'm using Visual Studio Community 2013 Update 4, but the issue exists on multiple PCs here, running varying versions of Visual Studio 2013 and 2015.
It makes no difference whether the extension methods come from the .NET BCL, or are defined in our project. The code itself compiles and runs successfully; the issue is only in Immediate and Watch.
I tried setting all projects to framework 4.5.1, and using the x86 configuration, without result.
Adding Imports System.Linq at the beginning of the code file makes no difference (which makes sense, as System.Linq is already globally imported (Project properties -> References -> Imported namespaces)).
What else can be done?
In any context where System.Linq isn't imported you can call the extension methods as normal static methods instead. So for example, the following did not work for me in the QuickWatch window (where actualVariables is a List):
actualVariables.Select(x=>x.Identity.DisplayName)
Change it to this form and then it works:
System.Linq.Enumerable.Select(actualVariables,x=>x.Identity.DisplayName)
I'm trying to figure out how to get a single-file generator installed on VS2010. Previously I got it sort-of working on VS2013 after many hours of head-banging; in both cases the primary difficulty is setting up the registry entries. Apparently VSIX files don't allow registry settings:
You can use the VSIX format to package project and item templates,
Visual Studio Integration Packages, Managed Extensibility Framework
(MEF) components, toolbox controls, assemblies, and custom types. The
VSIX format uses strictly file-based deployment and does not support
writing to the Global Assembly Cache (GAC), or to the system registry.
VSIX is the preferred deployment method for the extension types that
it supports.
My VS2013 solution involves the CodeGeneratorRegistrationAttribute and ComVisible(true) on the assembly, but after install, the extension doesn't work until the user runs devenv.exe /setup in Administrator mode. In VS2010, CodeGeneratorRegistrationAttribute does not exist in any of the SDK DLLs and simply adding the source code of CodeGeneratorRegistrationAttribute.cs to the project (as the Single File Generator sample does) doesn't seem to work (and I don't understand why the sample seems to expect it to work; .NET doesn't use structural typing, after all, so how could this attribute possibly have any effect?)
If a VSIX cannot add registry settings directly, I think a reasonable substitute is to include some code that automatically runs on VS startup. That code could find out the path of the registry hive of the running VS version and add the necessary registry settings at that time. So I have three questions:
How can I cause a method written by me, inside my extension, to run when VS starts?
How can I get the path of the current VS registry hive?
Is there any other way to add the registry information?
Eventually I gave up on making a VSIX to hold my single-file generator. I made a CodeProject article about what I did instead.
But back when I was still trying to make a VSIX file, this blog post came in handy.
What is wrong with MSI-deployment? You can do anything from there. WiX has option to install VSIX packages pretty simply, just use the embedded element <VSIXPackage>. It also offers you to create new registry keys + you get registry key unistall for free. Note that you can elevate privileges, if needed.
does your vsix have a class that extends Package?
Add code in your Package's Initialize method that runs when your package is initialized.
To get to VS based registry stuff, see Microsoft.VisualStudio.Shell.VSRegistry