Hacker News Reader

Comment by kossmoboleat | Hacker News Reader

VS 2008 here, somebody apparently tested 2012 but nothing came out of it with people fearing that a different C++ compiler will break everything...

View on HN

Man! If you're doing C++ then you definitely want to get onto 2012/2013 ASAP, the improvements in tooling are amazing. "Navigate to.." alone is worth it.

VS 2008 is the last one capable to compile the C++ to produce the binaries that can run on Windows 2000. Believe or not, I actually need that. That prevents me to use any C++ language changes introduced after VS 2008.

The frustrating part is that MS actually removed the existing code from the already existing libraries (but which are not binary interchangeable between the compiler versions) in order to disable the support for Windows 2000. Otherwise I'd be able to use even VS 2013. They did the same for XP with VS 2012, but more people made the fuss so now even VS 2013 should support XP, AFAIK.

"MSDN Camp"[1] in its full glory.

[1]: http://www.joelonsoftware.com/articles/APIWar.html

Wow, a long article but still relevant. As I was reading this I realised how closely it matches even the latest metro ui fiasco (for developers). Indeed "MSDN Camp" has won. Thanks for the link!

That's "MSDN Magazine Camp". MSDN Magazine was a rag of a publication that was mostly just advertisements for 3rd party tools than it was anything interesting about programming. MSDN is the Microsoft Developer's Network, which houses basically all of their documentation, tutorials, articles, and support for developers.

Yea, MS even begin to remove references to old Windows versions from MSDN after they go out of support.

I use VS2008 for C++ and VS2012 for .NET. I upgraded our C++ projects to VS2012 as a proof-of-concept and build times went from 5 minutes to 15.

Our projects aren't particularly great, virtually everything is in stdafx.h directly or indirectly and small changes results in rebuilding. The increase in build time would have hurt us.

VS2013 is a bit faster (~10 minutes, last time I checked) but still a bit of a hit. Allegedly this is due to the extra time parsing the C++11 language bits.

I don't think this is a huge deal (our code should be better), rather something to bear in mind.

Also, if you recreate your project instead of upgrading it you'll end up with a default instruction set of SSE2 (instead of SSE) and your exe will suddenly not run on Athlon XP-era chips.

Upgrading is not something to be done lightly.

I think the improvements we'd get in Entity Framework performance, testing, and analysis would be well worth it.

> I think the improvements we'd get in Entity Framework performance

Technically, that's not a VS2012 or 2013 feature, that comes from .NET 4.5, which you can use with VS 2010.

However, the testing and analysis is well worth it. I don't know what your source control is, but paired with TFS 2012, it's a pretty large productivity improvement for my team over VS 2010 (as large as you can get from an IDE upgrade).

I'm using SVN for source control.

And I'm a little confused on the first part, because .NET 4.5 is not supported in Visual Studio 2010.

I just upgraded a VS2008 project to VS2010 and got a huge boost in compile times, worth it for that alone.

IMHO the killer feature with VS 2012 is C# 5 and await/async. It takes a good afternoon to get your head around it but is totally worth it (unless you develop CPU-bound web applications exclusively, I suppose).

I'm still on VS 2008 as well. Is there anyone who has upgraded a substantially sized C++ project from VS 2008 to one of the newer versions that would be willing to share their experiences?

Yes. 700 of them in fact, from VS2008 to VS2010, a couple of years ago. Here's what I found...

- VS2010's macro system is just broken, and fails to coexist with VS2008. Basic macros using the DTE object work; more sophisticated ones (I have a few that used DTE90 - or was it DTE80? - anyway, whatever, they manipulated project properties) seemed to be literally impossible to make work, due to some kind of conflict between system-global components that both try to install. Pretty shameful.

- VS2010+ craps massive files into your solution folder, worse even than the NCB palaver, and so your more junior and/or inept programmers will keep checking that junk into source control.

- It's common in VS2008 to change the build product name by going to the Linker or Librarian property page and just changing that Output File property. VS2010 doesn't like this, though, due to some MSBuild limitation, and would much prefer you to modify the settings in the General page, leaving the output file name as its default of something like "$(OutputFolder)$(OutputName)$(OutputExt)". Of course, the project upgrade doesn't actually do anything about this for you, so after importing all your projects that work the old way way, they won't work properly, and you have to fix each one up yourself.

- VS2010 dependencies aren't like VS2008 dependencies. There's a new C#-style References section that manages the linking. Dependencies can still be set, but they only affect build order. (Also - when you change dependencies, you need to close and restart Visual Studio, because sometimes they don't take effect properly.)

- The new C#-style references are part of the project, not part of the solution, so they come with the project when you add it into a solution. Add a project but forget its references and you just get a cryptic error (along the lines of "Project has no Debug|Win32 configuration") when you try to build; to add insult to injury, when you go to the References page, the missing reference is not actually shown, because (of course...) it's not in the solution. You need to open the vcxproj in a text editor and look at its contents and compare it to the references VS2010 shows you to work out which is missing.

- When a project refers to a non-existent file, the project will be considered permanently out of date. VS2010 won't give you any clue about what's wrong, and to track the problem down you (as I recall...) have to change some random setting in a file you've never heard about, which gets MSBuild printing stuff out via fucking OutputDebugString, leaving you to scrape through its (unreadable) output with DbgView until you find the magic message that hints at the file in question. (The link I have in my notes is http://blogs.msdn.com/b/vsproject/archive/2009/07/21/enable-...)

- If a solution refers to a non-existent project configuration, you get a cryptic "The parameter is incorrect" error when trying to build, with no clue as to what's wrong.

- If you happen to open one of the built-in MSBuild files in the text editor, which can easily happen if you click on the wrong warning, all hell breaks loose and MSBuild starts to spew warnings everywhere each time you build.

This excludes a few vendor-specific issues I had, with my favourite (I think...) being the plugin that would instantly terminate Visual Studio if you used the phrase "%(ProjectFilename)" (instead of "%(ProjectFileName)") in your build output paths.

Needless to say, after this dreadful experience - and I have to say that if you have never embarked on an endeavour such as this, you probably won't (as I didn't) appreciate just how long it can take, and how time-consuming it can be to track down and fix all these issues ocurring in all these opaque black boxes - I swore off VS2010 completely. And to this day, I have yet to use it in anger.

Reply on news.ycombinator.com