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 am currently doing research to complete my org's migration to VS 2015, including implementing StyleCop.Analyzers, getting ReSharper settings updated and checked into source control, etc.
One topic I keep coming across is "compatibility" between StyleCop and ReSharper. A Jet Brains dev has even forked classic StyleCop in order to make it "compatible" with ReSharper 9.
What does "compatible" mean here? Is it as simple as making all of ReSharper's default code analysis settings match those in StyleCop, or something more involved?
Our upgrades/changes include:
Visual Studio 2010 to 2015
ReSharper 8 to 10
StyleCop classic to StyleCop.Analyzers
... so I just want to make sure I have my bases covered.
Is it as simple as making all of ReSharper's default code analysis
settings match those in StyleCop, or something more involved?
Yes, pretty much. It's all about keeping the rules in sync so that one doesn't flag an error the other is ignoring.
One thing to watch for on this migration is the version of the R# plugin. I haven't had much joy with ReSharper.StyleCop, but
StyleCop by JetBrains 4.8 works fine, plus it is designed to "play nice" with
StyleCop.Analyzers.
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).
Is it safe to use the beta versions of Visual Studio?
By safe I mean, while developing any project in this studio, is it probable that it may cause some losses to my project? Or any other kind of risk?
Should I just use the studio 2008 and
wait for the stable version of Studio
2010?
Purpose of the question: I am doing my graduation project in .NET framework (includes - C#, WPF etc.).So I don't want to put my project at any risk because of some issue regarding (beta) visual studio.Hence the question.
As long as you are using a version control system, there should be no problem. Simply check out your project (or better yet, create a vs2010 branch) to an experimental folder and work from there.
There are no hidden risks when you use version control appropriately.
Visual Studio 2010 will convert your project files to its new format, meaning you'll have trouble if you want to go back to VS2008 later. I'd suggest holding off for now unless you can find a way to keep both old and new versions of the project files up to date.
There's always a risk in using beta software (but then again, there's always a risk in using any software). The whole reason it's called beta is because the company is not confident that it's got all the bugs worked out. Otherwise, it would have been released so they could start raking in the moola.
There are quite a few ways to mitigate the possibility of any beta software (not limited to VS2010 or even any programming-related product) from causing you trouble. Choose any from this list, which is by no means exhaustive:
Don't use it on the same data (be it accounting information or source code) until you've run it in parallel and gotten the same results as with the older version.
Plan a backout strategy if the software is so bad that it's easier to go back than to try and go forward.
Backup your data even more frequently during the periods where you're using the beta software, up until the point that you're comfortable with it and can revert to a more normal backup strategy.
Don't use beta software at all - wait for the real release (or SP1 if you want to be even safer). There may not be a driving force behind updating to the latest version.
As a company, limit your exposure to the beta software to a small set of your employees. So, for example, if you have six different teams, choose the least important as a sacrificial lamb, so to speak.
My own personal preference is to wait until everyone else has sorted out the problems first. I didn't upgrade to the latest Ubuntu while it was in beta (I still got burnt a little bit with the video and X but that particular problem already had a solution on the net). I don't download the latest and greatest Eclipse until it's been in use for a few months. I'm still using VS2008 under Windows XP since there's nothing I think I need in the latest release (of VS or Windows).
We obviously have the latest and greatest OS' in our test environments but they're crash-and-burn environments that won't cause any real pain if they blow up (other than a rebuild but even that's pretty painless nowadays).
For your particular circumstance, I would probably stick with a tried and true version. You don't seem to have a pressing need for any of the new features in your question and the sort of failure you're talking about is not just losing some information at work which, while annoying, is probably backed up to the point where your career would survive.
A similar loss of your educational work would affect you for a long time if you fail your subject because of it. I would probably just concentrate on getting it finished rather than worrying about what VS2010 beta might do to my work. Don't misunderstand me, you should still be protecting your work even with VS2008 but I'd personally feel safer with that option.
Then, if you have some spare time at the end of your project (hah! as if that would happen!), you could try to convert what you've done so far to VS2010. If it all goes pear-shaped, you still have all the VS2008 stuff available.
There is certainly risk in using unproven software in that it could behave unexpectedly. Some of the answers here focus on protecting your source code and that is a valid concern, but you should also consider other risks.
Could Visual Studio 2010 make your system unstable? Having your source code in a local instance of source control won't do you much good if Visual Studio corrupts your hard drive. Even if you backed up regularly, you'd still be out a good day or two (MINIMUM) rebuilding your desktop.
Also, what do you intend to do with the finished product? Will a professor attempt to open the project on their own desktop? Are you expected to deploy it to another environment? We see these "Works on my computer" problems using proven software, a beta certainly increases the probability of running into this type of problem.
So yes, there is certainly increased risk in using a beta. You can take steps to mitigate the risks but with important work those are steps you should be taking anyway. Is the benefit of using Visual Studio 2010 worth the increased probability of delays / data loss / grade impact?
I know I'm experimenting with VS2010 and I haven't seen severe problems but betas are not proven/guaranteed - the overall risk is probably slight but it is a risk nonetheless.
I guess I would approach the question differently...Is there any real value in using VS 2010 over 2008? I have been using both for a while and I would say, No.
I have had some mysterious crashes with VS 2010 and the application has disappeared on me, causing me to lose any unsaved data.
If you are integrating IronPython / Ruby or working with Office or VB style COM, there is more support for this in .NET 4.0. Beyond that, most of the changes add some shine to the IDE, but not much real value.
my 2 cents.
The biggest risks you will face are crashes, random tool window misplacements, and occasionally Visual Studio will refuse to start and you will have to reset all your settings to have it working again. 1 (I am anyway reasonably happy with Visual Studio 2010 and don't regret having installed it; in my case the compelling reasons were unit testing and visual designer for Silverlight)
But as ocdecio says, there should not be danger for your code, especially if you use a source control system.
As an additional advise, target your projects to .NET Framework 3.5. Using a beta development tool may be ok, using a beta .NET Framework in a production environment is usually not.
1 This crash is supposed to be caused by using raster fonts for the code editor, but it has happened to me without using this type of fonts.
Given that you've said the project will be "tested on another system", the answer is simple: use VS2008. VS2010 solutions cannot be opened by earlier versions, and I wouldn't bet my graduation project on whether or not someone else has VS2010 installed.
Other reasons to stick with VS2008:
VS2010 probably doesn't gain you much.
There are bugs, and I'd rather be working on getting my graduation project done rather than working around problems with my development tool.
If you need help along the way, those that can potentially help probably aren't using the same version. That may make a difference, it may not.
Another thing to consider.. usually the EULA prohibits you from deploying and/or shipping a product using a Beta version of the toolset. I'm not sure this applies in your situation but it's a point to consider.
Another potential issue I've heard of is that sometimes Visual Studio betas refuse to uninstall when it comes time to put in the RTM version. So as long as you don't mind reinstalling Windows when you're ready to install RTM and you've taken the other answers into consideration, then go ahead.
Since your project is for a graduation project and not for full production release, I would say use the latest/stable version of Visual Studio 2010.
You will gain more than you will lose as you will be using the latest technology which will be more useful going forward.
There is an issue for touch screen machines which may render WPF applications unusable.
A workaround exists. See details:
‘MS.Win32.Penimc.UnsafeNativeMethods’ Threw An Exception
fix: C:\Windows\Microsoft.NET\Framework\v3.0\WPF>regsvr32 PenIMC.dll
The biggest problem I have with VS2010 Beta 2 is designer. The Windows Form Designer generates buggy code (Microsoft Connect bug id 507267 and 499925). So I have to edit the form in older version of Visual Studio
I have a few other problems not related to code lose, like random crashing and wizard disappearing.
I've just spent two weeks in VS 2010 beta 2 doing some serious prototyping work. It all went pretty smoothly, and I really like VS 2010. At the end, I moved all the code back to VS 2005 and integrated it with my current project. My experience:
Moving the code back to 2005 was pretty easy. I did try not to use any C# features from 2008 or 2010. The only thing I missed was C#'s implicit properties, but those are easily fixed.
Yes, the project and solution files are not backward compatible. To migrate back, I just created new projects in 2005, and pasted the source files in through Visual Studio. Worked like a charm.
I did find one thing that would consistently crash 2010. If you use the splitter to view two different sections of a file at once, and cut-and-paste from one pane to the other, VS 2010 will roll over and die pretty quickly (not necessarily at the time of the cut-and-paste, but very soon afterwards).
There are some nice productivity features in 2010. You can drag a tab out and make it a window. In Windows 7, you can drag it to the top of the screen to maximize, or to the side to use have the screen. Dragging one file to one side of the screen, and another file to the other side, means you get the whole screen to edit two files, side by side. Very nice. (Even better on two monitors, but I was on a laptop.) The "Quick Find" dialog can now be docked -- that's a huge improvement.
As others have mentioned, use source control, but VS 2010 really is not unstable enough to be any more of an issue than VS 2008. Note that Team Foundation Server 2010 is also available in beta, and will be part of all MSDN subscriptions. It installs under Win7 and Vista. I'm using it for source control on my laptop! Team Explorer is integrated into VS 2010.
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.