§ ¶Visual Studio 2010 RC: Impressions
The Visual Studio 2010 Release Candidate was released last week, and I dutifully pulled it down and installed it since I've been tracking the VS2010 betas. Since I use Visual Studio very heavily, I have a lot of interest in coming down the pipe. Of course, anything could change between RC and RTM -- including of course the ship date -- and so all of this has to be taken with a grain of salt, but given that this is the Release Candidate and we're about two months from the current ship date, what we've got now is fairly representative of what we can expect from RTM.
So, what's the RC like?
First, general impression: I don't hate it. I should explain a bit. When I first pulled down the Visual Studio .NET beta, I hated just about everything in it, including the slowness, the awful UI, etc... but I thought, hey, it's a beta, it'll get better before ship. Then we got the final version, which was pretty much exactly like the beta, and the only thing I could think of was: I'm screwed. Ever since then, my approach to evaluating VS has been to pull down the beta, try using a bit, and then imagine how much my life would suck if I had to use that version in production work. I'm pleased to say that after using the RC for a bit, I don't hate it -- I can actually concentrate on what I'm doing without being distracted by huge gaffes in Visual Studio. That's a promising start, at least. It took me about an hour to get Altirra and VirtualDub compiling, which is not too bad. Of course, there are still glitches in various areas, like:
The UI: It's blue. No really, it's got a dark blue window background. It doesn't bother me much, although it is a bit startling at first. Judging by bug reports, though, it's really distracting to some people. A VS team member has written an extension to change the color palette. It would be much better if this was integrated into Visual Studio itself, but at least there's a way to change the colors. There were some bizarre rendering errors in the UI, especially in combo boxes, but it seems that these have been fixed since beta 2. The unhinted menu text has also been fixed. The UI unfortunately has a tendency to redraw a lot, which manifests itself as massive lag and flickering whenever you resize the window.
Editor: The editor has been totally rewritten in WPF, so unfortunately, there are some random regressions here and there, like the caret ending up in unexpected positions. The significant change here is that due to the change to WPF the editor can no longer render non-antialiased fonts. ClearType font quality has been improved noticeably since beta 2, although there is still a little bit more color fringing compared to GDI. Given that going back to GDI rendering for this is release is likely impossible, if you are one of those people who cannot tolerate antialiased font rendering you are absolutely going to hate this release just for this reason alone. It's always possible that nonantialiased text rendering will be added for RTM but I highly doubt it. Editor speed doesn't seem too bad; on Windows 7 it seems decent, and I suspect on Vista or with a WDDM 1.0 driver it might actually beat VS2005 with a high resolution due to bypassing software GDI rendering.
C/C++ Compiler: Fairly solid; expect few problems here for existing code. I haven't had a chance to use the C++0x derived features much, so I'm not sure how solid they are. I did try to break lambdas a bit, but surprisingly they work fine with vector intrinsics types. Come to think of it, I don't think I've logged a single bug on the VS2010 compiler. That's got to be worth something.... or maybe I'm slipping. I haven't seen any big overall improvements in code generation, but there are a few tasty improvements in intrinsics code generation.
Libraries: I don't use ATL or MFC, so my experience here is in the base CRT and STL libraries. Everything looks pretty good here too; the weird min/max overloads are gone and my stuff compiles and runs without breaking now. The manifest system has been ditched and they're back to the old MSVCR**.DLL filename based versioning for the CRT. One change that I ran into that did cause problems, though, was that RC has a version of the Platform SDK that at least is definitely newer than VS2005; I don't know if it's newer than VS2008, but it did break a bunch of previously valid code that I had, and it's also incompatible with older versions of the DirectX SDK due to a header conflict.
Debugger: Beta 2 had some pretty big performance problems here, mainly related to overzealous refreshing in the panes and slow text view updates. RC seems better in this regard and it's much closer to VS2005 in stepping speed, including disassembly view. There are some interesting changes in some of the views, such as thread and breakpoint grouping, but nothing earth shattering for native code development.
Intellisense: It still spends a lot of time parsing, sorry. You do have good visibility into what it's doing, and in beta 2 the accuracy and popup speed are decent. I haven't had a chance to use it with a really big project, so I can't tell if it still has the update delay problems that VS2008 had. One minor nice touch, though: it now autocompletes #include statements. No support for C++/CLI... so if you do interop work with that, well, it's going to be a bit rough.
Resource Editor: Looks about the same as before, unfortunately. Don't expect a lot here unless you really like using a mockup image to layout your dialog. And yes, it still picks the frigging bottommost control in a stack. (I'm going to keep bitching about that until I die or until it gets fixed. Don't try to stop me. Get off my lawn.)
Project System: A lot of the kinks have been worked out in the RC, and once you get everything up and running, odds are that you won't have too much trouble with the new MSBuild-based project system. The output has been cleaned up since beta 1, and in the RC it's actually too quiet: you'll have to raise the MSBuild logging level to Minimal if you want to see the names of files being compiled. Where you are likely to experience major pain, however, is in initial project conversion. Neither Altirra nor VirtualDub convert cleanly: there are still bugs in the Makefile project conversion that affect Altirra, and VirtualDub breaks in several ways. The main problems are: additions of backslashes to various properties and macros, causing command lines with quoted paths like "$(IntDir)" to fail; user macros not declared in forward evaluation order silently break, which in VirtualDub's case causes it to build into the root directory until fixed; and there are numerous problems where quotes are either handled improperly or simply cause conversion to fail. There has been major progress in this regard since beta 2, but if you have a non-trivial project chances are low that it will convert successfully in RTM without the need for manual fixups. The underlying project format is also tremendously more complex and radically different from earlier versions, so if you're expecting to be able to change the version field in the project file from 10.0 to 9.0 or 8.0: forget it.
Help: Oh boy. Sorry, but I'll just say it: the new Help system sucks bigtime. It didn't even install properly for me in beta 2, and in the RC it's a shock: the help viewer has been replaced with your web browser connecting to a custom local web server. (Sadly, this means that Help startup time is still likely to be dominated by disk thrashing if you're using Firefox as your web browser.) I hate local web server based help systems with a passion, but the real kick in the pants is that the index is gone. That's right, you get search and TOC, and that's it. There also doesn't appear to be any way to filter. The Connect bug on this is now up to 71-0 in voting and is #5 on the Most Up-Voted Active Bugs list, so I hope the Help team got flak vests. The good news is that apparently the underlying help API does support an index and people have been working on replacements in the old help viewer style, such as H3Viewer.
Source code control: Haven't really exercised this, but Perforce's P4SCC plugin does work with RC.
.NET Framework: I don't do much .NET and haven't tested this much, but there is one specific improvement I want to call out. As a programmer who primarily writes native code, one of the things that absolutely drove me nuts was that if a .NET program crashed in a call into native code, the runtime captured the native exception and translated it to a .NET exception object, which was then caught or displayed. Unfortunately, AccessViolationException is totally worthless for debugging the problem on the native side, as it contains no native context whatsoever and the unwind process blows it away, preventing a JIT debugger from working. This has now been fixed and the default behavior is for such critical exceptions to tunnel through .NET exception handlers and activate the native handler. This has two benefits: first, you can now get the native call stack and context to debug the problem, and second, it makes it harder for applications to accidentally catch and eat such exceptions and continue in an unstable state. You can still use attributes to tag cases where you still want to catch and handle such exceptions.
Editions: I missed the announcements on this around beta 2, but the major change here is that Standard Edition is gone. This is a bit of a shock to me as previously in VS2008 MS had been going the other way and pushing functionality down from Professional into Standard. Express is still around and has gained some features since VS2005 (most notably MASM), but if you need Win32 resource editing, MFC/ATL/OpenMP, add-in support, source code control integration, or project level support for x64 this will put you in a bind as you will have to go to Professional. So, unfortunately, this is likely to be a fairly big price hike for individuals. :( There is also a lot of change up in the Team System range as well, but that won't matter if you stick with the common practice of using Professional Edition with third party packages for source code control, unit testing, etc.
Again, we'll have to wait for the RTM for the final verdict, but my current thoughts: if shipped as-is, I think I could work with this version. For C/C++ development it's a bigger change than VS2008 from VS2005, both in terms of added features and in regressions/breakage, but I'd say it's a net plus. Whether it's worth the cost and the upgrade churn... I don't know. It certainly doesn't meet the "must have" bar for me, but at least I'd feel I was getting more value than VS2008, which I felt added so little for what I do that I skipped it.
The Visual Studio team has made additional fixes to WPF text rendering for the RTM version which will improve text clarity: they've identified and fixed a problem that was still causing antialiased text to be blurrier than GDI, and they've clarified that ClearType is only forced on with the Consolas font, with every other font rendering non-antialised if the system is set for that.
Gah, why does the help get worse and worse with every Visual Studio version?
I have zero faith in Connect getting any help-related bugs fixed. People, and lots of them, have been complaining for years about the problems with F1 in Win32 projects taking you to documentation on anything-but-Win32 and the bugs keep getting closed as "cannot reproduce," which is a joke after so many reports over the years. I haven't tried VS2010 but if I F1 over "GetDC", for example, the help claims the function doesn't even exist. F1 over most window messages takes me to pages about their MFC handlers, which is a joke considering anyone using MFC would never even see the window message or want help on it. Or you end up with docs on .Net or Windows CE. It's a joke.
Back when we could manually filter the help it was okay, although still ridiculous that the IDE knew what kind of project you were writing but couldn't apply those filters itself. Then they removed the ability to do that. Sigh.
I love Visual Studio but god dammit I wish they'd sort out the help, the awful project-settings UI and the awful dialog editor.
While I'm griping, it's also a joke that the new UI doesn't take its colours from the system-wide colors & visual style. Never mind having to install an add-on to configure the colors; why do I have to configure them at all if I want the app to look normal? Thanks largely to Microsoft's flagship apps, Windows is going the way of X Windows when it comes to a consistent look & feel across the desktop. :\
I am looking forward to several of the new C++ language features. Some of that stuff is definitely cool. But that stuff will be useful once in a blue moon while fighting the help & dialog editor will annoy me on a daily basis. Visual Studio has some strange priorities.
Leo Davidson (link) - 14 02 10 - 21:16
So, still VC6+WndTabs+VisualAssitX forever? (At least for 32 bit)
asf - 15 02 10 - 05:29
I think the writing was on the wall for Standard when Microsoft decided to REMOVE mobile development from 2005->2008. So if you want to develop for the "Windows Mobile Marketplace", you're already in Pro land. Given that mobile is pretty much the hottest development in the world (for now), I knew where this was going.
With the express editions out there and the ability to jerry-rig x64 builds by using the Platform SDK, there isn't much of a reason to need Standard except for that. I'm probably going to stick with Express this time around for home use.
Best thing I've noticed so far is the non-blurry text when scrolling in WPF, as has been the case in all previous versions of WPF.
Trimbo (link) - 15 02 10 - 06:14
The problem is, if Express doesn't quite cut it for you, the price has been rising over the years. It was already bad enough that they eliminated Visual C++ as a separate SKU, but this basically eliminates the entry-level SKU. Express has a lot of functionality, but missing add-in support and the resource editor are pretty big holes for Win32 development. Also, Express does not come with the CRT source, which can be a bit of annoyance when debugging.
I get the impression that the problem with the Mobile support is that it's from a separate team, which means that they constantly have to play catch-up with the changes to Visual Studio internals and that makes it hard to sync to the VS release schedule.
Phaeron - 15 02 10 - 06:52
So what about post-SSE4.1 extensions, like SSE4.2, PCLMULQDQ, AVX? VS2010 will have built-in support for all of these.
Yuhong Bao (link) - 15 02 10 - 17:48
If that's the only thing you're concerned about, the Intel compiler is a far better deal.
Phaeron - 15 02 10 - 18:39
am i the only one who sees WTF every time i read WPF?
:) (maybe it makes more sense that way)
whitetiger - 15 02 10 - 19:11
Had to launch 2008 a few weeks ago, just to compile ffdshow to check something, and wow how lightning fast it was, compared to 2010. Since beta1 I started using lambdas and could never go back. RC also does not launch so many vcpkgsrv, consuming 200MB+ each. Already a big improvement. And can't find the custom tool editor dialog anywhere. Is it gone?
Gabest - 16 02 10 - 05:12
The custom tool editor was nuked due to the project system change and won't be in VS2010. :(
Phaeron - 16 02 10 - 15:23
I hope I'm not opening myself to a giant flame by responding here :)
I'll start by saying that we'd love to look into some of the specific issues you mention in the post. As you pointed out, we have improved the project conversion experience and we'll take a closer look at some of the remaining issues you brought up. As for Intellisense, when is it "over-parsing?" We have a slightly longer initial parse time to create our database but it doesn't happen after that (e.g. every time you edit a header or change configurations). Hopefully our subsequent parsing for files you open in the editor (in order to provide some great new features like live error reporting) should be relatively fast. Where are you seeing the issue? We've seen some instances where successive Go To Definition operations end up too slow, is this what you're referring to? As you play with RC some more, we'd love to hear more feedback.
I can't really answer every other comment but I'll add a few things. Meanwhile, rest assured other members of the VS team will see the feedback in this post. Without going into the positives/negatives about the design of the new Help system, we have done a ton of work to make sure it handles C++ scenarios "out-of-the-box." For example, I'm happy to say that the examples Leo Davidson mentioned work perfectly in VS2010. We properly differentiate between MFC/Win32 functions by the same name, we removed redundant topics so that F1 for functions like "printf" also take you to the right topic.
Finally, while nothing will change for VS2010, we recognize the hole that we have left with the removal of the Standard SKU. It's something we'll be thinking very seriously about for our next release.
@Gabest - Are you talking about warm or cold load of VS? We've seen warm startup times on par with (and sometimes better than) VS2008 in lots of cases especially if you factor in full project loading.
Thanks for taking the time to play with the early release, log bugs and keeping a modicum of faith in us.
Boris Jabes [MSFT] (link) - 16 02 10 - 18:17
Boris, thanks for responding.
On the Intellisense issue, my experience is that in the course of development there are plenty of times where you need to make changes that will cause a major reparse, particularly headers near the PCH or that are simply framework level headers. My experience has been that even in the RC, whenever the engine has to do a major reparse, it can still take a noticeable amount of time, and this gets much worse if anything is competing for the disk (which I discovered after wondering why it was taking so long in one instance). My main point is that despite the improvements, there are still going to be cases during normal development where you have enough time to get a cup of coffee before the Intellisense engine is redone parsing. Interactivity in the RC is actually pretty good while this is occurring, but there are times where you have to wait for it to finish -- such as if you are trying to profile something on the machine. I actually like the improvements in accuracy over the past few releases, but the truth was that in the VC6 days I didn't have to worry about Intellisense much, and nowadays it's something that I do because it pops up and starts eating noticeable amounts of I/O and CPU bandwidth in the system.
As for the Help system, you should look at the Help-has-no-index bug on Connect for much more thorough feedback, but my feeling is that you're trying a bit too hard to try to make Help automagic and smart, when people would rather it have some better manual options. Personally, I don't want Help to try to figure out the right topic for the C++ keyword that I want -- I want to have options to forcibly exclude everything else. Even before .NET Framework and Windows CE really began to pollute the results, I used to rant about the MFC help conflicting with Win32. I think there's also some concern about the direction being taken with regard to trying to make the offline and online help experiences converge -- there appears to be pretty clear concensus that the offline experience was preferred and that the convergence is going in the wrong direction.
Reviewing what I wrote again, I think the most important overall feedback I can give is that the VS team might have bit off a bit too much in terms of infrastructure change in this release. In terms of change scale it feels about as big as the VS6 to VS.NET change, although I can at least say that this change wasn't nearly as disastrous. However, it has still resulted in a lot of breakage, some of which won't be recovered from until at least the next full product and which basically represents negative value in this release, like the removal of the custom rule editor and the blurrier editor text. As a result, you're going to have to make a harder case as to why people should upgrade to VS2010.
Phaeron - 16 02 10 - 19:07
Boris Jabes [MSFT]: I wasn't really referring to startup times, beta 2 was nearly unusable with 2 GB of RAM, but memory usage in RC got much better.
Gabest - 16 02 10 - 20:43
Phaeron: Ouch, I hoped there will be an editor for custom tools in the final build at least. The new system also doesn't seem to support mutliple files on the command line as before, or I just could not find the appropriate xml attribute to turn it on.
Gabest - 16 02 10 - 20:49
@Phaeron - we really don't like the idea of a coffee break to get Intellisense. Any chance we can get an email thread going to dig into the problem? Perhaps gathering a trace on your box might help us understand the bottleneck.
Boris Jabes [MSFT] - 17 02 10 - 06:40
My main development machine is a dell mini 12, 1.3Ghz atom cpu, 1GB ram. When VS2010 Beta 2 was releases, I was disheartened to note that it hiccupped 2-3 seconds every time I typed a word. I was happy to see when I installed the VS2010 RC that it was actually usable-ish, though still a tad sluggish. I'm sticking with SharpDevelop for now, but the RC has given me hope that the final version of VS2010 will be usable.
Zilog8 - 18 02 10 - 01:16
How's performance on large multi-projects builds? VC++ 6.0 was great, VS2003 was awful (until I discovered Fast Solution Build - which made it awesome) but VS2005 and VS2008 seemed slow (without FSB). Is 2010 any better?
Why does each release of VS get worse? They add all sorts of weird crap (WPF) but don't fix the fundamental things people actually care about.
Budge - 18 02 10 - 09:00
@Budge - we think we're at least as good if not better (on multi-core machines) than VS2008. Is there a solution you could point us to where we could verify?
Boris Jabes [MSFT] - 18 02 10 - 10:42
Well, I don't know about everyone else's experience, but I am desperately trying to give some loving to VS2010, almost in vain.
I am talking about the unbearable blurry text that's essentially still a showstopper.
To be honest, VS2010 Beta 2 and RC largely fixes this issue for the text editor window, but text rendered in *all* other windows is horrible. Even in the Properties Window, which is black-on-white, so I can't buy the usual "ClearType not supported in render targets with alpha" argument.
What's more, there is some kind of animated "auto focus adjustment" going on in almost every window after scrolling its contents. This literally makes my eyes sore.
Can't use VS 2010 until MSFT fixes WPF text rendering completely. At small point sizes like 8 or 10, the pixel grid should be given priority. I do understand that it's much better to render the Apple way at 150-200 DPI, but dammit, I want to develop software and I have large monitors because what I need is the screen real estate (and not setting the DPI to an insanely high level and have 40 chars in a line).
A good couple of us in our company use VS2008 Team System, so I'd venture that not fixing this would hurt MSFT, of course not because of our licenses, but because this is probably a literal showstopper for many.
Quite a pity, especially when .NET 4 and other BCL additions are so exciting.
Alan - 19 02 10 - 07:32
If I had to take a guess, the "auto focus adjustment" is probably occurring because you have smooth scrolling on and WPF is temporarily disabling hinting while the text is scrolling. That might be why I haven't seen it.
You might want to file a bug on the cases where the text is still blurry. At this point, they have the hooks in place to force text hinting on, so there's a chance they might still be able to fix those areas.
But yes, I agree in general -- smoothly scaling text is for rendering maps, not for UI in a dev environment. As I stated earlier, this one issue alone is going to be a major blocker for people upgrading.
Phaeron - 19 02 10 - 15:02
Phaeron, there already is a matching Connect issue raised with them, and I don't want to pollute their bug reporting system with duplicates.
Sadly BTW, the "auto focusing" I talked about happens after scrolling, not during it.
Two common scenarios I find hard to endure is that a) I look for a property in the Properties window, find it, then (once the window stopped scrolling, so it should be rock-steady) an effect occurs, which is not unlike someone rotating the manual focus ring on a camera back and forth for a few seconds; and b) I bring up Intellisense, and everything, every single character in it is blurville galore.
After 2-3 minutes I have to stop working and look away because my eyes are full of tears, and there goes my time in the zone.
Anyway, enough is enough. If there is no response from the "official" channel, I will file a bug report. Thanks for listening ;)
Alan - 19 02 10 - 20:27
Boris, thanks for your reply/feedback. I only just saw it.
It's great to hear that the Win32/C++ help problems have finally gotten some attention. Really looking forward to that in VS2010, probably more than anything else now (assuming it works as well as it sounds, of course).
Leo Davidson (link) - 19 02 10 - 23:12
Thanks for sharing feedback with us regarding the product. I will try and answer some of the conversion related questions below. Its good to hear that in RC the conversion experience is better, but it concerns us that there are a few that still remain. We intend to make the conversion experience as transparent as possible even though the move to the newer build system was a big task and with that came some design changes.
Where you are likely to experience major pain, however, is in initial project conversion. The main problems are:
- additions of backslashes to various properties and macros, causing command lines with quoted paths like "$(IntDir)" to fail;
In order to standardize how directory macros are used inside Visual Studio we added "\" to a few additional macros that did not conform, namely $(IntDir) and $(OutDir) etc. I can see how escaping can be an issue here, but the msbuild syntax doesnot require you to put quotes around paths as the msbuild parser automatically does that for you. If you use $(IntDir) without quotes everything should work as desired.
- user macros not declared in forward evaluation order silently break, which in VirtualDub's case causes it to build into the root directory until fixed;
This was a design change we made when compared to VS2008. VS2008 supported late evaluation of properties and user macros which means a macro could be used before it was defined and once it got defined the value would be correctly passed to where the macro was used. In VS2010 since we moved to MSBuild the design does not support late evaluation. Because of the evaluation a macro needs to be defined before getting used. During conversion however we do try to warn the user where ever possible if we identify such a behavior. We recommend that if you are using late evaluation that please restructure your properties to be evaluated before they can be used.
- and there are numerous problems where quotes are either handled improperly or simply cause conversion to fail.
There are cases where quotes are not handled properly. We actively look into these issues and fix them. We would like to capture this scenario. If you could share an example of such a project conversion failing at amitmo (at) microsoft (dot) com, we would be happy to investigate further.
Amit Mohindra [msft] - 20 02 10 - 07:36
> In order to standardize how directory macros are used inside Visual Studio we added "\" to a few additional macros that did not conform, namely $(IntDir) and $(OutDir) etc. I can see how escaping can be an issue here, but the msbuild syntax does not require you to put quotes around paths as the msbuild parser automatically does that for you. If you use $(IntDir) without quotes everything should work as desired.
This does not appear to be the case. I made a configuration called "Debug Test" and set the Makefile build command line to "echo nmake all OUT=$(OutDir)", and no quotes appeared.
Phaeron - 20 02 10 - 10:15
I'm guessing that Amit is refering to the fact that you're (usually) not required to qoute paths when passing them as input to an MSBuild Task since the task would presumably handle the quoting internally. This behaviour is really up to the task itself though since the MSBuild engine doesn't do any automatic quoting as far as I know (if it did it would create a real mess...).
So anytime you use MSBuild properties in another context like makefile or PostBuild commandlines you will have to handle any quoting yourself.
Jonyv - 21 02 10 - 22:29
If VirtualDub project files were completely converted to MSVC 2010 project style, technically it would be possible to use MonoDevelop to open and compile VirtualDub. MonoDevelop uses the MSBuild format for project files for C/C++, C#, VB.net, and other languages.
MSBuild can also be used independently of the IDE, so batch compiling is easier now.
However, this does break importing VS C/C++ projects into IDEs like Code::Blocks, because they only support the format used in MSVC 2003/2005/2008.
MonoDevelop cannot import non-MSBuild VS projects.
Sir Gallantmon (ニール・ゴンパ) (link) - 26 02 10 - 01:36
What kind of monitor are you running? Are you running at the native resolution? The reason I ask is that my friend has an LCD television and when she plays PS2 games on it, it does something like you describe. It looks OK as long as stuff is moving on the screen, but as soon as the movement stops, there's an effect that looks like a sharpening algorithm kicks in that makes the screen fuzzy at first followed a "pop" effect. It's very subtle and you can't see it from a good distance, but up close, it's BIG TIME annoying.
tankadin (link) - 02 03 10 - 10:06
Hi, I have a new post on project and conversion related issues: http://blogs.msdn.com/vcblog/archive/201..
Here is the section related to the issues you may run into when converting and building VirtualDub:
(1) Quotes used in makefile “Output” property
If you have a make file project with quotes used in the “Output” property, the conversion will fail. The fix is to remove the quotes in the “Output” property before doing the conversion.
2) Backslash in $(IntDir) and $(OutDir)
$(IntDir) and $(OutDir) are exposed at “General -> Intermediate Directories” and “General -> Output Directories” on the property page, respectively. To unify the format for $(IntDir) and $(OutDir), conversion has intentionally appended “\” to their property values if they don’t have one when converting them. Trailing “/”s are removed if there are any.
This, however, may break the build scenarios if $(IntDir) or $(OutDir) are used in makefile or custom build, where Exec task is used.
In the makefile case, nmake tool cannot evaluate the values if they are ended with “\”. For example, with this command,
BuildCommandLine="nmake /nologo "OUT=$(OutDir)" "OBJ=$(IntDir)""
Because $(OutDir) and $(IntDir) has a trailing “\”, nmake tool cannot properly expand them and OUT and OBJ will be evaluated as empty as a result. To fix that, you need to remove the “\” for $(IntDir) and $(OutDir) at the property page.
If $(OutDir) or $(IntDir) are passed to the custom build, including build event, custom build tool, custom build steps, you may run into build failure due to the fact that “\” may be treated as an escape character by the tools. For example, if you have a prebuild event like the following:
cl /c /Fo"$(IntDir)" "$(ProjectDir)\win32.cpp"
The command line will be: cl /c /Fo"Debug\" "C:\foo\win32.cpp" instead of cl /c /Fo"Debug\\" "C:\foo\win32.cpp"
To fix the issue, add an extra “\” in the value passed to /Fo (C/C++ -> Output Files -> Object File Name) so to compensate the escaping.
(1) is an issue that we have decided not to fix for this release but may fix it for future releases. (2) seems to be a limitation on the nmake tool and we may not fix it even for future releases since the workaround is easy.
Li Shao, MSFT
Li Shao [MSFT] - 04 03 10 - 07:58
"If that's the only thing you're concerned about, the Intel compiler is a far better deal."
Yes, but I mean, what is your plan for intrinsics after you upgrade to VS2010 from VS2005?
Yuhong Bao (link) - 04 03 10 - 11:55
Thanks for the info -- I've actually seen the blog post, and it's a pretty good one. Hopefully some of this information makes it into the RTM README.
> (2) seems to be a limitation on the nmake tool and we may not fix it even for future releases since the workaround is easy.
I'm afraid I don't understand. The backslash escaping behavior that NMAKE is showing is in fact the same behavior that your very own C runtime library performs, so a large variety of command line tools that rely on argc/argv parsing will have this problem.
> Yes, but I mean, what is your plan for intrinsics after you upgrade to VS2010 from VS2005?
Don't really have one, really, since I'm not too dependent on intrinsics. Besides, I don't know when I'm going to upgrade to VS2010. It's not a "must have" for me and I could probably stay on VS2005 for a while.
Phaeron - 04 03 10 - 15:30
Thanks you Phaeron. Yes, for next release, to resolve some issues due to escaping, may be we should consider appending "\\" instead of just "\" for $(IntDir) and $(OutDir).
Li Shao, MSFT
Li Shao - 05 03 10 - 10:37
At people from Microsoft reading this:
I can only side with Avery regarding help system. I disliked help showing MFC results for Win32 API calls and macros. I also disliked slow index rebuilding when help files are added or removed to/from collection. I dislike even more the idea of running local web server for help system, that just screams of potential exploits and security vulnerabilites.
I really miss good old CHM format, and regarding font rendering, I miss fullscreen command prompt in 64-bit Windows.
Igor Levicki (link) - 08 03 10 - 08:12
Well, so far I can only say I'm disappointed.
I got the ISO from their website, chose custom install, selected only VB.net, C# and C++ and had to restart the computer two or three times just to install it...
But that's not the bad part... the bad part is each time i go "File > New > Project" and try to create a new C# windows application or vb.net application it just fails saying the cryptic message "Error writing the project file. Class not registered." Creating a new C++ console application works, so I don't know what to say... and the only solution I found MS's site was to empty the event logs but that didn't solve anything.
I think my problem may be the fact that I installed the Beta 2 version a couple of weeks ago (i think) and uninstalled it just as fast, after a couple of days.
Anyways, tried reinstalling the whole thing - won't help.
marius - 09 03 10 - 00:08
Cross-pollution between beta 2 and RC is very possible. I recommend doing the following: uninstall everything VS2010 or .NET 4 Framework related, then wipe all VS2010/VC10 registry keys and directories in the user profile. That'll give you a much better shot at a clean install.
Phaeron - 09 03 10 - 16:00
It is RTM now.
Yuhong Bao - 15 04 10 - 15:56
Following up on my F1 help complaints and the claim that VS2010 would fix them:
VS2010 didn't fix anything. If anything, it's made things worse. (And I'm not even talking about the rushed release where the help system was unfinished so we were fobbed off with the PoS web-browser-based help with no index.)
After creating a straight Win32 EXE project in VS2010:
1) F1 on ::GetMessage opens a web browser showing help on Microsoft.Practices.EnterpriseLibrary.Validation.GetMessage, whatever the **** that is. Nothing to do with Win32 ::GetMessage.
2) F1 on ::BeginPaint opens a web browser showing help on (ATL) CWindow::BeginPaint for VS2008. Wrong framework. (The IDE knows I'm not using ATL and ::BeginPaint wouldn't be CWindow::BeginPaint even if I was. Wrong version of Visual Studio, too.) Wrong version of Visual Studio, too. (Surely the IDE knows which version of itself I'm using? Yeah? You'd think...)
3) On top of that, the CWindow::BeginPaint page has a link to ::BeginPaint in the SDK, except the link is broken and goes nowhere.
Brilliant work, Microsoft. Absolutely outstanding.
It's not like API help is a major part of an IDE or something you should try to get right, nor like this has been getting worse and worse for the last 10 years.
Leo Davidson (link) - 24 09 10 - 23:33
4) F1 on WM_CREATE takes me to Microsoft.VisualStudio.NativeMethods.WM_CREATE rather than, well, I don't know, crazy idea, but maybe WM_CREATE.
5) VS2010 keeps auto-completing to *A names in a Unicode project. Gives ::SetDllDirectoryA instead of ::SetDllDirectory or ::SetDllDirectoryW. Might as well go back to using a dumb text editor as the IDE is now negatively helpful.
Leo Davidson (link) - 25 09 10 - 01:17