How would you spend $100 on MSBuild?


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 (119)

  1. 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.

  2. BinaryCoder says:

    $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)

  3. Mike Ward says:

    $30 (#7) – Inline tasks

    $20 (#3) – Deployment/MSI

    $20 (#4) – Conversion of .sln

    $20 (#1) – Multiprocessor

    $10 (#11) – Debugger

  4. $50 (#11) – Debugger

    $50 (#12) – Visualization

  5. #2 – $5

    #3 – $30

    #4 – $30

    #11 – $15

    #12 – $20

  6. Bert Huijben says:

    $20 (#1) Multicore speedup

    $25 (#2) VC Projects

    $ 5 (#4) Solutions

    $30 (#7) Internal tasks

    $ 5 (#9) Internal functions

    $15 (#12) Build visualization

  7. John Hall says:

    $90 (#2) VC support

    $10 (#5) Extensible up-to-date checking

  8. Li Yang says:

    $50 (#11) – Debugger

    $50 (#12) – Visualization

  9. Mitch Wagner says:

    $50 [#11] – Debugger

    $25 [#12] – Visualization

    $10 [#9]  – built in functions

    $10 [#8]  – Typing and scoping

    $5  [#7]  – extensible reusable inline tasks

  10. john says:

    #3

    #4

    #2

    In that order.

  11. David Parrish says:

    $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

  12. Veksi says:

    #2 VC support

    #1 Higher performance multiprocessor support

    #4 Conversion of Visual Studio solution files

    And then better debug and visualisation support

  13. $35 – #5 – extensible uptodate check

    $35 – #12 dependenency visualization –  wpf please

    $5 – #4 .sln files are so lame

    $0 – #3 this should be the responsibility of those project teams. On our project – if somthing requires an IDE to build, it’s not viable tech for us.

    $25 – #1

  14. Buck Hodges says:

    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

  15. Buck Hodges says:

    Dan Moseley, a developer on the MSBuild team , wants to know how you would prioritize features for the

  16. JuzC says:

    $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.

  17. Dan Moseley, a developer on the MSBuild team , wants to know how you would prioritize features for the

  18. James Geall says:

    #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.

  19. $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

  20. GertGregers says:

    #11 – $60

    #12 – $25

    #3 – $15

  21. John Bennett says:

    1) Multiprocessor support: $15

    3) Project types:

      – $30 for Deployment/MSI projects

      – $5 for Sql Reporting projects

    4) .sln files: $5

    7) Extensible reusable inline tasks: $20

    11) Debugger: $25

  22. Maor David says:

    #12 – visualization – $30

    #1 – msbuild debugger – $25

    #2 – vc support – $20

    #9 – extensible functions – $5

    #7 – Inline tasks  – $20

  23. Maor David says:

    Dan Moseley, a developer on the MSBuild team , wants to know how you would prioritize features for the

  24. #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.

  25. Eugenez says:

    #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.

  26. 4   – $45

    6   – $10

    7   – $10

    11 – $30

    12 – $10

  27. Carel Lotz says:

    #7 – $10

    #9 – $30

    #11 – $50

    #12 – $10

  28. Ali says:

    #2  $30

    #4  $30

    #6  $20

    #12  $20

  29. Dennis says:

    $100 Make it easier to set the Version at build time instead of having to edit AssemblyInfo files.

  30. #2 (VC) $20

    #4 (SLN) $30

    #7 (inline tasks) $10

    #8 (prop scoping) $10

    #11 (debugging) $30

  31. Rudenko Sergey says:

    #2  (.vcproj) 10$

    #3  (.vdproj) 45$

       (.rptproj),(.prproj) 10$

    # 6 (distributed build) 5$

    #11 (debugging) 20$

    #12 (visualization) 10%

  32. Martin MacPherson says:

    $55 (#11) – Debugger

    $30 (#12) – Visualization

    $10 (#6) – Distributed Build

    $5 (#8) – Typed and scoped properties..

  33. kingbing says:

    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

  34. $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

  35. 3) $30

    4) $15

    7) (with C#, VB, PowerShell) $25

    9) $5

    13) full object-model support, which opens the way for unit tests: $25

  36. Visualization – $60

    Debugger – $30

    Lunch with Build Team – $10

  37. jbramwell says:

    $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

  38. The MSBuild team is looking for some feedback from the community to keep their "vision" for the next

  39. Steve Nuchia says:

    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.

  40. Markus Schiller says:

    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.

  41. Chris Lively says:

    $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.

  42. josh says:

    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.

  43. Anthony says:

    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

  44. Ken says:

    $50 on #11 Debugger

    $30 on #9  Extensible Functions

    $20 on #1  Higher performance multiprocessor support

  45. Dylan Smith says:

    $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

  46. John Robbins says:

    Debugger – $50

    VC support – $25

    Visualization – $25

  47. Rick Glos says:

    3)  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

    12) 40% Visualization for project and target dependencies… This would be nice.

    4)  10% Conversion of Visual Studio solution files… If just for the sake of clarity in switching between non-xml .sln and xml .*proj files

  48. 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.

  49. Tom A says:

    I think it is very important at this late stage to get the other groups to get with it and move to the MSBuild format.  I can’t believe that even in VS 2008 the vdproj files are not MSBuild and thus can’t build from a pure MSBuild command-line.  We had to go to WiX to avoid devenv.exe builds.  A true IDE like Visual Build Pro would be awesome, but their tool is so inexpensive already that it probably isn’t worth Microsoft’s time to duplicate it.

  50. Patrick says:

    $ 50 Distribute Processing

    $ 50 Load Balancing Builds and Scheduled Builds Across a Farm

  51. Mike Fourie says:

    @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

  52. Keith Hill says:

    $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

  53. Cleve Littlefield says:

    $50 – Debugger

    $25 – Converting to all MSBuild solution system, 2, 3, 4

    $25 – Deployment support for Test, Pre-Production, and production environments (with log on what was applied, and when).  Should run appropriate test suite after deployment (full suite in test, smoke test in production).

  54. #3 $10

    #4 $20

    #5 $30

    #9 $40

  55. Gavin Greig says:

    1. Multiprocessor support: $5

    2. VC support: $20

    3. Other project types: $20

    4. Solution files: $10

    5. Up-to-date checking: $5

    6. Distributed build: $5

    7. Inline tasks: $2

    8. Type & scope: $3

    9. Extensible functions: $5

    11. Debugger: $20

    12. 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.

  56. #3 (BizTalk, etc.) — $80

    #4 (.sln) — $15

    #12 (visual) — $5

  57. Roland K says:

    #3 (Biztalk) — $80

    #6 (Distributed Build) — $15

    Coffee — $5

  58. Shawn W says:

    #4 – 50%, do it fast and good, sln files must go away as they don’t scale and overly complacate large tree builds that have non-trivial dependancy graphs.

    #2,3 – 40%, These two items are the same thing get all the *proj files to just work, do it good

    #7 – 10%, do it cheap, while this functionality has a high value for some, more often than not inline code will just make the build files harder to maintain for the majority of builders.

    The rest would benefit from having the above list completed first.

  59. Justin says:

    $50: VDPROJ (Deployment/MSI) project support

    $30: VC project support

    $20: SLN support

  60. Austin Donnelly says:

    $50 on #1: faster multiprocessor builds

    $25 on #7: inline tasks

    $25 on #11: debugger

  61. FreeToDev says:

    1)  $5

    3)  $40

    6)  $10

    7)  $15

    9)  $15

    11) $10

    12) $5

  62. Klaus RM says:

    2) $40

    4) $40

    1) $10

    12) $10

  63. #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.

  64. Steve St Jean says:

    #1 Higher perf – $50

    #4 Convert .sln – $15

    #2 VC Support – $15

    #11 Debugger – $10

    #12 Visualizers – $10

  65. Jim McGregor says:

    #11 Debugger $75

    #12 Visualisation $20

    #7  Inline reusable tasks $5

  66. Time for another weekly round-up of developer news that focuses on .NET, agile and general development

  67. Aikson says:

    #2 VC support $70

    #12 Visualisation $20

    #4 Solution files: $10

  68. Floh says:

    #6 Distributed Build $80

    #4 Conversion of sln files $10

    #11 Debugger $10

  69. Chris says:

    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.

  70. Muhammed Inam says:

    #3 Deployment/MSI & BizTalk $80

    #4 Conversion of sln files  $15

    #11 Debugger $5

  71. Ben says:

    #11 – MSBuild debugger: $70

    #12 – Visualization: $30

  72. Malte says:

    #3 BizTalk $80

    #4 Conversion $10

    #11 Debugger $0

  73. Josh says:

    #2 VC Builds: $50

    #4 Solutions: $10

    #6 Distributed Builds: $40

  74. Craig says:

    #3  – $40

    #4  – $30

    #11 – $25

    #12 – $ 5

  75. prulifson says:

    #6 – $50

    #11 – $25

    #12 – $25

  76. Rune says:

    #6 – $50

    #11 – $25

    #12 – $25

  77. Morten Brun says:

    #2  – $25

    #4  – $25

    #6  – $25

    #12 – $25

  78. Sergey Popov says:

    #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

  79. Steve says:

    #4 (VS Solutions) – $33

    #7 (Extensibility) – $33

    #11 (Debugging) – $33

  80. Dean ONeill says:

    #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.

  81. larryd says:

    $75 – Mulitple builds at one time on one box

    $25 – more like NAnt, in otherwords programable

  82. Garry Trinder says:

    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!

  83. dvanderboom says:

    Performance, performance, performance.

    $50 – #5 Extensible Up-to-date Checking.

    Right now when I "build solution", it seems to spend too much time figuring out if the project has changed, and builds projects that shouldn’t need to be rebuilt.

    $30 – #1 Greater Multi-processor Performance

    For obvious reasons.

    $20 – #13 Better scheduling of tasks, even for single-processor performance

    The bottleneck for MSBuild is file access, right?  So when multiple projects are being built, why isn’t my disk access in Resource Monitor pegged constantly?  It reads for a while, then stops reading while compiling the code, then starts hitting the disk again later to write out files, etc.  I imagine some kind of thread should be constantly filling the funnel and queueing up files into memory proactively so that no downstream tasks are held up.  Thrash the disk like crazy and don’t let any non-disk-accessing gaps appear.

    Also, the use of multiple threads and concurrent builds could be useful even on single-processor machines.  I’m guessing some multithreading must already be going on, but an optimization of these could probably do wonders.

  84. There were over 80 responses to my recent post asking for feedback on where MSBuild should be heading

  85. There were over 80 responses to my recent post asking for feedback on where MSBuild should be heading

  86. abdul says:

    $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

  87. David A. says:

    $50: #4 – Solution file in MSBuild

    $50: #9 – Extensible functions

  88. Jon S says:

    11) An MSBuild debugger  $50

    12) Visualization $35

    6) Distributed Builds $15

  89. Dan Mosely recently posted a feature poll on the MSBuild blog . Here are the results . Debuggability

  90. Maor David says:

    I posted few weeks ago about the feature poll of MSBuild team on the MSBuild blog . Here are the results

  91. Lakshmi Akkiraju says:

    #11 – $30

    #7  – $30

    #12 – $20

    #6  – $5

    #4, #2, #3 – $15

  92. Ion Singh says:

    $90 #3 setup projects

    $10: #4

  93. AndyW says:

    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.

  94. Mike Fourie says:

    @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

  95. Jeff Gullett says:

    $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

  96. Ian Jorgensen says:

    $ 40 (4)  Msbuild sln

    $ 40 (11) Debugger

    $ 10 (9)  Extensible functions

    $ 10 (7)  Extensible reuseable inline tasks

  97. Burton says:

    #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

  98. Pete says:

    $80 (4) Convert .sln file

    $20 (3) Other project types

  99. Alex says:

    #2 $70 VC Support (VS2005 including)

    #3 $30 Support for other Microsoft project types

  100. Richard Nagle says:

    #4 $100

    But rather than a converter I’d like to see VS replace .sln files with MS-Build files. Probably just a pipe-dream but I think this would have huge benefits for anyone with a more than basic configuration.

  101. Kevin Rose says:

    6. $50

    7. $20

    11.$10

    12.$20

  102. Nicolas Gauvin says:

    #2(VC Support): $40

    #4(Sln Support): $40

    #1(Higher perf multiproc): $20

  103. Adam Lacey says:

    #4 – $100

    MUST replace solution files — how do you build multiple projects using one MSBuild script?

  104. Mike Fourie says:

    @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

  105. Jason Spicer says:

    #1 – $20

    #2 – $20

    #3 – $20

    #4 – $20

    #12 – $20

  106. SpiderM9 says:

    #2 – $20

    #4 – $30

    #5 – $50

    Xoreax will figure out #6, and it will only cost me about $100.

  107. #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.

  108. Daniel R says:

    #3 – 50$

    #4 – 30$

    #1 – 10$

    #12 – 5$

    #11 – 5$

  109. mikeycooper says:

    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.

  110. Anonymous says:

    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?

  111. Duncan Handley says:

    It has to be

    #2 – $33

    #3 – $33

    #4 – $33

    everything else – $1

    You have to make msbuild a standard before you do anything else with it.  I work for a very large multi-national company, and we have applications written in many languages, particularly C.  I wanted to standardise us on MSBuild for all our Microsoft related apps, but because you don’t use msbuild for VC project files, or any solution files I may have to recommend we use something else.

  112. frank says:

    $100 dollars for .vdproj support.  without this it is just another useless tool that can not complete the job needed

  113. Bu Hai-Qing says:

    $50 (#11) – Debugger

    $50 (#12) – Visualization

  114. Richard Winks says:

    #4 – $40

    #2 – $40

    #3 – $20

    Top priority, get all solution/project/build related files into consistent / extensible format.

  115. NTR says:

    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.

  116. AYoG says:

    $40 – #9: Extensible functions

    $60 – #11: Debugger

  117. Fabrizio Benedetti says:

    $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)

  118. Peter says:

    #1 (performance) – $10

    #11 (debugger) – $90

  119. Chuck England - MSFT says:

    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.