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.
Related
I'm porting all my development to Visual Studio 2017. I made heavy use of Portable Libraries in 2015, but it appears that .NET Standard is the way to handle cross-environment issues going forward. I've got a single file code generation extension that I've upgraded. In Visual Studio 2017, it works great against the traditional .NET libraries and portable libraries, but it doesn't work with the new .NET Standard library I'm trying to build. I'm happy to consider that I've done something wrong, but the GITHUB example doesn't work either:
https://github.com/Microsoft/VSSDK-Extensibility-Samples/tree/master/Single_File_Generator
Anyone know why Visual Studio extensions (at least code generation extensions) don't work on this project type?
I have Visual Studio 2010 Professional installed. But for a client I do need Visual Studio 2008 (to avoid some upgrades that are note compatible with vs2010)
It is my job's notebook, so everything must be original and legal. And both, the client and my boss want to avoid licences costs. ANYWAY... it seems that my notebook already has some version of vs2008, I need to know if it is too muche reduced or if it will work to develop.
I can open a vs2008 that seems pretty much the same, also the about screen. But at "Add or Remove Programs" I just only have "Visual Studio Tools for Applications 2.0"
Finnaly when I run the app, it works, but the code is not recognize, it is shown as it is notepad.
Here are some screenshots that may help... THANKS ALL!!
VSTA is sort of a replacement for VBA, i.e. you can use VS to write .NET code to extend and automate thrid-party applications that are designed to support it. It appears that that is the only VS 2008 component that you have installed so you cannot open VB or C# projects or any of that stuff. If you want a legal copy of VS 2008 that you don't have to pay for then you'll need to look at an Express edition, although that may lack some features that you need. 2008 Express editions are hard to come by now too, as they are not offered for download any more by Microsoft.
What are these non-upgradeable parts of your project?
I am trying to develop custom code for an InfoPath 2013 form. I have Visual Studio 2013 Professional installed, but when trying to edit code I get the following message:
The following external components are required to edit your form code. Please install them and try again.
Microsoft Visual Studio 2012
Visual Studio C# Support
Microsoft Visual Studio Tools for Applications 2012
C# support is installed, along with Visual Studio Tools for Applications 2012.
Does InfoPath 2013 just not support VS2013?
Unfortunately No
MS has really been making some bad decisions lately
Firstly VS2013 was released so they forced people to upgrade if you want to develop for Windows 8.1
Secondly, MS have announced that they are dropping InfoPath and have yet to provide an alternate solution. Support is still available but InfoPath 2013's successor will be another solution.....i'm guessing Azure Forms or SharePoint forms, something like that
Very disappointing
As you have found, adding code to an InfoPath 2013 form requires Visual Studio 2012. I am not aware of a way to use it with any other version of Visual Studio.
Depending on what you plan to use the custom code for, you may be able to get by with the qRules library (full disclosure: I am one of the developers of this library). It contains many of the most common features for which people tend to use code within InfoPath, and you can use them simply by executing rules within your form, eliminating the need for any version of Visual Studio.
If there is a specific thing you are looking to do with code, I can tell you whether it's possible to do so with qRules, but you should open a separate question for that (and let me know here).
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.
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.