My company recently created a Visual Studio 2010 add-in that allows us to create LINT files from any given visual studio project from 2010, 2008 and 2005. We now want to get this same add-in to work in Visual Studio 2012, because we know that many of our customers will be using this in the near future, if not already.
We thought that it should be a simple "switch-in", and that the same code should work for both, but lo and behold, the VS10 add-in didn't work in VS12. So I copied the code (absolutely no changes) into a VS12 add-in, and surprise surpise, it did work. Naturally, we do not want to have two versions of the same code; bad for readability, bad for maintainability, so we still want to find a way to get the VS10 add-in to work in VS12.
I think the problem lies in the Microsoft.VisualStudio.VCProjectEngine assembly. This is interpreted differently in VS12 to how it was in VS10, meaning that when VS12 reads the add-in, it doesn't do what we want it to do.
I have done some research into this problem, and many people suggest creating a work around by using reflection, but I am reasonably new to this concept and don't feel confident enough to try it and risk seriously ruining the add-in.
So my question is this: Is there a nice and easy way of being able to read the VS10 version of the Microsoft.VisualStudio.VCProjectEngine into VS12?
Much appreciated :)
I later found an answer to this question and realised it hadn't been confirmed on the thread.
The answer indeed lies in the VCProjectEngine assembly. For some reason, this is a different module in Visual Studio 2010 to the module (with the same name) in Visual Studio 2012, which means any code requiring the module when written in VS2012 will not work in VS2010 and visa-versa.
It's a pain, because it means we have two lots of exactly the same code, but that is the way it has to be.
Related
I saw a lot of good comments about ReSharper. So I gave it a try and I really like it. I even suggested to my team to use it and to put some money in this tool. But they sad "We better put the money in updating Visual Studio because newer versions come with almost all ReSharper features" as we are using Visual Studio 2010.
Is ReSharper useless in Visual Studio 2015 or 2017?
This might not be an answer, just my own opinion.
VS2017 is doing very well without R#. however, some important functions are still not there in VS2017, e.g. renaming namespaces, and here R# role arises.
Some where else, I find R# make the things bad, for example, I don't like how the R# renames the properties, it gives and new popup window, where VS2017 renames it immediately.
So what I mean, sometimes R# might be useful, but if you are not using it, you are absolutely safe and productive.
I am still waiting for any video or article where it is described, what are the flagship killers functions in R# which VS2017 doesn't have (except renaming namespaces ;)).
UPDATE:
What I actually suggest is, install use the refactoring suggestions of R# because they are awesome, but keep the default key mapping of VS2017.**
UPEATE 2:
I have been working for 1 year without resharper, and I am very ok and do not miss any function, except renaming namespaces.
UPDATE 3:
I miss the function of extracting a method to an existing interface in Visual Studio 2017, which already exists in ReSharper.
ReSharper is not useless in newer versions of Visual Studio, but there are a lot of features and shortcuts that come baked right into VS. My opinion would be that if you are new to developing in VS, look into the features it already has and make the best use of them. After all, what good is a Porsche if you cant drive? Here are a couple of links you should check out.
https://msdn.microsoft.com/en-us/library/da5kh0wa.aspx
https://msdn.microsoft.com/en-us/library/ms366750(v=vs.90).aspx
I have a solution with several projects that have Register for COM Interop checked.
I have a Visual Basic 6 project that references the resulting TLBs. One issue with VB6 is when it references a dll/tlb, it puts a lock on that file.
Using Visual Studio 2010, unless I'm doing a rebuild or have made a change to one of these interop projects, I can build/run the solution (with the VB6 project open) without it barking that one or more of the assemblies is locked.
However, using Visual Studio 2012, even on a simple build where nothing has changed, apparently it always does the regasm, which makes it impossible for me to debug my VB6 project.
Is this new feature of Visual Studio of running regasm on build something that I can turn off?
EDIT: Allow me to simplify:
Using Visual Studio 2010, I hit Build-->Build Solution and check the output for one of my assemblies that is marked as Register for COM Interop and the file has not changed.
Using Visual Studio 2012, I do Build-->Build Solution and check the same assembly, it has been updated, and does so every time I hit Build Solution.
I want the behavior in Visual Studio 2012 to work the same as it did in 2010.
EDIT (again):
I posted this to Microsoft Connect. If someone answers it there or posts a workaround, I'll urge them to also post the answer here.
I've always encountered problems like this when running VB6 and VS20XX, but I always did a rebuild. My suggestion is to stop using VB6 for testing purposes. I found it was far easier to simply create a testing project and do all of my testing in .NET on my .NET code. This should only require a small amount of set up, but it is well worth it in my opinion.
I know this isn't an answer to your specific question, but it offers an alternative. As far as the problem you are describing, I can't duplicate a change in behavior. I start off with only VS201X open, full solution rebuild, open VB6 and add a reference to an exposed COM DLL. I didn't notice anything unexpected.
Build works fine as long as I haven't changed anything in the COM DLL
Build fails if I changed the COM DLL's code as the file is locked
Rebuild fails as the file is locked
How do I run Visual Studio 2008 projects in Visual Studio 2005?
Take a look at this article by Jon Skeet about moving solutions and projects between VS2005 and VS2008.
Jon's conclusions:
It's possible to share project files but not solution files between VS2005 and VS2008.
If you upgrade a solution file by mistake, it's very easy to fix it by hand.
If you decide to maintain different solution files, if there are big changes in one it may be easiest to just make them in one solution, then upgrade again.
Creating a project in VS2005 and then importing it into VS2008 is seamless; the other way round has slight issues which are fixable by hand.
I don't know of a way of forcing VS2008 to only use C# 2 while at the same time maintaining VS2005 compatibility.
First off, you picked 2009. A terrible year. 2007 we might have guessed 2008, but 2009 is smack dab in the middle.
I'm not sure what the answer will be, but I'd guess that your best approach is to just add each code file and each reference until the project works.
I don't know what the file formats look like, but there usually isn't going to be support in an older version for a newer version's format.
I'm not sure that VS2005 has forward compatibility... haven't heard of that many apps that do.
I am thinking of creating a product based on the Visual Studio Shell (primarily isolated mode). Since Visual Studio 2010 will most likely be RTM before my product, does it make sense to start with VS2010 as a base rather than VS2008?
Has anyone looked at what they changed in connection to the shell framework and if it is improved enough to warrant using it over the better documented and not-beta 2008?
The editor extensability model is changed radically since it is based off MEF and WPF in 2010. If you extend the editor on 2008, it is likely you will have to make quite a few changes to get stuff working in 2010.
However, a large amount of the extensability still depends on the old VSIP/COM which remain unchanged.
If you plan on shipping with the 2010 time frame I think skipping 2008 is not a bad idea.
Speaking as one who is working on a product based on VS2008 shell I would strongly suggest to use VS2010 instead as base. They have cleaned up their interface and probably fixed a lot of the bugs that are in the VS2008 shell. I think they would also be more sensitive to bugs than when they happen in the "old" VSShell.
This is really not a technical question, in my mind - you need to think about your customers before yourself - is there a large enough crowd of people who use vs08?
(I encountered a similar question and concluded that for my scenario - I need to support VS08)
I am having trouble with my Visual Studio 2005 IntelliSense for some time now.
It used to work fine, but for some reason the 'Updating IntelliSense...' does no longer seem to be able to complete for the solution I'm working on currenly- it simply gets stuck somewhere at about 3-bars of progress and blocks one of my precious CPUs for eternity.
Deleting the .ncb file of my solution and performing a full 'Clean' afterwards was no help.
The 'Update' simply gets stuck again.
The project I'm working on is a fairly large C++ solution with 50+ projects, quite a few template classes (even more lately) and in general quite complex. I have no idea which impact this might have on the IntelliSense.
Visual Studio 2005 Service Pack 1 and all hotfixes which rely on it are not
installed (we hade huge problems with this one, so we haven't migrated yet).
Any answer is very much appreciated on this one. Gives me the creeps..
Cheers,
\Bjoern
Rename "C:\Program Files\Microsoft Visual Studio 8\VC\vcpackages\feacp.dll" to something else (like "feacp.bak") to disable Intellisense.
I recommend getting Visual Assist X to make up for it (it also has a number of other useful features as well).
I have found that the best fix for Intellisense in VS2005 is to install SP1, and then this hotfix: 947315. It has the added benefit of fixing most of the multi-core build issues.
This hotfix also includes the ability to control Intellisense via Macros. More information here.
As for making SP1 more friendly for existing code, you might also check out this hotfix for template compilation: http://support.microsoft.com/kb/930198
Intellsense is problematic. Very problematic. When it works, it's great, but more often than not it will cause more problems than it's worth. It will hang up, it will parse through files while you are trying to compile code and will generally make VC 2005 sometimes run like a dog. As a previous poster suggested, disable intellisense (and chose a potential alternative -- I also support VAX).
Supposedly the hotfix and SP1 provided by MS will fix some intellisense problems, but not all. We have seen minimal help from these where I work. You are better off to disable it and rely on something else.
My feeling is that the slowness comes from the size of the projects. Yours seems like it might fall into that case.
Here is the only solution that works for me.