We are very excited to announce the release of Visual Studio 2010’s Release Candidate. The official announcement can be found on Soma’s blog. You can download the RC from this location and it includes a go-live license for people who want to deploy in their production environment. This release incorporates many Customer Connect bug fixes and includes significant performance improvements. Just like Beta2 you can log Customer Connect bugs for this release. Here you can find a list along with descriptions of what is new in Visual Studio 2010. We are excited to see your feedback and answer your questions.
Visual C++ Team
@Li Shao - thank you, setting it up with project to project references instead of project dependencies fixed it
I've converted a smallish C++ project (~45000 lines) to VS2010's format and the project makes moderate use of Boost.
IntelliSense takes about 15 seconds to populate on a simple this-> within a class.
Caveats: I don't have a similarly sized project without the use of Boost to test with, nor do I have other hardware to test with. It might just be that my hardware is on its way out (I've seen lots of hard drive-related errors and the like).
It works perfectly snappy for even smaller projects that I've tested with, and I can't imagine that you didn't test use cases with Boost, so I'm assuming that my computer is simply garbage. Still worth mentioning if it leads to any performance increases.
The product is looking extremely solid otherwise. You guys and gals have done some great work.
Bill, I had the same experience with Beta2, just including spirit.qi 2.1 into a project crippled intellisense, which wouldn't be so bad except that the entire editor hangs. Back to Visual Assist X, again. :-/
@Adam, can you please try your scenario with the RC? we definitely don't want to cause editor hangs!
Why no snippet support for C++????
Why no class diagram editing support for C++????
As far as I can see, VS2010 is NOT the new VC6. It sucks!!! It is as same as VS2005 & VS2008
15 seconds is bad on simple MemberList operation. We've been testing with Boost 1.40 and we did find bugs. Most of those are fixed in current VS2010 RTM build. You might not have enabled PCH usage for the project? Can you check? If PCH enabled, can you please make sure you're references to Boost headers are within PCH borders, i.e. no #include statements after #include "stdafx.h" etc.
Windows C++ Team
Oh BTW does VS2010 fix the slow incremental links and slow multi-project builds? If it doesn't, don't bother releasing it.
When are you guys going to fix Visual Studio? Ever since VC++ 6.0 this product has been going backwards. Multi-project builds are painfully slow. At least with VS2003 we could use Fast Solution Build to get around your horribly slow linker. FSB was never released for VS2005/VS2008, so we just ignored them. But now Windows 7 doesn't work with VS2003, so we have to upgrade. But really in ten years what have you guys done? Nothing. You add all sorts of crap none of us care about. All we want is a fast C++ compiler that works? Try googling (sorry, "binging") for "Visual Studio 2003" and "Windows 7" and you'll see why the world hates Microsoft so much. Just fix this damned wretched compiler that we're all stuck with.
PS. Telling us to run VS2003 under Virtual PC is a crock.
PPS. If we could upgrade to VS2008, we could, but we'd rather have a fast compiler. Hell! If you can't fix that I'm going back to XP. Anything better than growing old and gray waiting for your lardass compiler to shuffle its fat ass.
> Very Depressed
It should be possible to use the MsBuild-system in VS2010 to launch the VS2003 compiler.
So you will use the VS2010 IDE but the VS2003 compiler. See this guide for how VS2010 supports this:
Btw. VS2010 is just as slow as VS2005/VS2008 when it comes to compiling and linking.
The IDE sure has gotten slower and fatter over the years. The beta was horrible in performance. Are we ever going to see a slimmer, faster IDE?
It seems that all products Microsoft do and full of bugs, bloat and performance issues.
In all previous versions of Visual Studio it's been possible to place the exe in a different directory than the other output files (.pdb, .obj etc), but now I'm getting a warning:
warning MSB8012: TargetPath(F:\FrameworkTest4\Release\FrameworkTest4.exe) does not match the Linker's OutputFile property value (F:\FrameworkTest4\FrameworkTest4.exe). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Link.OutputFile).
I have managed to get things to work by also modifying the Debugging Command to match where I put my exe. So now it's mostly just an annoying warning on every compile.
Of course, that's until I saw this Code Analysis thing and wanted to give that a shot, which promptly gave me this error:
MSBUILD : error : CA0055 : * Could not load file: 'F:\FrameworkTest4\Release\FrameworkTest4.exe'.
Of course that's not where the exe is, or is supposed to be. I don't understand why this change has been made. It was good the way it was, now it seems I am forced to put the debug output in a specific directory for everything to work, so why even have an option to change it? Is there some way to resolve this issue, or is there an explanation of why this has changed was made, or do I simply misunderstand some new concept in the 2010?
That's a fair comment. The IDE has gotten "fatter" full of new features over the years, and unfortunately Beta2 was a good example of its impact on performance and heavy memory usage.
However, I think you'll be pleasantly surprised how much perf and memory improvements we've done in VS2010 RTM after Beta2. I cannot quantify the improvements, but our entire focus post Beta2 was on perf and memory usage of VS. So, yes, answer to your question is, it won't be as much slimmer, but it will be much faster.
@Rolf Kristensen (Cool site BTW) and @Very Depressed
We hear you on the throughput issues We have made some improvements in VS2010 to help compile and link times. We have done some work on speeding up LTCG (something that we recommend you use) compilation by about ~30% in our test scenarios. PGO PGI run times have also improved. We have also done work on multi-threading the linker by offloading the pdb writing task. There have been other CQ or code performance speedups across the board.
Specifically, look at Ten’s blog post: http://blogs.msdn.com/vcblog/archive/2009/11/02/visual-c-code-generation-in-visual-studio-2010.aspx, Chandler’s post: http://blogs.msdn.com/vcblog/archive/2009/09/10/linker-throughput.aspx and Lin’s post on LTCG and PGO improvements: http://blogs.msdn.com/vcblog/archive/2009/12/01/gl-and-pgo.aspx
If you are not seeing speedups in your projects please let us know through the blog here or through Connect. We’d like to dive deeper into your scenario and see if there are improvements that we could do on our side.
@Emil Persson: This warning was introduced to workaround a limitation that we have when converting applications from previous version of Visual Studio.
As you may know, Link.OutputFile is the value defined at Linker -> General -> Output File on the property page. By default, its value is $(OutDir)$(TargetName)$(TargetExt), which is the same as $(TargetPath). When we convert application from previous versions, however, it is pretty hard for us to parse Link.OutputFile to figure out what exactly are the the values for $(TargetName) and $(TargetExt),as different customers may format them in different ways. To work around that, we have decided to have conversion preserve the value of Linker.OutputFile. $(TargetName) will be default to $(ProjectName). $(TargetExt) will be default to the default extension for the application type: .dll for Dynamic Library, .lib for Static Library and .exe for Application. Warning MSB8012 will be issued if Link.OutputFile and $(TargetPath) are not the same in the conversion log. You will get the same warnings when building the application.
$(OutDir), $(TargetPath) and $(TargetExt) are exposed on the "General" property page, as "Output Directory", "Target Name", "Target Extension", respectively. You can manually change the values of these properties so that you no longer get the warning.
In your particular case, it looks like your $(OutDir) is F:\FrameworkTest4 instead of F:\FrameworkTest4\Release, you can change the "Output Directory" value to "F:\FrameworkTest4" and that should eliminate the warning. It should take care of the issue you are seeing with lauching exe as now the value of $(TargetPath), which corresponding to $(OutDir)$(TargetName)$(TargetExt) is 'F:\FrameworkTest4\FrameworkTest4.exe'
Li Shao, Project and Build Team
Thanks Li, the solution was easier than I thought. :)
So I'll give you a harder problem then. ;) I just yesterday found an issue with the machine code generated by the compiler in certain situations. See my blog post here:
This is not specific to VS 2010, I saw the same problem in VS 2008. I could provide a sample project if you guys need.
Thank you Emil for reporting the issue. Could you open a connect bug for this. You can submit connect bugs through here: http://connect.microsoft.com/VisualStudio/content/content.aspx?ContentID=12362