printf(“Hello MSBuild!\n”);

infoblog » printf(???Hello MSBuild!\n???);

infoblog » printf(???Hello MSBuild!\n???); — Fri, 21 Nov 2008 03:41:31 GMT

PingBack from http://blog.a-foton.ru/index.php/2008/11/21/printf%e2%80%9chello-msbuildn%e2%80%9d/

Command-line builds?

Sachin Garg — Fri, 21 Nov 2008 10:06:50 GMT

Will it be possible to do command-line builds using MSBuild without having to write separate make files? That would be wonderful if possible.

Right now, while we love using IDE, the builds need to be automated which needs managing a separate set of make files which are manually kept in sync with project files (painful).

Being able to do command-line builds using the project files would be great, will this be possible using MSBuild?

re: printf(“Hello MSBuild!\n”);

David — Fri, 21 Nov 2008 10:44:08 GMT

@Sachin:

Until VS2010 is released, you can always use VCBuild.exe to build the non-MSBuild .vcproj files. Don't write separate makefiles, for all that is sacred!

VCBuild doesn't pack all the power that MSBuild does, but it definitely allows you to automate your C++ builds today and do some fun and useful things like injecting extra .vsprops files.

re: printf(“Hello MSBuild!\n”);

Sachin Garg — Fri, 21 Nov 2008 10:57:38 GMT

Ouch, can't believe I didn't know about VCBuild. All those lost hours hurt. Thanks a ton :-)

re: printf(“Hello MSBuild!\n”);

Leo Davidson — Fri, 21 Nov 2008 11:23:48 GMT

Any plans to improve the Project Settings GUI? This is still awful in 2008 in that it is not possible to see the settings for multiple platforms (x86 & x64) and builds (debug & release) at once, and requires a lot of clicking when switching between them.

I lost count of the number of times I have found inconsistent settings between builds as a result of this GUI and whenever I have to make changes or create a new project I end up swearing at it.

Improving that would make the new VC worth buying even if there were no other changes!

re: printf(“Hello MSBuild!\n”);

Leo Davidson — Fri, 21 Nov 2008 11:29:39 GMT

...adding to what I just posted: You could improve the Project Settings UI if it showed a grid with the settings for each build type.

At the moment each page has a two column grid with setting name and setting value.

That could be expanded to show a column for each build type instead of a single value column.

It wouldn't matter if a lot of build combinations caused lots of columns and scrolling because that would still be a million times better than the current setup.

Right now you have to click on two drop-downs, and then click "Yes" to apply your changes in a dialog that appears in a different place, to change between build types. You have to remember, or put in the clipboard, each setting and then change types to see if they are consistent based on what you can remember. It's horrible. If we could see all the configurations side-by-side, even if scrolling was required, then that would be so much better.

Locking the name column so that it doesn't scroll out of view might help.

Making the project settings dialog resizable would also help, of course.

re: printf(“Hello MSBuild!\n”);

int19h — Fri, 21 Nov 2008 12:53:14 GMT

> Will it be possible to do command-line builds using MSBuild without having to write separate make files? That would be wonderful if possible.

Well, it's possible today for C# and VB projects, so why wouldn't it work for C++ ones as well?

re: printf(“Hello MSBuild!\n”);

Niels — Fri, 21 Nov 2008 13:44:09 GMT

Will conversion of custom property sheets to MSBuild be supported?

E.g. in a case where you have a ProjectA.vcproj, ProjectB.vcproj etc. using multiple common property sheets tailored to your specific needs such as Libraries_x86-32_Debug.vsprops and Libraries_x86-64_Release.vsprops etc.

re: printf(“Hello MSBuild!\n”);

Brian Tyler — Sat, 22 Nov 2008 00:03:35 GMT

@Leo

The property page UI is pretty much the same in VS2010 and VS2008. I'll agree that there is a lot we can do to improve the experience - both for basic and advanced scenarios (which is always the rub). However, I'm a little confused by your comment that you can't multi-select. If you go into the Configuration or Platform dropdowns, you'll see All Configurations/All Platforms (unless you have 3 or more, in which case you also get Multiple - where you can pick).

The UI then only shows the values that are the same for all the selected configurations.

@Niels

Yes, the project upgrade wizard and the command line upgrade tool both handle property sheets. The Property Sheet concept is a very central idea in the concept of the project system.

re: printf(“Hello MSBuild!\n”);

msbuild — Sat, 22 Nov 2008 03:00:16 GMT

@Sachin

> Will it be possible to do command-line builds using MSBuild without having to write separate make files? That would be wonderful if possible.

Yes, that's one of the main principles of MSBuild, that you get the exact same build process on the command line, without Visual Studio installed.

Dan

re: printf(“Hello MSBuild!\n”);

Jalf — Sat, 22 Nov 2008 03:43:20 GMT

"Parallel builds - multiple projects build in parallel both in the IDE and on the command line"

So what about building translation units within a project in parallel? Is that feature going to be removed?

re: printf(“Hello MSBuild!\n”);

jon — Sat, 22 Nov 2008 05:51:45 GMT

@Brian: Regards Leo Davidson's comment, I would like to chime in with a +1.

At the VERY least, even if you're not going to change the interface of the Project Settings, PLEASE make the dialog resizeable!

And yes you can view the common properties of multiple builds simultaneously, but I believe what Leo is asking (and what I would like to see) is a way to see all properties (common and otherwise) simultaneously in a grid-format.

re: printf(“Hello MSBuild!\n”);

Marian Luparu [MSFT] — Sat, 22 Nov 2008 13:16:37 GMT

@Jalf: So what about building translation units within a project in parallel?

cl.exe /MP will still be supported - we are finally adding it as a property in the Property Pages rather than asking you to pass it as an Additional Options. Also, the number of cores you want to spend on /MP will be configurable from Tools/Options. Depending on your projects organization, you will continue to have the choice to mix and match both techniques of building in parallel (file-level and project-level).

re: printf(“Hello MSBuild!\n”);

Leo Davidson — Mon, 24 Nov 2008 15:02:45 GMT

@Brain: As Jon suggests, seeing the common settings for different projects isn't enough.

Consider a C++ Debug and Release project. You want to add a pre-processor definition, or you want to add an additional link library. (Or you just want to compare the two to see if they are consistent).

Those two things will almost always be different between a Debug and Release project.

With the pre-proc definitions you'll always have DEBUG defined for one and NDEBUG for the other.

With the link libraries you'll often have some debug-only and release-only link libraries (e.g. for components you have the source code to which provide you with debug versions) while other libraries will be release-only (3rd party libs).

In both cases, and several others, the result is that you just get a blank field (or a message saying the settings differ by project; I forget) if you select both Debug and Release configs.

As well as not being able to see and compare the settings side-by-side, there is no way to edit the settings in one place.

To compare the two configs you have to keep flicking between them which takes far too many mouse clicks and requires you to keep long, cryptic lists of symbols, library names, etc. in your head.

I have lost count of the number of times I've discovered inconsistent settings between configs as a result of this.

It's like a memory game rather than a GUI designed for speed and accuracy.

This is made even worse by having x64 and x86 projects since you now have four different project types, each with their own differences from the others (yet with commonalities as well). The GUI is so bad at this that I sometimes end up editing the project settings in a text editor instead.

I am just thankful that x64 became important around the time that ANSI builds became unimportant, else there would be eight configs to worry about instead of four!

If the settings were shown in a grid then that would solve it.

Or at least make it quicker to switch between configs after making changes to the current one. i.e. It should be one click, on a list of configs that is always on screen, no drop-downs and no confirmation dialogs.

Or make if so that you can open several project settings dialogs and view & edit different configs side-by-side that way.

Lots of ways to solve the problem which would be a million times better than what we've had to put up with for some many years in the current design.

(And, as Jon also said, making the dialog resizable is badly needed as well. It is so frustrating that it doesn't size when it is so normal to be dealing with long values in some of the fields.)

I should stress that I love Visual Studio. It's just this particular bit of if that I hate and find inexplicably neglected in terms of GUI design.

re: printf(“Hello MSBuild!\n”);

Dimitris Staikos — Mon, 24 Nov 2008 17:32:17 GMT

Since your primary interest is the MSBUILD process, I would request another feature (that is, in case it is not present):

Let us troublelessly build Device Driver projects.

We have the BUILD.EXE from DDK, with its own bunch of rules, macros, makefiles and various build 'environments' making it a herculian feat to batch-build all targets and platforms from the same shell window. Most people end up using OSR's DDKBUILD.BAT to get through the build process without brain damage. Please save the day!

Then let's get back to project settings...

PPPppplease... Fix the project settings dialogs. They are a source of constant pain and frustration. I realize that it is a very difficult UI problem because there are 3-degrees of freedom (build type, platform, setting), but I assume you have access to some internal UI experts to give you better advice. Have someone 'sane' propose some UI designs, someone that is not a developer ;-) someone from the Office team for example.

I have the following feature suggestions with regards to settings:

(1) Let us enter comments to explain project settings.

(2) Let us verify the value of settings through preprocessor definitions/macros.

This way I can have a dummy source file that simply checks for the correct values in some crucial options and thus make sure the build is sane. Moreover I could have various such files that get added on every project (depending on the type of project) to make sure for example that all my DLLs and EXEs for example use static CRT linking.

People go to great extents to solve some weird build issue through project settings, and one year later noone remembers what some obscure setting was needed for (e.g. we have a DLL with optimizations disabled in release build).

I filed the comments request in MS connect and after several weeks of serious thinking the item was closed with the response "You can enter XML comments in the VCPROJ file".

Man! What a breakthrough! I can enter a comment where noone can see it! And what was I supposed to be doing afterwards? Every time I want to change a setting open up the VCPROJ in a text editor to see if I have entered any comments???

Warm Regards

re: printf(“Hello MSBuild!\n”);

swn1 — Mon, 24 Nov 2008 17:42:52 GMT

"The UI then only shows the values that are the same for all the selected configurations."

Actually, it displays the values that are different the same way it does the ones are are all empty: as an empty string. You can't tell the difference between multiple non-default values, multiple default values, all empty by default, and all overridden empty.

Bogus. Extremely bogus.

re: printf(“Hello MSBuild!\n”);

Dan — Mon, 24 Nov 2008 21:49:26 GMT

I'll let the owner of the property pages dialogs speak to the feedback about them directly.

However, as the MSBuild owner, I can say that moving to MSBuild means that the file format is fully documented and supported, that Visual Studio is expected to handle whatever structure you create and whatever content you put in there, and that there will be a comprehensive, rich new object model over it.

(This will replace the object model MSBuild currently has, which has many deficiencies.)

So regardless of what the dialog supports in VS10, there will be plenty of opportunities to write powerful custom tools over the project files and property sheets to display in any format and allow any kind of editing: perhaps 3rd parties will create some.

Dan

re: printf(“Hello MSBuild!\n”);

David — Mon, 24 Nov 2008 22:04:06 GMT

@Leo:

> I lost count of the number of times I have found inconsistent settings between builds as a result of this GUI and whenever I have to make changes or create a new project I end up swearing at it.

I have found that Property Sheets (.vsprops files) are a great help when the number of projects, platforms and configurations increase. Instead of specifying lots of settings on the project level, I try to refactor the settings into a few .vsprops files (e.g. Debug.vsprops, Release.vsprops, X86.vsprops, X64.vsprops) and leave the .vcproj files to all defaults, inheriting everything from the property sheets. That's it, not a single entry in bold in the project properties (or at least very few). It takes some time initially to find the optimal structure, but once you have organized all settings into a few .vsprops files, you are less likely to end up with the inconsistencies that you describe.

I hope that VS2010 keeps improving on this feature, because I find it invaluable for big multi-project solutions. For example, source control integration is not great for .vsprops files in VS2008.

re: printf(“Hello MSBuild!\n”);

Aaron — Thu, 27 Nov 2008 01:17:53 GMT

since it supports native multi-targeting can you add support for the Visual C++ 1.52 compiler so we can compile our 16-bit applications without having to be on a Windows NT machine?

re: printf(“Hello MSBuild!\n”);

jon — Fri, 05 Dec 2008 16:21:29 GMT

"I'll let the owner of the property pages dialogs speak to the feedback about them directly."

I'm not noticing a whole lot of feedback from this person as yet :)

.vsprops

Jean-Marc — Sat, 06 Dec 2008 13:31:28 GMT

Since we found this feature in VS2005, project-setttings-hell has been a bad memory from the old days. Comes in handy if you have a multi-million C++ code base with hundreds of .vcproj files. So in our opinion, MSBuild should support the .vsprops.

Project filters

Martin Filteau — Mon, 08 Dec 2008 17:45:55 GMT

I'm wondering why the filters are in a separate *.vcxproj.filters file.

Wouldn't it be easier to keep this information in the *.vcxproj itself under the <ProjectExtension> node?

MSBuild Task

Visual C++ Team Blog — Tue, 16 Dec 2008 20:12:27 GMT

Hello again! My name is Li Shao. I am a Software Design Engineer in Test in the Visual C++ group. As

VC MSBuild Extensibility Example

Visual C++ Team Blog — Thu, 02 Apr 2009 01:02:16 GMT

Hello, my name is Felix Huang and I am a developer on the Visual C++ team. Over the last year, I worked

Visual Studio 2010 New Features, Extensibility Points and Partner Opportunities

Visual Studio, VSIP Partners and more ...... — Wed, 20 May 2009 01:52:00 GMT

As part of my role in working with partners in the Visual Studio Industry Partner (VSIP) Program I have

Bogdan Mihalcea: The New VC++ Project/Build system - MSBuild for C++

ComponentGear.com Feed — Thu, 18 Jun 2009 21:54:04 GMT

Bogdan Mihalcea is a developer on the VC++ build and project system team. He and team have been very