How would you spend $100 on MSBuild?

Artikel
11/17/2007

We're currently planning for our next version (aka, "Dev10" - no code name this time) and subsequent releases. In that spirit, I'd like to do a quick poll of MSBuild aficionados to help us keep our "vision" for MSBuild aligned with yours, our customers.

First, a caveat - while ideally I would like to rank the results and work down the list, the reality is that we have other constraints: although we are a separate build platform, our biggest customer by far is Visual Studio and its customers. There's a lot more Visual Studio users than direct MSBuild users, so when Visual Studio needs to add a feature that requires work on MSBuild, we have to help. Then there's other constraints, like team resources. There's no guarantee which of these will appear in what version, and some of them may not be worth any investment. Some of them I just made up.

OK. Here’s some brainstormed features. Some of them are properly Visual Studio features, but they overlap closely with build:

1) Higher performance multiprocessor support. For example, we suspect there is plenty of room to improve the scheduling we do, and find speedups elsewhere in the code. As more and more of us have multicore machines, this might be a good place to invest.

2) VC support. This means converting VC projects (.vcproj) to MSBuild format, a customizable and extensible build process entirely defined by MSBuild .targets files rather than in makefiles or built into the VC project system, reuseable tasks for native code tools just like we have today for managed code, changing the VS project system for VC projects to sit on top of MSBuild format projects and build process, and replacing use of vcbuild.exe with msbuild.exe.

3) Support for other Microsoft project types that aren't yet in MSBuild format: Deployment/MSI (.vdproj), SQL Reporting (.rptproj), Biztalk (.btproj), Speech server (.prproj) etc -- whether currently supported by a VS project system or not. This is essentially a process of internal evangelization and encouragement for us.

4) Conversion of Visual Studio solution files (.sln files) and their (rudimentary) build process to MSBuild format and the VS support for reading and writing these, opening the way to create a targets file useful for traversing a tree of projects, and to let VS cleanly support n-level project hierarchies.

5) Extensible up-to-date checking: a way to plug in up-to-date checker extensions that you could use on selected Targets as an alternative to the simple timestamp checking you are currently restricted to. Perhaps including a ready-made extension that would by some means automatically support transitive dependencies - header files are an example of these; or to compare public interfaces for significant changes.

6) Distributed Build. (Like multiprocessor build we are now shipping, but building spread over a set of machines that you have pre-provisioned; possibly opening the way for future Team Build support for it too.)

7) Extensible reuseable inline tasks. This means the ability to create extensions that consume the language or description format of your choice and to create a task that you could use without explicit compilation or deployment. For example, a Powershell extension that you could use to create tasks implemented in Powershell. Think of putting script underneath a <UsingTask> element. These inline tasks would be easy to create and share online. Might include ready-made extensions for Powershell, and/or a data-description format for tool switches, so you could quickly create a task wrapping a command line tool without any compilation.

8) Typing and scoping for items and properties. For example, declaring an item to contain a path; letting a property fall out of scope at the end of a target.

9) Extensible functions. Today we have only 'exists(..)' and it's stepchild 'hastrailingslash(...)'. This would be an extension allowing new functions to be created for use in conditional expressions, and possibly elsewhere, and some functions like perhaps combinepath($(root),$(file)). Perhaps more built-in metadata to go along with %(Filename) and such.

11) An MSBuild debugger with full Visual Studio support for stepping, inspecting locals, and breakpoints. Today you have to use <Message> tasks and gaze at diagnostic logging output.

12) Visualization for project and target dependencies, mining of what files are consumed by what projects, impact analysis for changes to particular files, possibly leading to support for build refactoring at the project/tree level. This is essentially richer logging and datamining and a high level on a huge source tree.

So now here's the poll. If you had only $100 to spend, how would you distribute it amongst them?

Dan

(Edit: gave Distributed build a unique number :-) )

Comments

Anonymous
November 17, 2007
How about spending $80 of that $100 on an MSBuild UI editor ala FinalBuilder. I don't bother using MSBuild for anything beyond the project/solution compilation tasks. Personally, XML is too verbose and annoying to deal with, when there are plenty of better tools out there to achieve the same goals.
Anonymous
November 17, 2007
$35 (#7) Inline tasks: with built-in support for C# and VB $25 (#8) Typing and scoping for items and properties $25 (#5) Extensible up-to-date checking $15 (#9) Extensible functions: with ability to define these using inline scripts like (#7)
Anonymous
November 17, 2007
$30 (#7) - Inline tasks $20 (#3) - Deployment/MSI $20 (#4) - Conversion of .sln $20 (#1) - Multiprocessor $10 (#11) - Debugger
Anonymous
November 17, 2007
$50 (#11) - Debugger $50 (#12) - Visualization
Anonymous
November 17, 2007
#2 - $5 #3 - $30 #4 - $30 #11 - $15 #12 - $20
Anonymous
November 17, 2007
$20 (#1) Multicore speedup $25 (#2) VC Projects $ 5 (#4) Solutions $30 (#7) Internal tasks $ 5 (#9) Internal functions $15 (#12) Build visualization
Anonymous
November 17, 2007
$90 (#2) VC support $10 (#5) Extensible up-to-date checking
Anonymous
November 17, 2007
$50 (#11) - Debugger $50 (#12) - Visualization
Anonymous
November 17, 2007
$50 [#11] - Debugger $25 [#12] - Visualization $10 [#9] - built in functions $10 [#8] - Typing and scoping $5 [#7] - extensible reusable inline tasks
Anonymous
November 17, 2007
#3 #4 #2 In that order.
Anonymous
November 18, 2007
$30 (6) Distributed Build $20 (8) Typing and scoping $20 (11) MSBuild debugger $10 (2) VC support $10 (3) Support for .vdproj $10 (4) Conversion of .sln
Anonymous
November 18, 2007
#2 VC support #1 Higher performance multiprocessor support #4 Conversion of Visual Studio solution files And then better debug and visualisation support
Anonymous
November 18, 2007
The comment has been removed
Anonymous
November 18, 2007
Here's my take. Making the experience of developing, maintaining, and debugging msbuild scripts would be hugely valuable. 12 - visualization - $30 11 - msbuild debugger - $25 ?? - visual editor, navigation (e.g., jump to target or property, symbolic search, navigation) - $20 3 - support for non-msbuild projects - this is extremely important, but as Scott says, it's the other teams that need to do the work 2 - vc support - $20 9 - extensible functions - $5 Buck
Anonymous
November 18, 2007
Dan Moseley, a developer on the MSBuild team , wants to know how you would prioritize features for the
Anonymous
November 18, 2007
$70 Supporting other project types (espec. .vdproj) $30 Interface and built in functionality for manually and automatically modifying assembly versions (and setup proj versions) with each build.
Anonymous
November 18, 2007
Dan Moseley, a developer on the MSBuild team , wants to know how you would prioritize features for the
Anonymous
November 18, 2007
#1 1$ #4 20$ #3 79$, sort of. Would you consider making the internal SolutionParser(name from memory) class (it creates an msbuild proj file in memory that represents the solution) extensible so that when it finds a project it doesn't recognise it raises an event or looks at some plugins to parse said project and create build tasks for it? That may make it easier for your teams to pickup internally and allow people outside microsoft to develop support for project types important to them.
Anonymous
November 18, 2007
$40 - #3 Other Project types $40 - #4 Conversion of .sln files to MSBuild $10 - #12 Visualization for project and target dependencies $5 - #5 Debugger $5 - #6 Distributed build
Anonymous
November 18, 2007
#11 - $60 #12 - $25 #3 - $15
Anonymous
November 18, 2007

Multiprocessor support: $15
Project types: - $30 for Deployment/MSI projects - $5 for Sql Reporting projects
.sln files: $5
Extensible reusable inline tasks: $20
Debugger: $25

Anonymous
November 18, 2007
#12 - visualization - $30 #1 - msbuild debugger - $25 #2 - vc support - $20 #9 - extensible functions - $5 #7 - Inline tasks - $20
Anonymous
November 18, 2007
Dan Moseley, a developer on the MSBuild team , wants to know how you would prioritize features for the
Anonymous
November 18, 2007
#1 - 10$ #2 - 0$ #3 - 0$ (nice to have, tons of work for nothing) #4 - 5$ (nice to have, Abbot time we have it) #5 - 0$ #6 - 10$ #7 - 10$ (Demo driven feature) #8 - 0$ #9 - 10$ #11 - 50$ #12 - 25$ Debugging - 50$ Visualization - 25$ Multiprocessor & Multi machine build - 20$ SLN - 5$ The two most needed features in terms of development is the things that allready exists elsewhere - Debugging & Drag and drop development cycle.
Anonymous
November 18, 2007
#1 $15 #2 $20 #3 $5 #4 $25 #5 $0 #6 $5 #7 $5 #8 $0 #9 $10 #11 $10 #12 $5 To me the most important feature is having all VS projects/solutions work with MSBuild. Performance related features (will be useful for Team Build) come after that. All other things are useful - but only once the above two are implemented.
Anonymous
November 18, 2007
4 - $45 6 - $10 7 - $10 11 - $30 12 - $10
Anonymous
November 18, 2007
#7 - $10 #9 - $30 #11 - $50 #12 - $10
Anonymous
November 18, 2007
#2 $30 #4 $30 #6 $20 #12 $20
Anonymous
November 18, 2007
$100 Make it easier to set the Version at build time instead of having to edit AssemblyInfo files.
Anonymous
November 18, 2007
#2 (VC) $20 #4 (SLN) $30 #7 (inline tasks) $10 #8 (prop scoping) $10 #11 (debugging) $30
Anonymous
November 18, 2007
#2 (.vcproj) 10$ #3 (.vdproj) 45$ (.rptproj),(.prproj) 10$

6 (distributed build) 5$

#11 (debugging) 20$ #12 (visualization) 10%

Anonymous
November 18, 2007
$55 (#11) - Debugger $30 (#12) - Visualization $10 (#6) - Distributed Build $5 (#8) - Typed and scoped properties..
Anonymous
November 18, 2007
Currently, to build an editor, I'd need to parse and understand the file myself, rather than use the object model (I'm thinking in particular that there's no way to enumerate the metadata associated with elements). My $100 would go entirely to allowing me to fully access an arbitrary .proj file from the object model. This way anyone could build an editor (including yourselves, but hey, I know how busy you are, and I've only got a measly 100 bucks to spend...) Cheers Matt
Anonymous
November 18, 2007
$33 - (Not in list) "Framework support" for writing unit test fixtures for task libraries $33 - 4) Conversion of Visual Studio solution files $33 - 7) Extensible reuseable inline tasks
Anonymous
November 18, 2007

$30
$15
(with C#, VB, PowerShell) $25
$5
full object-model support, which opens the way for unit tests: $25

Anonymous
November 19, 2007
Visualization - $60 Debugger - $30 Lunch with Build Team - $10
Anonymous
November 19, 2007
$50 - (11) Debugger (this would be an awesome addition!) $30 - (7) Extensible inline tasks - I could see this feature getting huge use (and re-use) $15 - (3) Support for other project types $5 - (8) Typing/scoping
Anonymous
November 19, 2007
The MSBuild team is looking for some feedback from the community to keep their "vision" for the next
Anonymous
November 19, 2007
remove the distinctions between the IDE's build system and MSBUILD; eliminate all "special" project formats. Get with the 3rd party tool vendors and make their compilers work with MSBUILD!!!!!!!! then add a debugger. (Actually, add the debugger early since it will help with evangelism) #2: $25 #3: $10 #4: $25 #11: 25 #12: 15 Once I can actually use msbuild to do my builds it might become interesting to think about performance and syntax improvements.
Anonymous
November 19, 2007
Give $100 for number 4, the Visual Studio SLNs. This is a conceptual break which hurts in TeamBuild alot! Even the 30 year old make (happy birthday make http://en.wikipedia.org/wiki/Make_%28software%29#Origin) does a better job here.
Anonymous
November 19, 2007
$40: MSBuild UI. Use the Visual Studio platform and make a decent UI for this. $50: #3. Anything the IDE can build, MSBuild should be able to handle. $10: Get rid of the ellipses in the build log files. Sometimes trying to track down exactly which file msbuild is complaining about is difficult. It's a log file, who cares how long the path is.
Anonymous
November 19, 2007
11 (Debugger): $40. Yes please, complex build scripts can be a PITA to get right. 4 (Solutions to MSBuild): $20, I hate having to choose between solutions and buildfiles. 8 (Typing/scoping): $20, it's a little jarring the first time you realize this doesn't work. Would be nice. 9 (Extensible Functions): $10 7 (Inline Tasks): $10, both of these would help make build customization easier.
Anonymous
November 19, 2007
As a newbie, debugging a MSBuild script is definitely the most time-consuming part. So that's #11 #4 might feed into the MSBuild-from-MSBuild scripts that I've seen used. It would probably make this easier. MSBuild-from-MSBuild is OK, so long as you're aware that no environment is passed across unless it's specified explicitly (see time taken to debug...). #3 has already been done for installers, it's called Wix 3. Please do it for Sandcastle docs. Doing it for others too looks reasonable, not that I have suffered personally from the lack. The rest look a bit more esoteric - get the basics right first. If you want MSBuild to be more like a programming language, why not just make MSBuild a class (or set of classes) usable from powershell scripts? That's a good programming wheel, don't reinvent it badly with ugly XMl syntax, global vars and include files everywhere. I would spend: #3: $20 #4: $40 #11: $40
Anonymous
November 19, 2007
$50 on #11 Debugger $30 on #9 Extensible Functions $20 on #1 Higher performance multiprocessor support
Anonymous
November 19, 2007
$20 - [3] Support for other project types $30 - [4] Conversion of sln to MSBuild $50 - [?] Full-Fledged GUI interface to create and maintain MSBuild scripts
Anonymous
November 19, 2007
Debugger - $50 VC support - $25 Visualization - $25
Anonymous
November 19, 2007

50% Support for other Microsoft project types... - we're using WiX, would be nice to swap it out and maybe this might put some pressure on making installers a better toolset in the VS Package
40% Visualization for project and target dependencies... This would be nice.
10% Conversion of Visual Studio solution files... If just for the sake of clarity in switching between non-xml .sln and xml .*proj files

Anonymous
November 19, 2007
40$ - 3) Support for other Microsoft project types. 30$ - 4) Conversion of Visual Studio solution files. 20$ - 7) Extensible reuseable inline tasks. 5$ - 9) Extensible functions. 5$ - Visualization for project and target dependencies.
Anonymous
November 19, 2007
The comment has been removed
Anonymous
November 19, 2007
$ 50 Distribute Processing $ 50 Load Balancing Builds and Scheduled Builds Across a Farm
Anonymous
November 19, 2007
@Steve >> Get with the 3rd party tool vendors and make their compilers work with MSBUILD!!!!!!!! We need your help advocating this to those vendors. But a few months ago, Borland's released their latest IDE and it now uses MSBuild for builds of native code. Dan
Anonymous
November 19, 2007
$25 on #7 - Oh man, PowerShell in msbuild would rock my world! $25 on #11 - msbuild debugger $20 on #3 - support deployment projects $15 on #4 - convert SLN format to msbuild $10 on #2 - support VC projects directly $5 on #9 - extensible functions
Anonymous
November 19, 2007
The comment has been removed
Anonymous
November 19, 2007
#3 $10 #4 $20 #5 $30 #9 $40
Anonymous
November 19, 2007

Multiprocessor support: $5
VC support: $20
Other project types: $20
Solution files: $10
Up-to-date checking: $5
Distributed build: $5
Inline tasks: $2
Type & scope: $3
Extensible functions: $5
Debugger: $20
Analysis: $5 All worthwhile, but 2, 3 and 4 (making MSBuild all-inclusive) should be the top priority. BTW, please ask them to migrate .vdproj to WiX. The debugger (11) is a killer feature, so next most important. The other features are nice to have (very nice in some cases - those analysis features made me drool a bit), but much less important.

Anonymous
November 20, 2007
#3 (BizTalk, etc.) -- $80 #4 (.sln) -- $15 #12 (visual) -- $5
Anonymous
November 20, 2007
#3 (Biztalk) -- $80 #6 (Distributed Build) -- $15 Coffee -- $5
Anonymous
November 20, 2007
The comment has been removed
Anonymous
November 20, 2007
$50: VDPROJ (Deployment/MSI) project support $30: VC project support $20: SLN support
Anonymous
November 20, 2007
$50 on #1: faster multiprocessor builds $25 on #7: inline tasks $25 on #11: debugger
Anonymous
November 20, 2007

Anonymous
November 20, 2007

Anonymous
November 21, 2007
#4 - $25 #7 - $30 #11 - $35 #12 - $10 And if I can issue myself a $50 mail in rebate form, I'll toss in another $25 for #11, $15 for #7 and $10 for #4.

a big THANK YOU for asking for customer feedback! I'll even mail in my $50.

Anonymous
November 21, 2007
#1 Higher perf - $50 #4 Convert .sln - $15 #2 VC Support - $15 #11 Debugger - $10 #12 Visualizers - $10
Anonymous
November 21, 2007
#11 Debugger $75 #12 Visualisation $20 #7 Inline reusable tasks $5
Anonymous
November 22, 2007
Time for another weekly round-up of developer news that focuses on .NET, agile and general development
Anonymous
November 22, 2007
#2 VC support $70 #12 Visualisation $20 #4 Solution files: $10
Anonymous
November 22, 2007
#6 Distributed Build $80 #4 Conversion of sln files $10 #11 Debugger $10
Anonymous
November 23, 2007
11 - 55 bucks 12 - 20 bucks 4 - 15 bucks One week of building a team build for 120+ VC6 / VB6 / MSBuild projects made me want those the most.
Anonymous
November 23, 2007
#3 Deployment/MSI & BizTalk $80 #4 Conversion of sln files $15 #11 Debugger $5
Anonymous
November 24, 2007
#11 - MSBuild debugger: $70 #12 - Visualization: $30
Anonymous
November 25, 2007
#3 BizTalk $80 #4 Conversion $10 #11 Debugger $0
Anonymous
November 26, 2007
#2 VC Builds: $50 #4 Solutions: $10 #6 Distributed Builds: $40
Anonymous
November 26, 2007
#3 - $40 #4 - $30 #11 - $25 #12 - $ 5
Anonymous
November 26, 2007
#6 - $50 #11 - $25 #12 - $25
Anonymous
November 26, 2007
#6 - $50 #11 - $25 #12 - $25
Anonymous
November 26, 2007
#2 - $25 #4 - $25 #6 - $25 #12 - $25
Anonymous
November 26, 2007
#1 (Multiprocessor) - $10 #2 (VC support) - $0 #3 (Support for other project types) - $0 #4 (Conversion of VS solutions) - $5 #5 (Extensible up-to-date checking) - $0 #6 (Distributed Build) - $0 #7 (Extensible reuseable inline tasks) - $30 #8 (Typing and scoping) - $15 #9 (Extensible functions) - $30 #11 (An MSBuild debugger ) - $5 #12 (Visualization) - $5
Anonymous
November 27, 2007
#4 (VS Solutions) - $33 #7 (Extensibility) - $33 #11 (Debugging) - $33
Anonymous
November 27, 2007
#2 $50 (VC native support is a MUST have) #1 $25 (better multi-proc support) #6 $25 (multi-machine support) Our code base is in the 10s of millions of lines of C and C++ code, and our builds take hours and hours. So anything to help that along would be great! To be perfectly honest, I want every darn item in that list, eventually.
Anonymous
November 28, 2007
The comment has been removed
Anonymous
November 28, 2007
My vote would be to spend $50 on getting the full solution/project system MSBuild compliant (vcproj, other project types, solutions), $40 on the debugger, and $10 on the miscellaneous syntax improvements (typing and scoping, re-usable inline tasks, extensible functions). The other features (improved multiproc support, distributed build, project/target dependency visualization) target what I think is probably a pretty small segment of the market, though based on the other comments I may be wrong here!
Anonymous
November 28, 2007
The comment has been removed
Anonymous
November 30, 2007
There were over 80 responses to my recent post asking for feedback on where MSBuild should be heading
Anonymous
November 30, 2007
There were over 80 responses to my recent post asking for feedback on where MSBuild should be heading
Anonymous
November 30, 2007
$40 (#11) MSBuild debugger (especially important if you add more "cleverness" through extensible functions - which means more obscure ways of breaking a build) $30 (#2) VC++ support $10 (#4) SLN support $10 (#7) Extensible inline tasks $10 (#9) Extensible functions
Anonymous
December 03, 2007
$50: #4 - Solution file in MSBuild $50: #9 - Extensible functions
Anonymous
December 03, 2007

An MSBuild debugger $50
Visualization $35
Distributed Builds $15

Anonymous
December 03, 2007
Dan Mosely recently posted a feature poll on the MSBuild blog . Here are the results . Debuggability
Anonymous
December 04, 2007
I posted few weeks ago about the feature poll of MSBuild team on the MSBuild blog . Here are the results
Anonymous
December 05, 2007
#11 - $30 #7 - $30 #12 - $20 #6 - $5 #4, #2, #3 - $15
Anonymous
December 05, 2007
$90 #3 setup projects $10: #4
Anonymous
December 06, 2007
From an enterprise perspective #3 is probably worth $110. There are three main scenarios. a) Packaging programmer code (deployment project using application project output) b) Packaging 3rd party product/legacy application (thats not packaged) where they just provide a zip file full of files and directories. c) Re-Packaging 3rd party product that has already been packaged (such as applying additonal transforms). a) and b) really need automating. VStudio is flawed in that the file-open dialog used to select the files to be packaged, does not handle directory selection (so each directory has to be manually added, then individual files). It would be good to have an automated process where I can assign a package script to a directory have have it automatically package any files/folders/sub-folders that are dropped into that directory. Perhaps the result of a build or a 3rd party supplying a new zip file etc.
Anonymous
December 07, 2007
@AndyW Thanks for this detail -- I've passed it on to the team that owns deployment projects. I think they're getting the message, everybody wants MSBuild based deployment projects. Dan
Anonymous
December 14, 2007
$80 # 9: I would like to be able to see if a certain symbol was defined within the project build options using the /define:VarName argument, so I can conditionally reference that file. $15 #11: MSBuild Debugger $ 5 # 4: Convert .sln -> MSBuild
Anonymous
December 23, 2007
$ 40 (4) Msbuild sln $ 40 (11) Debugger $ 10 (9) Extensible functions $ 10 (7) Extensible reuseable inline tasks
Anonymous
December 28, 2007
#2 $75 VC Support Shoulda happened in VS05 #3 $20 DEPLOYMENT!!! (.vdproj would be nice, but WIX or other "full featured" would be AWESOME) #8 $5
Anonymous
January 19, 2008
$80 (4) Convert .sln file $20 (3) Other project types
Anonymous
January 21, 2008
#2 $70 VC Support (VS2005 including) #3 $30 Support for other Microsoft project types
Anonymous
February 01, 2008
The comment has been removed
Anonymous
February 20, 2008

$50
$20 11.$10 12.$20

Anonymous
February 25, 2008
#2(VC Support): $40 #4(Sln Support): $40 #1(Higher perf multiproc): $20
Anonymous
March 06, 2008
#4 - $100 MUST replace solution files -- how do you build multiple projects using one MSBuild script?
Anonymous
March 06, 2008
@Adam Lacey > how do you build multiple projects using one MSBuild script? Hi Adam, could you clarify what you mean? MSBuild can already build solution files. Also some people create "traversal projects" that simply run MSBuild on a list of projects. These could even be nested. I take your point that this is definitely not ideal, because VS cannot open such things yet. Dan
Anonymous
March 06, 2008
#1 - $20 #2 - $20 #3 - $20 #4 - $20 #12 - $20
Anonymous
March 13, 2008
#2 - $20 #4 - $30 #5 - $50 Xoreax will figure out #6, and it will only cost me about $100.
Anonymous
April 07, 2008
#9 - 70 #6, #8, #11 - $10 each And another $100 of mine for GenerateBootstrapper to: $20 - to fix "MSI not found after .NET installation reboot" $30 - to make .NET installation launchable from a bootstrapper launched from another MSI; $45 - to make setup.exe a SFX archive that contains my MSI inside. $5 - to make ReadLinesFromFile not trim them.
Anonymous
April 12, 2008
#3 - 50$ #4 - 30$ #1 - 10$ #12 - 5$ #11 - 5$
Anonymous
May 02, 2008
Late to the party, I know, but if #4 also provides some kind of support akin to solutions embedded into other solutions, $100. One of the most frustrating parts of n-tier development with VS solutions for me has been having to add a newly referenced project by something low down in the stack (say a framework project now depends on a new framework-crypto project) to EVERY solution that uses the framework project. Having Visual Studio somehow manage project inclusion would be dreamy.
Anonymous
May 06, 2008
I have a problem with msbuild on VC++ Win32 solution. When I run the msbuild on that solution file, it builds and the ide opens immediately with that solution file. Why is it so? Also, one of the dependency proj was missing. Is it because of that?
Anonymous
June 19, 2008
The comment has been removed
Anonymous
June 30, 2008
$100 dollars for .vdproj support. without this it is just another useless tool that can not complete the job needed
Anonymous
July 15, 2008
$50 (#11) - Debugger $50 (#12) - Visualization
Anonymous
November 05, 2008
#4 - $40 #2 - $40 #3 - $20 Top priority, get all solution/project/build related files into consistent / extensible format.
Anonymous
December 08, 2008
What about fixing something that everybody at some point encounters. The use of absolute paths and the related maximum characters error. This is a constant annoyance for us, since we try to honor .NET naming guidelines and try to give products real names instead of acronyms or similar. And windows does support paths longer than 256 so why this limit? The error: Typically with $(FullName) something: The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
Anonymous
February 06, 2009
$40 - #9: Extensible functions $60 - #11: Debugger
Anonymous
April 23, 2009
$80 on #2 (.vcproj migration) $20 on a Visual Editor (I am evaluating SideKick, but without .vcproj migration to MSBuild it's of little use)
Anonymous
June 30, 2010
#1 (performance) - $10 #11 (debugger) - $90
Anonymous
July 23, 2010
For those who voted for an MSBuild debugger, please see Dan's blog post: blogs.msdn.com/.../debugging-msbuild-script-with-visual-studio.aspx This post describes the (disabled by default) Visual Studio debugger feature for MSBuild.

Freigeben über

How would you spend $100 on MSBuild?

Comments

6 (distributed build) 5$

Zusätzliche Ressourcen