Trying to do this on Windows 10.
I have a VB6 folder and I'm trying to make a solution out of it.
Visual Studio succeeds in making a project, but when trying to compile it gives millions of errors (see image).
I've read conflicting info about VB6 support in Visual Studio.
On one hand it's written that Visual Basic is supported, but not VB6?
There also used to be a VB6 IDE, but I can not find a download for it.
Should I use Visual Studio 2008 or something?
What are my options?
Thank you.
When Microsoft today uses the abbreviation "VB", they usually mean "VB.NET", the successor of classic VB published by Microsoft in 2002. According to this source, the latest version of VB, called VB6, appeared in 1998, and 10 years later Microsoft dropped any support for VB6 and its IDE.
Unfortunately, VB.Net is not backwards compatible to VB6, it is a different programming language (though it has some properties which arguably make it easier to port VB6 to VB.Net than to other .Net languages like C#). You cannot compile VB6 programs directly with Visual Studio 2002 or later, you usually need the original VB6 IDE. That leaves you basically with two options:
Try to find a copy of the old VB6 IDE and compile the program with it (if you cannot get it from where you got the source code, according to the comments, you may have luck at Microsoft, when you have the right developer subscription level).
Port the VB6 application to VB.Net. For this, however, you should have some not-too-basic knowledge of both languages, know the differences and ideally have an environment where you can test the original application against the ported one. I did this by myself in the past for some applications, so I know it can be less effort than recreating an application completely from scratch. However, this depends a lot on the specific application, how large and complex it is, how large the UI parts are and which kind of 3rd party components were involved. To be honest, if the application is not trivial, you should have a VB6 IDE for this approach, too.
Note also when your old VB6 code uses 32-bit third party OCX/ActiveX components, for porting it to VB.Net I would recommend to use VS2019 or an earlier version, not VS2022. The current Winforms Designer of VS2022 is not compatible with 32 bit OCX components any more, and it is unclear if MS will ever publish a version which will be.
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.
I'm using Visual C++ in Visual Studio 2010 Express, and in the past I remember when you use a string object and after the dot (eg: .) all the member functions will show in list, but that's not happening.
string myString = "hello world";
myString.
After typing the dot, all functions that are part of the string class don't show. Where in Visual C++ is the setting to make them show?
The functionality you refer to is called IntelliSense in Microsoft-speak, their version of autocompletion for variable names, functions, and methods.
IntelliSense is not supported in Visual Studio 2010 for C++/CLI projects. You will only get IntelliSense for projects written in native C++ code. This is explained in more detail here on the Visual C++ Team Blog. There is also a bug filed on Microsoft Connect; the official word is this:
Thanks for your feedback. Unfortunately in this release we had to cut the intellisense support for C++/CLI due to time constraints. If you want to get some intellisense like quick info and memberlist on the native classes you can get it by choosing no /clr support in the project properties.
Thank You!
Visual C++ Team
This is unfortunate news for many of us who work with C++/CLI projects, and we aren't left with many options. A question regarding those options has been asked here: What are people replacing the missing C++/CLI Intellisense in VS 2010 with? The summary is people are either going back to VS 2008
(I believe the Express Edition of 2008 is still available for download if you look around), or purchasing third-party software such as Visual Assist X that promises to bring back IntelliSense.
It's worth mentioning, however, that Microsoft does not regard C++/CLI as a "first-class" .NET language. There's little (if any) reason to start new projects using the language. It's designed for interop purposes between native C++ and managed C# applications. If you want to write C++, you should target the native Windows API (create a new Win32 project in VS). If you want to write managed .NET code, it is highly recommended that you use C# instead (that's a different version of Express that must be downloaded separately). The syntax is very similar between C++ and C#, but you will still have to learn the .NET Framework and idioms. Both native C++ projects and managed C# projects have very much improved IntelliSense support in Visual Studio 2010, so you're guaranteed to be much happier with either of those.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
In my admittedly somewhat short time as programmer, I have used many development environments on many platforms. Most notably, Eclipse/Linux, XCode/OSX, CLI/editor/Linux, VisualDSP/Blackfin/Windows and MSVC/Windows. (I used each one for several months)
There are neat features in pretty much all of them. But somehow, I just can't find any in MSVC. Then again, so many people really seem to like it, so I am probably missing something here. So please tell me: What is so great about Visual Studio?
Things I like:
Refactoring tools in Eclipse
Build error highlighting in XCode and Eclipse
Edit-all-in-Scope in XCode
Profiler in XCode
Flexibility of Eclipse and CLI/editor
Data plotting in VisualDSP
Things I don't like
Build error display in MSVC (not highlighted in code)
Honestly, this is not meant to be a rant. Of course I am a Mac-head and biased as hell, but I have to use MSVC on the job, so I really want to like it.
The best thing about visual studio is that it's the host application for Resharper ;)
It depends from programmer to programmer. I preferably like Visual Studio because:
(1) Development is much faster as compared to other IDEs.
(2) Intelli-Sense concept works best in Visual Studio. In some IDEs I noted that the menu opens when you pressed the . and moved ahead. And also the concept of Intelli-Sense started with Visual Studio. I am sorry for hurting if I am wrong.
(3) I use Aptana Studio for PHP development. It is a great IDE as it is built on Eclipse, but still I am able to work faster, specially while working on HTML files, using Visual Studio than in Aptana. But again, Aptana also has some very neat features.
(4) I find debugging a .NET application using Visual Studio much easier than working with other IDEs.
IMHO, Visual Studio has one of the best debuggers in the business. Much easier to use than the many graphical frontends to gdb out there.
Visual Studio is more integrated with its supported languages than anything I have ever experienced (I've been around the block--Aptana, Eclipse, Zend Studio, etc.).
Add ReSharper to the mix, and I'm in heaven.
What I like is the:
Intellisense (code-comletion features)
In-environment documentation
ReSharper is a plug-in which enhances these things and adds some more advanced features like large-scale refactoring, killer object discovery features, code validation against recommended standards (which you can change to fit your own needs).
After close to 10 years using and loving Visual Studio up to version 2008, I have been doing some Java development in Eclipse for a few months and I am quite surprised that, in my opinion, Eclipse is a much more advanced IDE. I just miss a lot of features when I go back to VS.
Perhaps the people that think VS is the best haven't used any other modern IDE lately.
I had the same question myself, since everyone seems to love Studio (and I personally think it's not even close to Eclipse's abilities).
After a lot of reading, I came to the (possibly wrong?) conclusion that: Visual Studio is great for .net languages, but Visual Studio for C/C++ is just not close to as good.
Almost everyone who speaks so highly of Visual Studio is coming from a .net background, and a lot of the wonderful things they keep talking about, I just couldn't find when working on C++.
This, btw, makes a lot of sense: the main effort of Microsoft is to push .net forward, and the tight integration with Studio makes it a very powerful IDE (the same way Eclipse is great for Java development).
If you are using Visual Studio for C or C++ programming, you should really look into Visual Assist X. It adds refactoring and better syntax highlighting and a few extra things.
If you are using Subversion for version-control, you should also look into VisualSVN (best) or AnkhSvn (free).
With those add-ons you might find Visual Studio more to your liking.
'Out of the box', I can write a program without having to go through all the hooplah of installing CDT (or whatever other tools). This is a real PITA for Ubuntu and not much better on windows. (The updates never seem to work right, there are always stupid package incompatibility problems, or special install steps).
The environment 'feels' natural to windows and non-clunky, and that lack of awkwardness counts a lot toward productivity. Shortcuts are common with other windows apps, window behavior is the same, etc.
VS is also not cluttered by a crapload of windows when you open a project. I'm sure that there are ways to save the perspectives in Eclipse so you don't have to do this every time, but it is an extra step.
Visual Studio isn't a great IDE at all - I discovered that when I started C# development.
With Resharper it's pretty nice, with features present in better IDEs like Eclipse andIntelliJ IDEA.
I have no idea why Microsoft doesn't just buy JetBrains and merges Resharper into Visual Studio.
Visual Studio Team System Data Base Edition - all the tools you need: code editor with designer, Source Control, Team View and , what's best - Data Base deployment!
Probably someone else already gave this answer, but:
DEBUGGING Tools
That's it. Simple as that. Point me to one tool that can debug code as fully as VS can, and I'd marry it (yes, I'm married to VS). When you are targeting .Net, things get even better.
Which one did you use first?
From someone who has been developing since...uhm...punching holes in cards and has seen IDEs evolve I actually like using Visual Studio, but I like other ones too. I find Visual Studio is best with Microsoft specific languages such as VB or C#, and it has many of the features comparable to the points you say you like in others.
I do find that I need time to get used to a new IDE because since I use VS a lot, I'm usually looking for the VS way to do something. So maybe it's just the case of giving it time. And if you don't like it try out the customisations to change it or turn it off.
I dare say that VS introduced some ideas that other IDEs adopted and vice versa.
My top favourite thing is the intelli-sense that never seemed too obtrusive compared to other IDEs, and for C# VS 2003 seemed to get a lot clever at predicting what I wanted to type.
It certainly is not an IDE to despise.
VS is getting better from version to version, with 3rd party tools like resharper it is as good as the other tools. (sames goes to profiling.. the 3rd parties are pretty good).
basically - if you coding dot net - this is the tool, and if you're coding java - you have the others...
so the real question - which framework you like better, and not which IDE....
.... and if you are only using good old c++ I think which ever tool you're used to...
I used to compile c++ on borland on dos and I was happy :-)
I use both Delphi and Visual Studio. While I prefer Delphi (for a lot of reasons), there are some things that Visual Studio does better.
The code editor works better, making writing code smoother, and therefore faster.
The help. It's faster, returns more relevant results and is better integrated into IDE.
It's more of a .Net thing than Visual Studio, but I'm really liking ASP.Net, so I'd have to call that another win for VS.
And for bonus points, I'm also a big fan of Delphi Prism, which is hosted in Visual Studio.
So, if you're writing code for Windows, there are a lot of things to like in the Visual Studio IDE.
The debugger (I primarily use C++). I make sure my projects work in Visual Studio all along, even if my team in my job isn't supporting it, because it always saves our hide in the end. Otherwise its non-standard solution/project system is somewhat annoying.
Also, for someone accustomed to using VS, Eclipse is far too sluggish. It's like an ice hockey fan trying to become a soccer fan. It can happen, but it's not easy.
I tried using VS2010 for working on a Great Plains / eConnect project, and it kept crashing on me.
I would like to like this IDE, but I can't even use it right now. VS2010 has the featureset I need to work on the above (with the newest versions).
I like VS because it is the more responsive one (runs circles around Eclipse for instance). I'm still using 2005 though and not looking forward to the upgrade to 2010 (we skip every other release, so not 2003 and no 2008 here).
A question to those of you who already looked at VS2010. How big are the changes that add-in developers will have to make in order to get their add-ins working under VS2010?
As luck would have it I've just written about this exact subject and shown what it took to upgrade my add-in. (links below)
Basically your answer is that there is a low-impact migration, because a back-wards compatible "shim" is in place for most functionality. Understandably though, to get the new stuff in 2010 like MAF, MEF, and WPF there will be some work on the developers part.
http://jb-brown.blogspot.com/2008/11/migrating-visual-studio-add-in-to-2010.html
http://jb-brown.blogspot.com/2008/11/migrating-visual-studio-add-in-to-2010_29.html
(more to come)
Lastly - Be sure to read this outstanding post from Carlos Quintero, MVP about Add-Ins, Frameworks and CLR compatibility. Carlos's blog is the best I've found for add-in stuff.
We've already migrated a development version of our Visual Lint product to VS2010, and for the most part the migration was straightforward - or would have been if there weren't so many bugs in the Visual Studio 2010 Beta 1 automation model. The experience has been akin to the work we had to do to support VS2005 (by contrast VS2008 was a breeze), so it's obvious that VS2010 represents a major change in the evolution of Visual Studio.
As we're using the same binary for all versions of Visual Studio we support (which means the code is contstained to be native C++ throughout), breaking changes in the interfaces tend to be quite visible to us. This time, the areas which have caused us issues are:
The new .vcxproj project file format (we parse project files to read project properties as that's more reliable across multiple Visual Studio versions than using VCProjectEngine - the Visual C++ automation model). Hence we had to write a new parser for .vcxproj files, and as they are potentially very complex that was a major task in itself.
Various bugs in the command bar/command interfaces (presumably related to the new WPF editor/command bar integration). Carlos Quintero has blogged extensively about this subject, so if you have concerns in this area you would be well advised to read his blog.
An undocumented change to the add-in startup sequence in Beta 1 which meant that the DTE Window interfaces were not functional until the OnStartupComplete event had occured. MS have informed us that they are reversing this particular change in Beta 2 due to potential compatibility issues, but we've desensitised our code to this one now, anyway.
Toolwindows in Beta 1 can't be created by internal CLSID (though ProgID works OK). This is the last one we're waiting on before we can wrap up the last major bit of the port.
I suspect that our experience will be pretty representative for most add-ins - it is only if you are using the areas affected directly by major changes in Visual Studio itself (e.g. editor or intellisense integration) that the effects are likely to be particularly severe.
Finally, we're not planning to migrate the build itself to VS2010; it is currently built in VS2008, and we quite simply can't see any reason to migrate to an IDE which is showing every sign of still being a "work in progress" even when it RTMs later this year (that's just my personal opinion though - YMMV).