VS Support Policy

As far back as this MS support page goes, Visual studio editions had a 5-year mainstream support period, and since VS .NET 2003 – a 10 year extended support period. In particular, VS2010 mainstream support is advertised to end on Jul 14, 2015.

Now given that MS releases major new VS versions roughly once every 2 years, such a support period can be quite a burden. In my (much, much smaller) organization we don’t bother with backward support at all, we just ask those pesky cry-baby customers to upgrade to our latest version before we even consider checking their bug reports. The logistics of testing and patching multiple versions can admittedly get exhausting – so I would have had great respect to the magnitude of the task that DevDiv took upon themselves when they chose to support 2.5 versions backwards.

If they would have actually done so.

As of ~July 2012, the VS bug submission form in Connect no longer enables even reporting issues with VS versions prior to 2012 (note, I think that was before VS2012 even reached RTM):

Long before that, bugs I filed against VS2010, along with complete, consistent repros, were closed as either not reproducible or fixed – if they happened to be resolved in VS2012.

For all practical purposes, support in VS2010 ended less than 2 years after its release – and less than 1 year after its first service pack release!  In our organization (and I suspect in many others) we don’t even consider upgrading VS before the newest version has had its run, and reached a level of maturity attainable probably only at a service pack release. That leaves us with less than a year of practical support, which is beyond annoying – it borders on fraud.

I should probably post here more details about specific unresolved bugs I reported. Beyond that and the much needed venting, I don’t see much that can be done.

A Day with VS11 Beta – part 1

A large chunk of our customers still use XP so we won’t be upgrading VS any time soon. Still, out of curiosity I spent some free time with the VS11 Beta and below are some bits and pieces I noticed that I (mostly) haven’t read elsewhere.

Bug Fixes

I’m sure there are plenty, but MS doesn’t make the full list public (please join me in trying to fix that). I can say that two minor bugs that bothered me are indeed solved and one isn’t. Also, MS finally solved a major-ish issue I reported that prevented using STL containers on aligned elements. This last fix opens up some serious potential optimizations – I’d finally be able to make our matrices 16-byte aligned and apply SSE to them.

UI enhancements

I agree that the colorless GUI and ALL-CAPS-TITLES do not increase productivity, and I hope the options dialog does become resizable one day, but by and large I don’t understand the heat of this discussion .  Maybe it’s the most heavily discussed aspect of every new version just because it’s the most widely accessible aspect. Maybe it’s just fertile ground for MS-bashers – covering the entire range from ‘why did they change the GUI, I can’t find anything now’ up to ‘they just slapped some new GUI around the same product’.

Here’s a thoughtful little addition to the UI: the Project Properties dialog now includes an ‘All Options’ sub-category, for most property categories (C/C++, Linker, etc.):

I didn’t think of it until after seeing this addition, but it entails some deep usability analysis. It probably seemed like a good UI practice to divide the jungle of compiler/linker switches into digestible-size categories, but in practice I often find myself wasting time looking for a single familiar option within inevitably vague categories.

They might have gotten a bit carried away, though.. :

Here’s another nice addition to the editor context menu:

Well, it will be nice when it actually works, anyway. In the mean time /showincludes does the work for me.

Editor enhancements

There are a ton of those – in syntax coloring, code completion, reference highlighting, code snippets and more, but I use the almighty Visual Assist extensively and the native IDE still has a way to go to catch up with it.

Debugger Enhancements

New debugging scenarios are now supported, and the visibility of different debugger configurations is vastly improved:

I didn’t experiment with any web/GPU debugging myself yet, but these do seem promising.

I do get a fair share of optimized builds debugging, and so had high hopes from the new advertised PDB improvements, that allow watching more variables and stepping into inlined functions in release builds.  So far, I have very little to write home about:

The vast majority of local variables (probably all those which are stored only in registers) are still un-watchable.  The ‘Variable is optimized away’ message is a nice direction, but still appears very sporadically. It doesn’t show in the screenshot, but I had no luck stepping into inlined functions too.

Next time…

The part I care most about are compiler enhancements, and specifically the auto vectorizer. More on that –in the coming post.

QuickTip: Toggle disassembly with Ctrl+F11

Short post today. For a long while I’ve been switching to disassembly with Alt+8, as appears under the Debug/Windows menu:

- and back with Ctrl+Alt+0, as appears under View menu:

A while ago I discovered there’s a more pleasant shortcut, usable for both directions: Ctrl+F11, which is the default assignment to the IDE command Debug.ToggleDisassembly.

Happy disassembling.

Microsoft’s Known Issues Policy

As far as I can tell, there isn’t anything there you might seriously call a policy.

Well there is an old ‘knowledge base’ searchable either via a solution center or technet. It includes, however, only known issues that MS support personnel have already encountered and resolved or (mostly) worked around.

There are various MS-maintained forums and communities, in which MS devs are often active, but MS devs certainly do not initiate any discussions on open issues there.

There is connect – which is a great initiative by itself, and which I personally use a lot. It includes, however, only bugs that users have reported. How many are these? Well, Pat Brenner recently wrote that -

[MFC 11] Fixed over 220 bugs, nearly 100 of which were reported by customers via the Connect web site

So extrapolating it seems fair to assume that most of the known bugs at any given time are not reported by users, and developers are forced to re-discover them time and time again.

MS actually seems quite behind on industry-standard issue disclosure policies: I can’t find serious release notes or other form of known-issues-list anymore. There was something for 2005 express editions, and a blog post for 2010 Release Candidate. But nothing serious and official about any professional versions.

 

 

So, I’ve made a suggestion at the Visual Studio UserVoice site:

[…] I’d love to see a live, public repository of known issues, updated with their triage results and expected resolution (if any).

Some examples:

https://bugzilla.mozilla.org/


http://bugs.sun.com/bugdatabase/

Beyond the potential saving in developer frustration, MS might gain valuable insight into impact and prioritization of known issues, which you might want to consider, e.g., when planning service packs.

Of course all the above does not hold for security bugs.

If you agree, please take a minute to vote this suggestion up. If not – I’d love to hear why! Please comment and explain.

$(TargetDir) Bug, or: Where Did My PDB Go?

Edit: This is now a confirmed VS bug. Hope the Connect page would be updated when it is resolved.

---

Try this (if you weren’t bitten by this issue already):

1. Create a new C++ project – any project type will do – at a volume other than your VS installation, say under D:\code.

2. Open its property pages, and under Configuration Properties\ General\ Output Directory, type exactly: \bin\

3. Go to Linker/Debugging and inspect the PDB location. It gives the innocent looking: ‘$(TargetDir)$(TargetName).pdb’. Now edit it and expand the Macros pane to dig deeper:

Your PDBs are all going to be generated at a drive different than the project’s (and thus, probably different than where you intended).

This is definitely new to VS2010, and calls for a deeper peek. Turns out the calculations of these macros are visible, at %PROGRAM FILES% \MSBuild\ Microsoft.Cpp\ v4.0\ Microsoft.CommonCpp.targets:

<TargetPath Condition="’$(TargetPath)’ == ”" 
   $([System.IO.Path]::Combine($(ProjectDir),$(OutDir)
   $(TargetName)$(TargetExt)))
</TargetPath>  
<TargetDir Condition="’$(TargetDir)’==”"
   $([System.IO.Path]::GetDirectoryName(‘$(TargetPath)’))
</TargetDir>

This format is quite readable as pseudo-code, and brief C# experiment shows that this code on the inputs above still gives the relative path ‘\bin\’ for $(TargetDir).

System.Io.Path documentation says:

Relative paths specify a partial location: the current location is used as the starting point when locating a file specified with a relative path.

‘Current location’ is the location of the running executable – unless a different directory is explicitly set. Since the full path ‘C:\bin\’ is displayed at the expanded macro page, I suspect somewhere VS runs GetFullPath over the result of the Microsoft.CommonCpp.targets code, resulting in a path on the volume of the VS installation.

I can’t verify any of it, but a while ago I opened an MS Connect issue about it, which seem to have received little attention from MS till now (can’t say I blame them – they seem to be bombarded recently with bogus issues). I’ll update in this blog if any new info is available.

Slides from the Windows Developers User Group Meeting

Thanks goes to everyone who attended! As promised at the meeting, I’ve uploaded the presentation.

The slides by themselves are rather thin, as almost the entire meeting was spent in visual studio. However, I left out various syntax details – so the links in the slides may be of value to whomever is interested.

I hope to find the time and energy to record (at least partial) screencasts of the presentation. You’re very welcome to comment or email me (ofekshilon at gmail) stating which of the presentation subjects you’d like to dig more deeply into.

"The solution appears to be under source control", or: How P4 messes up MSSCCPRJ.scc Location

For a long while we faced an annoying issue with source control binding:  we’d load some solution and this would pop up:

We’d then fix it using File/Source control/Change source control/Bind:

 

And all seemed well – until we loaded the solution again, only to be greeted by the same error message.  We’d fix it again, load again, ad infinitum.

Googling around didn’t shed too much light. The p4 binding mechanism isn’t well documented (although where p4 lacks,  StackOverflow steps in). Someone described what might be a similar issue, but didn’t get any answers.

MSSCCPRJ.SCC

- is a text file that holds the actual binding info: the mapping of disk locations to source-control locations. (Note: strictly speaking, the binding info can be encoded inside sln/proj files, but it’s bad practice. The choice of binding location is controlled via a separate file – more in a future post).

When I search my disk for MSSCCPRJ  I find dozens (!) of instances scattered throughout my source folders, with contents similar to:

SCC = This is a source code control file

[yadda.vcxproj]
SCC_Aux_Path= "P4SCC#serverrnd:1666##Ofek##OfekPC"
SCC_Project_Name = Perforce Project

[yaddayadda.vcxproj]
SCC_Aux_Path= "P4SCC#serverrnd:1666##Ofek##OfekPC"
SCC_Project_Name = Perforce Project

…

MSDN lists some specifications the file must adhere too, but leave unspecified its location and scope – that is, the number of projects it describes and their relative-location-on-disk – and here exactly lies a loose end of the p4/VS integration. p4 knowledge base half-admits it:

- Use a Single Solution Model whenever possible. The Single Solution Model uses one .sln file as a container for all of the projects defined by your application

- Use a Consistent Folder Structure for solutions and projects. Ideally, keep solution files in the top directory and all of the projects in subdirectories.

These less-then-precise advice probably mean: avoid a state where a solution includes a project that does not lie below it on disk/source-control. This seems impossible to adhere to in real-life situations (how would you recycle libraries?), and is probably the indirect cause of the MSSCCPRJ mess.

The Problem

The direct cause is a discrepancy between the disk location where p4 places MSSCCPRJ during project bind, and the disk location where it searches MSSCCPRJ during solution load.

If you bind several projects simultaneously, seems p4 persists the binding info into an MSSCCPRJ at their common ancestor on disk. E.g., if you simultaneously bind D:\code\proj1\proj1.vcxproj, D:\code\proj2\proj2.vcxproj and  D:\code\proj3\proj3.vcxproj, the MSSCCPRJ would be generated (or modified) at D:\code. However it seems that during solution load, if p4 uses MSSCCPRJ at D:\code, it would never look for other MSSCCPRJ under D:\code subfolders.  So if, for example, some day you bind the single project D:\code\proj4\proj4.vcxproj, an additional MSSCCPRJ would be created at D:\code\proj4, and never be used during solution load, no matter how many times you re-bind the project using the change source control dialog.

The Solution (well, more like a workaround)

Just bind your projects individually. i.e., instead of clicking ‘bind’ on multi-selection:

 

Repeatedly bind a single selection:

and separate MSSCCPRJ files would be created at every project folder. It can be a hassle for large solutions (I should know – I applied it to ~100 project solutions), but it’s a one-time hassle. For me, that seem to have solved the issue completely.

NOTE: we’re using Perforce 2007.1 and the issue may have been resolved since – although I find that improbable, as the issue seem to persist in the p4 knowledge base. The reason we’re not upgrading is that we’re migrating to TFS instead, and I can’t say I’m too sad about that.

‘Internal CPS Error’ When Adding A Project Reference

Edit: This is now a confirmed VS bug.

Occasionally I get this -

- when trying to add a reference from one project to another in VS2010. I’ve no idea what CPS is and what shim object they’re talking about, but I’ve discovered a hack around it.

Suppose you’ve encountered this error when trying to add a reference from projectA to projectB. Albeit cryptic, the message distinguishes an actual project reference (which VS found), from some internal representation or (more likely) satellite object, the shim object – which is missing.

To resolve this discrepancy edit projectA.vcxproj (you can unload projectA, right click it and choose ‘edit’, but notepad would do just fine). Locate and delete the lines that encode the existing reference to projectB:

…
<ProjectReference Include=”..\projectB\projectB.vcxproj”>
<Project>{66d572b3-b340-47dc-94fe-93515aebaaf4}</Project>
</ProjectReference>
…

The discrepancy is fixed. Reload projectA in VS and merrily add the reference to projectB.

_VC80_UPGRADE and Warning RC4005 (IDR_MANIFEST Redefinition)

The _VC80_UPGRADE macro seems to cause some confusion around, as does the warning -

'warning RC4005: 'IDR_MANIFEST' : redefinition.'

While it was tempting to try and smear these issues on two posts, fact is they are one. A disk search finds a single reference to both, at afxres.h:

#if defined(_VC80_UPGRADE) && (_VC80_UPGRADE >= 0x0700) && (_VC80_UPGRADE < 0x0800) && defined(IDR_MANIFEST)
  // Handle project upgrade from VC7/VC7.1 for projects with manifest
  #define IDR_MANIFEST    1024
#endif

Which still doesn’t remotely pass as documentation. The closest I could find is this Connect reply:

We left this warning deliberately. Our upgrade support manages to make sure that your old project’s manifest doesn’t clash with the manifest that our tools now insert automatically. Our upgrade conversion warns you of this in its conversion log. However, this compile-time warning serves as a reminder that you should remove the manifest entry from your .rc file. When that’s done, you can undefine the _VC80_UPGRADE symbol.

The relevant conversion log snippet, quoted in the connect entry, is somewhere between obscure and misleading:

Due to the requirement that Visual C++ projects produce an embedded (by default) Windows SxS manifest, manifest files in the project are automatically excluded from building with the Manifest Tool. It is recommended that the dependency information contained in any manifest files be converted to “#pragma comment(linker,”<insert dependency here>”)” in a header file that is included from your source code. If your project already embeds a manifest in the RT_MANIFEST resource section through a resource (.rc) file, the line will need to be commented out before the project will build correctly.

Here’s what I make of it all – and this isn’t anywhere near official, so tread with caution.

Conjecture 1: In VC versions from 0×700 (inclusive) to 0×800 (non inclusive), embedding external manifests via resource scripts was either automatic or encouraged (certainly supported) as a way to declare dependencies upon specific assembly versions. From VS2005 (VC 0×800) onwards, the manifest tool automatically generates and embeds such manifests into the built binaries.

Conjecture 2: Judging by the conversion log (‘If your project already embeds a manifest in the … rc file, the line will need to be commented out before the project will build correctly’) , the project upgrade wizard didn’t handle well the conversion of the RT_MANIFEST resource section. Judging by the Connect response (‘Our upgrade …manages to make sure that your old project’s manifest doesn’t clash…’) the upgrade wizard probably did a good job, but for whatever reasons preferred not to delete the RT_MANIFEST section itself.

If you put your heart into it you might reconcile these two phrasings (maybe by ‘build correctly’ they mean with no warnings? Maybe they just made sure the manifests ‘didn’t clash’, but couldn’t decide which was correct?). Doesn’t matter – one way or another MSFT didn’t feel comfortable with auto-upgrading the RC-manifest and sought ways to encourage you to look into it in person.

Conjecture 3: Setting _VC80_UPGRADE to 0×700 and duplicating the definition of IDR_MANIFEST is just MSFT nudging you to peek into your old .RC script, confirm the choices the auto-update made and delete the entire RT_MANIFEST section when you’re done.

If any of this is true (which I can’t verify), it is a weird, weird hack by the VC team. At the very least I would expect some guidance near the (deliberate) warning origin. Even an informative comment – anything more than ‘Handle VC7.0 upgrade’ would be nice – but why not customize the warning?

#if defined(_VC80_UPGRADE) && (_VC80_UPGRADE >= 0x0700) && (_VC80_UPGRADE < 0x0800)
  #ifdef IDR_MANIFEST
#pragma message("We have reason to believe you are using a custom manifest as an embedded resource. Are you? Please don't. Really. The build process now generates and embeds a manifest automatically and there are better ways to guide it if you must. (Although try not too. It tickles.)")
  #endif
  #define IDR_MANIFEST    1024
#endif

Some Concrete Suggestions

If you did see ‘warning RC4005: ‘IDR_MANIFEST’ redefinition’, don’t ignore it. Inspect your project’s RC file – and specifically the RT_MANIFEST section. If it doesn’t contain any meaningful dependencies – erase it and be done with it. If it does hold some assembly references that you decide you want to keep – migrate them to some modern means: either #pragma comment(linker) as the conversion log suggests (I can’t think of a scenario where that’s the better way, but who knows), or use the /MANIFESTDEPENDENCY liker switch – either at the command line or via project properties, at Linker\Manifest File \Additional Manifest Dependencies.

Whether you saw the warning or not, whether you did migrate manifest settings or not, the _VC80_UPGRADE macro is now just clutter. It arrived at your projects via an added property sheet reference, and the civilized way of clearing it is via View\Property Manager:

The screenshot is from VS2010, and of clearing some embarrassing upgrade clutter from VC6.0 (!). Oh well, better late.

Child Breakpoints in Visual Studio

You often see in the breakpoints window that certain breakpoints are expandable:

These are called child breakpoints, and are a strong contender to the title of most poorly documented feature of VS.  According to MSDN, child breakpoints occur -

…when you set a breakpoint in a location such as an overloaded function…

…when you attach to more than  one instance of the same program.

And I’m not sure what they mean by either. AFAIK, a single debugger cannot attach to more than one instance of a program, and different overloads of the same functions reside in different code lines – so they cannot possibly count for child breakpoints.

It’s reasonable to assume that child breakpoints are generated whenever a breakpoint is set in a line of code  that is compiled into multiple binary locations. I’m aware of two such scenarios – but there may be more:

1. Templated function/method instantiated with different arguments,
2. A function in a static library linked into multiple executables (exe, dll) in a single solution.

Perhaps by ‘overloaded function’ MSDN means (1) and by ‘more than one instance of the same program’ they mean (2)?  I sure hope not.  Also, the ever generous John Robbins confirmed the 1st case by email.

It’s good to be aware of this feature because it does have debugging performance implications – In a large project such that I work on, setting a breakpoint in (e.g.) smart pointer code results in spreading INT 3 instructions in thousands of instantiations – occasionally causing full minutes of IDE stall. There are often better alternatives – maybe more on that in a future post.

To make things even more interesting, in VS2005 this feature was badly bugged: more often than not a breakpoint was split into children for no apparent reason. This seems to be fixed in VS2010.