Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
Just before you sigh and mark this question as a duplicate, I can tell you, it is not.
I've seen a lot of questions about replacing Resharper with something else, but most of them are out of date. I'd like to get this question raised again with a view to current situation in the world of VS extensions.
I have been using R# for the last 2 years and have paid out of my pocket for V7 and for upgrade to V8. But more and more I use it, I feel it is a drag! Drag on CPU resources and drag trying to fight the bloody thing. Visual Studio is horribly slow with it enabled. One of the projects I work on has 230K lines of code and R# is very slow there!
I wish Resharper was modular and I could turn off most of it's features.
I have tried Productivity Power Tools and they add a lot of value, but don't have critical functionality I'm after
Anyway, my question is: what extensions can do the following:
Nice test runner. Where you can right click on the test and say Run. Native VS test runner is horrible.
Refactorings. Some refactorings are presented in VS natively which is nice, but anything past extracting a variable is non-existing. Renaming is very nice in R#, but I've never seen this implemented anywhere else.
I know this question is a bit off-topic - asking to recommend a product. But people did ask similar questions here, hence I decided to ask as well.
2nd July 2018 Edit 4 years after and I still get upvotes on this question, so I guess it is a time for an update. I'm on Visual Studio 2017 (currently 15.7.4) and don't have Resharper installed on any of my machines. And it is working just fine. Built-in functionality is mostly doing what is needed, even built-in Test Runner is fine.
There was a period of withdrawal when I was missing R#, but after almost 2 years without R#, I can say - native VS is good (and fast) enough to work on web projects. Yes, some R# features are still missing, but not enough to grant R# behemoth to weight me down.
This is one of those subjective questions that are typically closed quickly on StackOverflow, because there isn't just one answer. Here is mine, and I will provide the typical disclaimer: I am very biased towards ReSharper. I'm a huge ReSharper fan, have been using it since v2.5, I build plugins for ReSharper, and I keep very close tabs on what's happening at JetBrains, because I really love that company!
I will admit: ReSharper performance is something that comes up with every single version, year in, year out. No matter how much work the ReSharper team does to improve performance with every new version, this is true - once ReSharper is installed in Visual Studio, a noticeable performance hit is felt - Visual Studio takes a bit longer to start, at some (rare) cases, typing might be slower, and if you have huge code files (few thousand lines long), ReSharper will choke trying to open them.
Having said all that - for the additional value I get from ReSharper, I will take its performance overhead any day! There are just not enough words for me to describe the benefits of being so familiar with the tool, that you feel like an absolute caveman without it. My dayjob is developing a Visual Studio debugging extension, and whenever I install a clean Visual Studio in a Virtual Machine for testing, I am in physical pain, because vanilla VS lack so many features that seem just obvious (few examples: extract (introduce) variables/fields, inline methods, rename everywhere (as you've mentioned), not to mention navigation to all errors in the solution without having to recompile, and many more).
I mentioned that I am biased, but I will try answering your actual question. You have probably heard of Roslyn. If not, Roslyn is the name of the next-gen .NET compiler platform that Microsoft has been working on for the past several years. This new platform provides APIs that will allow Visual Studio extension authors to build diagnostics and refactorings/code-fixes that are very similar to ReSharper. So similar, in fact, that Microsoft just took ReSharper's light-bulb and put it in Visual Studio!
The next version of Visual Studio (currently called Visual Studio "14", which is in preview stage) is entirely powered by Roslyn, and comes out of the box with some "ReSharper-like" features, such as the powerful rename (screenshot below), and other diagnostics. The SDK comes with samples, allowing you to build your own diagnostics and refactorings, using a rich, modern API. Microsoft did a good job in making all those things accessible to "normal" developers, so you don't have to be a compiler expert to build those things yourself.
I will say this: compilers are HARD. No matter how good the API or the platform, the amount of work required to cover all the corner cases is insane. It took almost 10 years for ReSharper to get where they are today, feature-wise. It will be at least a few more good years until Visual Studio catches up to (most of) them. There are already free extensions that build on top of Roslyn, which introduce some new diagnostics and refactorings.
In conclusion, I believe Roslyn will provide a sufficient alternative to ReSharper in the not-so-near future. Many free extensions will be built, and you'll be able to install just the ones you want. One caveat about free extensions, just as you yourself mentioned in the question - they tend to become obsolete and disappear. There will be no-one to complain to about their own bugs and performance issues.
Edit Same is true, by the way, for any other commercial "ReSharper alternative", that's why I didn't even bother mentioning other tools. The all have both pros and cons. It's up to you to decided what is sufficient.
Hope this helps!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Are there still enough VB6 shops to make learning the language worthwhile?
I work for a fortune 25 company and we have a few legacy apps there were written in VB6. However all new development (in the Windows world) is strictly .NET. I would suggest learning VB.NET if you're interested in learning VB.
Computing languages don't die easily, and there are always niche markets where those skills are needed. Languages like Smalltalk, Lisp, COBOL, etc. have there loyal followers and clients that need those abilities. There will probably be some need for VB6 for a while yet.
The chief difference between VB6 and the other languages I mentioned is that the newer version of VB (VB.Net) has been declared by Microsoft to replace VB6. That tells me that VB6 will have a shrinking market as newer versions of Windows makes it near impossible to have VB6 apps that look like current modern applications.
My advice is: if you have a current need for VB6, like maintaining a legacy application, by all means learn it. The more useful you are to a company, the longer they'll keep you. If you don't have a current need for VB6 then learn the newer version of the technology. In the Microsoft world, the .NET CLR based languages are the current vision of the future. You'll also have more success finding help for problems you're facing day to day.
I do not think it is worth to learn VB6.
I work for company where main product is written in VB6 and know one another company where main product is written in VB6 too.
In both cases:
All new products/development is done in .NET (mainly VB.NET to keep syntax similar).
None of developers know VB6 when joined company.
In other words:
VB6 is probably still widely used, but companies migrate to VB.NET. Moreover VB6 is so easy to learn that you can start using it really fast with no previous experience.
I also work an Fortune 25 company with a world-wide presence and many legacy VB6 apps are still widely used through the company. Myself, I am a .NET developer and only learn as much VB6 as I need to fix a production issue or to convert something to .NET (typically C#). So no, don't invest time in learning it unless you must on the job.
I don't use vb too often - I know a lot of larger businesses (Insurance, IT you name it) who do use VB functions so managers can input data into their DB's through some kind of 'Excel' sheet.
Learning any language is worthwhile! VB is easy to understand and M$ has many libraries that are easy to use (i.e. look at connecting to Databases/creating Forms... if you're interested in what real world applications are built on it).
I've used it once for the SOAP api (very easy), and some other applications. I thought it was nice enough.
There are still companies using VB6. Where I'm active for example. But we're migrating to .NET. (the sooner the better in my opinion)
So, as mentioned by aioobe, why would you want to learn VB6? I'd say it's a waste of time and I would spend my time in, for example, VB.NET.
Unless you have a really good argument for VB6 ofcourse.
I wouldnt waste my time learning VB6. I worked with it 10 years ago and I'm still thankful everytime I look at my CV that I had the opportunity to start working in C#.NET. VB6 felt like a mickey mouse language.
You might do a search on indeed.com for "VB6" and draw your own conclusions. I find about 900 jobs there as opposed to 112,000 jobs on a search for ".net".
Google
VB6 - About 5,080,000 Results
Visual Basic 6 - About 33,700,000
Results
VB.NET - About 35,200,000 Results
Visual Basic .NET - About 20,800,000
Results
StackOverFlow
vb6 - 1920
VB6 applications are probably still used quite a lot but I believe for new development over the years VB6 has been chosen less and less as a primary platform to develop an application with people opting for .NET alternatives.
In terms of learning it, I would only do this is you need to work with old VB6 applications that will not be upgraded to .NET, or if you are upgrading VB6 applications to .NET then by all means learn it but dont waste to much time on it.
I would hazard an educated guess, based on my own experience, that there are many more programmers writing new COBOL programs than new VB6 programs. VB6 is ten years replaced and, as far as I can tell, no longer supported in any way by Microsoft.
There are still products around that are written in it (I have two myself) but Microsoft have meant to have said that Windows 8 will not work with VB6 programs, also Visual Studio 6 (required to build VB6 projects) does not easily run on Vista and Win7.
VBA is very similar in syntax and it looks like this will be supported for the next few years at least.
My advice: learn VBA if you need it, but only learn VB6 if you have a maintenance project that requires it. If you really want to learn BASIC then go for VB.NET. It is difficult to suggest other alternatives (there are lots!) unless we know about what you want to learn and why. Eg. If you wanted to learn about OOP then I think C# or Java would be better.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
for my final year project (BSc Software Engineering) I am looking at time entries for software applications, and whether they accurately reflect the development of the project, and whether they can be improved or automated.
For this I will be prototyping a plug-in for Visual Studio using VSPackages that will automatically track which files are being worked on, assigning the files to tasks and projects. The plug-in will also track periods of inactivity within Visual Studio.
This will then be backed up via a simple Web Application for non-technical staff to pull reports from, so that projects can be tracked very accurately.
I currently work in a small company (10 people) and cannot get the large set of data I need to gain a good conclusion from. For this reason I ask if it would be possible to discuss the topic below and if you have a few spare minutes to fill in my questionnaire and email me the result to the address contained within the document:
http://www.mediafire.com/?dmrqmwknmty
Cheers,
MiG
In answer to your question, development time entries are important. But you can't measure them through a single IDE, nor indeed through any software. The development process is a complex one involving discussions, planning around a whiteboard, diagrams sketched on a piece of paper, research on the Internet, etc etc.
Read Jeff Atwood's excellent post on laziness and the other posts he refers to there. A good, successful developer spends time away from the IDE making sure they don't spend 90% of their working day reinventing the wheel, or 50% of their day heading down the wrong track because they haven't thought the design through.
I find the basic idea interesting, even though automated time tracking has flaws, just as measuring the number and frequency of commits to a project (as done on ohloh.net for example) can be a very misleading indicator about its activity.
However, the reality is that time worked is the basis for billing, and needs to be measured somehow. There are already solutions for this, though.
Take a look at
Grindstone or
AllNetic Working Time Tracker
(there are many more out there but these two I know well).
They work independently from what tool(s)/IDEs I am using, they can detect my absence/presence on the computer and prompt me about how I want to file the time, and they can do all the necessary reporting. It is also easy to add and manage filed entries.
What would your Visual Studio Plugin achieve that these solutions don't offer already?
Time spent developing in an IDE provides only a (sometimes very) partial metric of how much time a developer works.
I have been using FogBugz version 7 lately at work, and it has a feature that allows developers to estimate how long it will take them to finish a case. The developer can then use the software to say, "I am working on this case". Then the clock will count down until it reaches zero, based on the developer's working schedule (including days off), the hours that they say they are in the office, and the percentage of their time that they estimate they are working on cases.
But as a developer, I know that I can easily get sidetracked by more important cases. I also know that I spend a good deal of time working on the cases using tools other than the IDE - such as testing in MbUnit, looking for error message explanations online, or giving status to people who ask me why I have not finished working on a bug yet. And I've also been in places where I spent half the typical day - or more - in meetings or in a lab doing my work on a remote machine somewhere else. When I'm at my desk, I could be using my computer to map out ideas for the work I'm doing, or just pen and paper.
So there are a lot of variables to consider when you ask the question, "Is the guy who sits over there really doing his work?" You would really need to look at more running applications than just Visual Studio 2008 (devenv.exe). You would probably need to look at activity for processes associated with a developer's test framework, text documents, remote desktop connections to other machines, and even Firefox. (Firefox would be a huge judgment call as to whether somebody is actually working!)
As part of your research for the project, I would also suggest researching some of the other time collection systems that are in use throughout your company's industry and comparing their features.
A bit off track, but you could potentially use this sort of data to illuminate areas of complexity (LOC), areas that are prone to change (frequent updates 'n' days apart), etc. but even this would be skewed by different programmers approaches to development.
We track all our time by project daily. It takes me less than five minutes a day to fill out what I was working on. This is not something that can be automated or even should be automated as it will never be anywhere close to accurate. Files aren't always associated with just one project and it would cost me more time to tell an application which files belong to which project that the five minutes it takes to fill our my timesheet. No one spends the entire day typing - there are meetings and phone calls and thinking (you know where you figure out what you want to type!), none of that will be captured in your automated system. What you are porposing will not be more accurate, it will be less accurate than requiring people fill in time sheets daily.
While time entries are important, figuring out how to organize it is where trouble comes into the picture. How well would non-technical staff understand the various phases of development in order to understand the data? I'll agree with the other responses that the IDE tracking is a terrible idea, especially if part of what is being done involves changing a database through a web browser which is what I have in my current big CMS project where we may have to change templates or create content to test out if the functionality works.
This also heavily ignores the gaming the system idea that can happen. What if I leave my IDE open in debug because I'm wanting to scan memory or do something else that requires the window be open to actually look at something but I could also have left my desk unless you are somehow tracking where I'm looking and sitting.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 14 years ago.
Improve this question
What technologies/languages/applications do you think have hit their peak on Windows platforms, those that are or should be slated for obsolescence? My votes, might be wishful thinking in some regards:
VBScript
Microsoft Access
ODBC
Flash
I ask because we are in the process of setting future directions for technologies and application development, i.e. don't use these unless there is no choice.
I think Windows has peaked in general. The latest version of Windows, Vista was viewed negatively across the USA, there are numerous examples of major organizations in Europe and Africa phasing out their use of MS Windows in favor of Linux, and all of this has come to great benefit of the Linux vigilante's. The worst part is that Microsoft employees some of the smartest people in the computer industry but are usually screwed over by Marketing people.
I expect I'm going to get hard in down rank points for this answer, but I figure its worth it. As a senior/lead developer I wish I could use a couple Microsoft technologies but I'm afraid of pulling my company under the Microsoft tax of existence, so that biases me to toward a company that had a big role in getting me into programming ( Apple Basic, then MS Basic, and then c++ with the win32 API in the late 90's ) which is disappointing.
I think that MS Access is not a dead technology/product. However the legacy 'Jet Database Engine' that is often associated with Access is definitely in obsolescence mode. I dont; think MS has released a 64-bit Jet Engine (I know they intended not to, but wouldn't be surprised if demand made them change their minds). Also the Jet Engine is no longer part of MDAC.
MS wants the future of Access database engines to be an SQL Express/SQL Compact/MSDE type of engine.
I really don't think Flash is doomed .. I'd bet on its future over Silverlight's right now
Not sure why Access is in your list. Still used heavily and a good choice for small scale DB.
Here is what I think MS wants to kill... whether it happens or not is a different story.
WinForms
VB6
C++ (for desktop apps)
IMHO Classic ASP (as opposed to ASP.Net) and Visual Basic (again, as opposed to Visual Basic.Net)?
In all honestly, I really think that anything which has the ability to make this list won't ever be doomed. It's really really hard to retire a technology. Look at COBOL. Everyone says that COBOL has met it's end of days and has been saying that for years and lo and behold, people still program in it, and there are a multitude of production systems running it.
He's another example, my first job out of college was a heavy Delphi shop. No VB and MS technologies are evil. It was clear that everyone in my area and most people around the U.S. were dropping it in favor of Visual Basic, or something more powerful like C++. I swore up and down Delphi was a dead technology and that Borland was going down the drain. That being said, it's clearly in use today. I was wrong. Popular technologies will never really die, or become obsolete, because of their ability to change and because people depend on system which are currently working (look at FORTRAN, I know of some physicists which still use programs written in it). Once a language/system gains popularity, there will always be a need for someone who knows it, and this means that there will always be a need for someone to improve. There are a lot of technologies that die, but that is because they were never popular enough to begin with.
Of the list that you gave, I would say maybe ODBC could be the one phased out, but with other legacy technologies, I think it is going to be a long time. You could maybe argue VB6 is going to be done away with, but I think it won't be long until someone (not MS) writes a new compiler for it and not necessarily revitalizes it's use, but extends it's life. There's too much written in it for organizations to just throw it away. People argue about things being rewritten, but how often does it successfully happen? The main mentality of people outside of IT is: "don't fix it if it isn't broken." That is going to keep technologies around for a long long time. We can say something is dead, but in reality they all will be around for a long time.
I agree that MS don't support C++ at all well, is this an attempt to create coders who can only write business apps, and therefore don't directly challenge MS themselves?
The other dead in the water is Vista, roll on Windows 7.
By flash do you mean Actionscript or the platform all together?
Flash CS4 has shown some great potential.
Here's a cool feature tour of CS4
What conversion/rewrite have you been involved with that failed? What where the languages and framework involved in the process? How large was the software in question? Finally what is the top one or two thing you learned from being involved with the process.
This is related to this question.
One of my favorites was a fixed price project developing a server app on Sun OS 3 that was eventually required to run on an old Data General machine running some (at the time) current version of Unix.
Now, we knew ahead of time it would be painful porting the C code to the Data General because it had 9 bit bytes / 36 bit words but didn't realize how ... lacking... the Unix implementation would be.
It was approximately 5 hours from the start of the porting task when the wise executive decision was made to simply buy the customer a shiny new Sun box.
I had one recently that largely failed due to my inability to thoroughly convince management that rewriting the app would be cheaper in the long run than to keep maintaining it as it was. If I had only read up on technical debt sooner, it may have been a success. Jeff's latest article on the topic was about 8 months too late for me!
All told the app was about 75K lines of C# code but it was a maintenance nightmare (in-house application). A handful of god classes and the rest were what I called puppet classes (classes by name only, the god classes "pulled the strings" for everything they did). Almost nothing was user-configurable so developers were responsible for everything.
In hindsight, the biggest roadblock to success was the app itself. Keeping it running was a full-time job for 3 of us. I think the best thing we could have done was to keep on refactoring. The "version 2" app had some real good concepts and we should have kept on trying to get them integrated instead of starting over... Had we done that, we could have built the big components after stabilizing the original app.
I once attempted to port a game I wrote in DarkBasic to C.
The problem I ran into was that DarkBasic was such a limited language (for example, no argument passing by reference) when I ported it I attempted to do a straight port... IE, I tried not to refactor it appropriately for the language I was using...
The result was a big mess...
I probably could have gotten it working, but I stopped after about 2 days because I realized it needed more than just translation to move to C...
I had written a Pacman clone using C and Allegro back in the day and I tried to rewrite it to run on the Dreamcast.
That was some horrible code. I couldn't really salvage much from the code base and scrapped the idea.
I learned that regardless of what I thought at the time, I was a really horrible programmer back then and I had learned a lot in the passing years. It also made me realize that in a few years time, I should learn enough to look back on the code I was writing today and think the same thing. Basically, I should always strive to become better.
I was once asked to convert a program which drove a photo typsetter on a DEC-System10 to IBM 4381. Looking at the code, I discovered that the original developer had, for no obvious reason, written various bits of the program in the following different languages:
DEC FORTRAN
Algol 68
BCPL
MACRO-10
This was a great testimony to DEC's support for multi-language programming, but it was the only time I've had to go to a user and say "No can do".