What's diff in term of functionality are there between addins and Visual Studio Packages ?
This article is a good place to start: http://msdn.microsoft.com/en-us/library/bb330853.aspx
VSPackages are the 'first class citizens' in the IDE. Much of the core IDE functionality is actually supplied via packages. This is how Microsoft itself adds functionality to Visual Studio (i.e. new tools, languages, etc...).
Addins are limited in what they can do. Generally, they are restricted to using only the DTE automation object model to accomplish their tasks. The advantage is that it's usually simpler to do what you need this way, and the templates are included "in the box".
In general, we recommend that folks extend the IDE via VSPackages for new projects. You'll need to download the Visual Studio SDK to get started.
Related
We are using a commercial software that has its own scripting language with which you can customize the product. It is very tedious to write code in it without any help from an IDE and it has its own compiler.
Is it possible to use Visual Studio and create an environment for me to write scripts in this language and get the help of intellisense and syntax highlightning and other good things you find in an IDE? Ideally I would like to bind a button in VS to launch the external compiler and compile the code so I don't have to switch windows all the time as well.
If this is possible is it a very hard thing to accomplish?
Yes, this is certainly possible. You need to create a Visual Studio Shell add-in with custom language services and text editors. You need to install the appropriate Visual Studio SDK and then you'd continue to:
Create a custom Editor and/or designer
Add a language service
Add Project and Item templates
You're allowed to ship Visual Studio Isolated Shell with your application (license required and there are some limitations) so that your users don't need to have Visual Studio Professional installed.
There are a number of open-source projects that provide a custom editor, language services etc in Visual Studio, these could provide a nice place to research how things are done, next to teh Visual Studio SDK documentation:
PyTools, which is a Visual Studio editor for IronPython
Phalanger, which contains a Visual Studio editor for PHP
PoShTools, a Visual Studio service for PowerShell editing right inside Visual Studio
You'll probably want to dig into MsBuild as well, since Visual Studio will expect you to create a project file if you want to edit a collection of files and compile them. MsBuild could in turn call your own compiler, like it calls csc to compile C# code for example.
Creating Project Types
I've been given the task of developing some extensions for Visual Studio for our internal use. These will have to support a couple of different versions of Visual Studio (VS2008, 2010 and 2012 - VS2005 would be a nice to have but not essential). I'd like to develop these in as consistent a way as possible, reusing as much of the code as possible, while fitting it into the existing project structure for these kinds of tools, which is a Visual Studio 2012 .sln.
What's the best / easiest way of developing this kind of extension? A VSPackage project? Can I make a 2008-compatible VSPackage which is developed in VS2012?
The features I will need for the extensions I'm writing at the moment are pretty basic - I need to create Tools menu commands, possibly a custom toolwindow. My requirements might change later on but I don't need editor adornments or anything like that at the moment.
I saw this question which might seem to be a duplicate, but the answer which was accepted doesn't answer the question, so...
It really depends on what is your extension going to do.
VS2008 does not support extensions (.vsix) and you will need to write VSPackage deployed as msi for it. You also won't have access to many new features introduced in VS2010 (easier editor integration and access to vs services via MEF), but basic stuff such as manipulating solution/project/files should be fine and work on all versions (e.g. using DTE should be ok).
As far as I remember for VS2008 you will also need to obtain a PLK, which is no longer required for 2010 and 2012.
I haven't tried developing 2008 package in VS2012, but you definitely can develop 2010 extension in 2012.
Also remember that VS2008 is .Net 3.5, so your code should use .net 3.5 and version of c# which it supports to be portable.
We need to enhance the installer for our WindowsForms.NET grid component: we should have the ability to add it to the Toolbox in a VS 2010/2012 Express edition (VB, C#, ...) while installing the product. We can do that for all non-Express editions using the well-known EnvDTE.DTE object, but this does not work for Express.
Is there an approach to achieve the goal? Say, change some system files (system for VS)? I.e., maybe, VS stores the toolbox item list somewhere in a file so we can access it and change accordingly? And maybe, this way can be used for all non-Express editions too?
Yes, there is a multitude of approaches:
manual installation
Toolbox Controls Installer (TCI)
Visual Studio Automation Object Model (DTE)
VSI, VSIX packages
VSPackage
I wrote a tutorial article discussing them in more detail:
Visual Studio Toolbox Control Integration
I think the TCI approach would work with the Express edition of Visual Studio. Also the VSI and VSIX packages are quite convenient way to make sure the components get installed.
This is easily one of the most annoying "features" of Visual Studio in its history and I don't understand why it exists -- ever.
Why would a CodePlex project need to care what version of Visual Studio I am using?
Off the top of my head, the only thing I can think of is that some versions of Visual Studio might introspect assemblies searching for attributes to determine what to display in "Visual Designers" and "Property Editors". But why would that cause Visual Studio to not be able to open the project and allow me to browse its contents and compile?
It seems to me like Open Source in .NET is somewhat limited by the stupid dependency management exhibited by Visual Studio. In other words, if I am using Visual Studio 2008 and you are using Visual Studio 2010, then we have different solution files.
http://blogs.msdn.com/b/visualstudio/archive/2010/03/15/why-does-visual-studio-2010-convert-my-projects.aspx
Here's an example from the site as to why Visual Studio converts your projects to 2010 format.
For instance, Visual Studio runs
custom tools such as single file
generators for designers in order to
output code representing the changes
made to the designer. Many of these
custom tools are upgraded or
completely replaced in the newer IDE.
During conversion, the IDE knows which
custom tools to replace or upgrade. In
order to make round-tripping work, VS
would need old and new custom tools to
understand each other so as to ensure
that old and new designers can work
side by side. Other than designers,
the following files would also be
affected: resource editors, wizards,
code snippets, item and project
templates, diagramming and modeling
tools, and many more.tools, and many more.
Since 2010 knows about what tools 2008 has, it can convert forward to be compatible with the custom tools 2010 uses. 2008 has no idea about what 2010 is using, how could it? Therefore, it is impossible to convert backwards since it doesn't know what it needs to convert, nor how to.
I believe the purpose of this touches on what you stated in your comments. If you are using 2008 and I 2010 and I compile it, how could you possibly run it again? 2010 is backwards compatible but 2008 has no way to make itself forward compatible.
Thus, by recompiling the project in 2010 I ensure that no 2008 user may mistakenly think they can compile it.
When creating a new extension for visual studio, there are two project options: "Visual Studio Integration Package" and "Visual Studio Add-in". What is the difference between the two project types and when would you use one over the other?
Ok, you can find a full detailed comparison here (there are also links to the previous parts in the series).
But basically, add-ins were available as the VS extension type from the very first versions of the VS and built as the COM components. Later on, some limitations were discovered in that approach, so the new extensibility feature was created -- namely VS SDK package.
Probably, if you are building an extension for VS 2008+ you should target the VS SDK package as the newer technology. Another strong point of the VS package is better integration with the Visual Studio.
Whatever you do, add-ins are an
external thing for Visual Studio while
VSPackages are a completely integrated
part of the IDE.
You still might consider building an add-in, if
you need access to high-level extensibility API, as opposed to low-level fundamental API available from a VS package;
you develop in Visual Basic (templates for VS Package are available only in C# / Visual C++);
you want to automate a simple task / common scenario, then add-in will probably require less development effort.
Important point on Visual Studio Add-in vs Package, Add-ins are deprecated in VS 2013 and will not be available in VS "14"
Add-ins Deprecated in Visual Studio 2013
Visual Studio "14" CTP: add-ins are gone
"Official" guidance from How to: Create an Add-In is "Visual Studio add-ins are deprecated in Visual Studio 2013. You should upgrade your add-ins to VSPackage extensions...."
An integration package is something that can be chosen when you start a new project (like how you pick C# or VB).
See http://www.bitwisemag.com/copy/features/dev/visual_studio/vs2005_integration_1.html.
Add-ins work just like they would for MS Office applications. You can add your own custom buttons and menu items. Here is an example: http://www.c-sharpcorner.com/UploadFile/mgold/AddIns11292005015631AM/AddIns.aspx.