I am working on a C# windows based project in visual studio 2005.I often debug different features in this huge project.Now the problem is i have made few break points in few places which i require only when i debug for that feature.i want other break points to be disabled then.I understand this might not be a use case for larger community.
What i want to know is,is there any way to group break points in VS 2005 ,so that i can enable disable them when i debug that particular feature?
There's not a feature built into Visual Studio, however something I came across a while back is a clever use of macros to give some grouping functionality.
Check out this blog entry by Jim Gries showing how to do it.
Just a note, I now it doesn't help your current situation, but the situation has been improved in VS 2010.
you can check this reference:
a VS 2010 Debugger Improvements (BreakPoints, DataTips, Import/Export)
This solution works only in Visual Studio 2010 and above
Related
I've recently started using Visual Studio quite heavily since starting to develop in .Net
I really like the intellisense as it increases my productivity by allowing me to code faster. Previously when authoring CSS I would just use Notepad ++ and I got very used to some of the little features that this awesome text editor possessed however, now that I am doing the bulk of my work in Visual Studio 2013 I want to try and avoid having too many environments open at once. With this in mind, there is one feature inparticular that I would like to try and replicate in Visual Studio when editing CSS or indeed any other type of code.
In Notepad ++ it automatically includes a sort of guideline which runs down the page between the opening and closing tags of elements as shown below:
My question is, how do I replicate this behaviour in Visual Studio 2013 as the currently setup I have at the moment isn't as clear/productive as you can see below:
Any help would be greatly appreciated.
There are a couple of free extensions you can use to do this. These will run on any of the Visual Studio versions except Express, which does not support extensions.
You can duplicate this with the Indent Guides extension.
You can also use the Structure Visualizer Feature of the Productivity Power Tools.
Note: The backgrounds in the example are different because they are taken on different machines with different themes.
I'm currently writing a tool to help maintain unit and integration tests (coded tests). I've started extending Visual Studio to make the developer experience nicer, which got me to notice the new-ish CodeLens feature.
The stuff I'm currently showing as a tooltip should probably actually be part of the CodeLens info.
Question: Does anyone know how to extend CodeLens in Visual Studio?
Thanks.
As #RichardBanks says, officially CodeLens is not extensible. Technically I think it may be possible at the moment. Look for *CodeSense*.dll in the visual studio directory for hints. There is no documentation at present and the API can still change going forward.
I suggest you'd venture into this for research purpose only, distributing any 'plugin' seems like a very bad idea until Microsoft opens up the API, which they probably will.
CodeLens is officially extensible since Visual Studio 2019 was released.
CodeLens for Everyone
CodeLens has been a feature found only in Visual Studio Enterprise, but that will change in an upcoming preview of Visual Studio 2019, when it will also be available for the Community edition, likely in 2019. CodeLens shows the number of references a type or method has, information about unit tests covering the method, and data directly from Application Insights.
In addition, Microsoft has made CodeLens fully extensible1, so third-party extensions can start to add their own experiences on top of it. CodeLens makes key information about your types easy to find, while keeping you in the source code. Lenses for source control history and IntelliTrace are still an Enterprise-only feature.
Looks like this is the best place to start looking at when implementing your own CodeLens extension.
1. Highlight mine.
Code Lens is not currently extensible.
I can't say for sure, but I think there are still some features the team wants to add before they open it up for extension (e.g. git support).
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.
We're using Visual Studio 2010 (Premium edition if it matters), and pretty happy with it. However, We're never going to use the TFS features that's included in the IDE. (We're using Jira and Subversion, as it's not just Visual Studio that we work with, but also IntelliJ and a couple other IDE's.)
Is there any way to disable the TFS portions of the IDE? It's not a big deal or anything, just for the sake of "keeping things neat."
In Visual Studio 2010, go to Tools->Options In the list, select Source Control. Set your Current source control plug-in: to None
The main "TFS" parts of the IDE are in Team Explorer - Just don't install it.
Anything else you don't want/use, I'd advise you to simply ignore - VS has support for hundreds or even thousands of different things that you will probably never use, and you can't easily "clean" them all away.
In my experience the more you alter your installation of Visual Studio the more problems you will have with it. Every custom Option you set is another thing you have to repeatedly set every time you get a new PC or install a new VS. (Although it has improved a lot since import/export options became available and reliable). I used to spend about half a day setting up a visual studio to "work well", and now I just install it and use it. Ultimately I found that it was easier to just adjust my working practices (e.g. by relearning a few keyboard shortcuts etc) than to try to bend VS to my will.
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)