Follow up On Feedback From Beta1 and DevLab About VC Project Conversion’s Performance

re: Follow up On Feedback From Beta1 and DevLab About VC Project Conversion’s Performance

Roger Lipscombe — Sun, 07 Jun 2009 11:04:02 GMT

Some of our older projects suffer from high numbers of per-file configuration settings. As you suggest, I suspect that this is because they've been manually tweaked over the years, and have been through successive upgrades (e.g. from VC5 all the way to VS2008).

I wonder if, when VS2010 is done, someone could find some time to write a VS PowerToy to make it easier to look at these and maybe remove the incorrect per-file configurations? ;-)

Nice

QbProg — Sun, 07 Jun 2009 22:44:00 GMT

Yes, in fact the conversion was really slow. But as you said, it was a one-time tax, so it really doesn't matter!

Woow going down from 1h,40 to 20secs ! There should have been a real bootleneck! :)

CMFCOutlookBar::LoadState() bug

cppboy — Mon, 08 Jun 2009 08:40:02 GMT

"lpbData" uses array new operator to allocate memory in CSettingsStore::Read(), but it uses free() to free memory.

Sorry, I don't know where to report the bug ^_^

re: Follow up On Feedback From Beta1 and DevLab About VC Project Conversion’s Performance

SvenC — Mon, 08 Jun 2009 08:56:32 GMT

Hi cppboy,

please use http://connect.microsoft.com/VisualStudio to report bugs and suggestions

SvenC

re: Follow up On Feedback From Beta1 and DevLab About VC Project Conversion’s Performance

David McCabe — Mon, 08 Jun 2009 10:46:38 GMT

More important for us is to be able to identify which files have file-level settings. Consistency is very important for us, and I would like to be able to set options for all projects, and be able to identify which projects and files override these settings - such that I can get a report, probably from msbuild, which settings are different.

re: Follow up On Feedback From Beta1 and DevLab About VC Project Conversion’s Performance

S. Colcord — Mon, 08 Jun 2009 19:33:14 GMT

It's always interesting to hear about fixes that yield 2+ orders of magnitude improvement in performance. Can you elaborate on what the key change was?

Detecting un-clean and clean projects

Greg — Mon, 08 Jun 2009 22:38:59 GMT

We would appreciate any help in detecting any different projects and file level settings in a multi-project C++ application solution.

Our goal is to use the same project level settings for all projecs in the solution. We would also like to not use any file level custom settings.

We want to be able to answer the basic question:

Will this project build from an arbritrary directory on a machine with VS version 2010 without any extra manual tweaking?

We want to detect and avoid things like:

- hard coded paths to DLLs, projects, solution files, h files, c++ files

- custom pre and post build steps

- reliance on multiple copies of the same file (H or dll) in different subdirectories of the same project

Some real world cases we've seen:

- Developer creates mapped drives Q:, R:, S:, etc and then hard codes them to different projects (e.g., all gui dlls are on the Q: drive). This is a poor attempt at providing location independence. We want to start each project at a root directory (e.g., c:\dev\abc) and the have all files for that entire solution in that directory outside of builtin win32 OS dlls, .net BCL DLLS, etc.

- Have multiple projects in a solution divided out for purposes of TDD unit testing only with duplicate copies of the same DLL and H files in different directories. We want to combine the projects in a large solution to remove the overhead of managing multiple projects, take read advantage of whole program optimization and greatly reduce the number of files in our source and installation.

- Developer links in several open source dll files into an application to use a small portion of the functionality because they want to use a particular coding style (e.g., object relational mapping DLL created from 50,000+ lines of C++ that is used only to store/retrieve a simple 5 object structure). That extra code adds significant risk and maintenance time to a large project as the benifit of using it is tiny when compared to the risk of adding 50,000+ extra unknown lines of code to our application.

re: Follow up On Feedback From Beta1 and DevLab About VC Project Conversion’s Performance

vcblog — Wed, 10 Jun 2009 00:58:33 GMT

Hello cppboy

As SvenC correctly suggests, please use http://connect.microsoft.com/VisualStudio to submit a bug on this. On a quick look at our current codebase we cannot see this issue, so please supply as much detail on your configuration as possible.

Thanks

Damien

re: Tool to compare project settings

Chris Oldwood — Fri, 12 Jun 2009 13:30:40 GMT

Greg,

I wrote a tool for comparing vcproj settings, it's free and available on my web site here - http://www.cix.co.uk/~gort/win32.htm#VCProjCompare.

It won't show file level overrides, but it's on the TODO list :-)

re: Follow up On Feedback From Beta1 and DevLab About VC Project Conversion’s Performance

Amit Mohindra [MSFT] — Mon, 15 Jun 2009 04:44:11 GMT

Hi Greg,

Thanks for sharing feedback and suggestion on this blog. These are really good suggestions and we recognize the value that such tool would provide to the C++ developer community. Unfortunately we would not be able to deliver this functionality in the box. If you are interested you could start a community project on CodePlex and we will try to help out by contributing to this effort.

You can contact me directly at amitmo at microsoft dot com to discuss this further.

Thanks,

Amit