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

  • 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

  1. Multiprocessor support: $15
  2. Project types:   - $30 for Deployment/MSI projects   - $5 for Sql Reporting projects
  3. .sln files: $5
  4. Extensible reusable inline tasks: $20
  5. 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

  1. $30
  2. $15
  3. (with C#, VB, PowerShell) $25
  4. $5
  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

  1.  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
  2. 40% Visualization for project and target dependencies... This would be nice.
  3.  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

  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
  10. Debugger: $20
  11. 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

  1.  $5
  2.  $40
  3.  $10
  4.  $15
  5.  $15
  6. $10
  7. $5
  • Anonymous
    November 20, 2007
  1. $40
  2. $40
  3. $10
  4. $10
  • 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

  1. An MSBuild debugger  $50
  2. Visualization $35
  3. 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

  1. $50
  2. $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.