New Feature Feedback Request: /IgnoreProjectExtensions – A new command-line switch


I’ve been in a cave just getting things done toward our Orcas release. But there’s not much a Program Manager can do without going back to their customers :) So here I am.


So here’s the scoop.  We’ve been debating internally about a new command line switch on msbuild.exe for sometime now. I am not certain that we’ve come to the right answer ourselves – but customers give us the final word – so tell us what you think about the following:


Today, when you invoke msbuild.exe from the command line and don’t specify any project files as arguments, then we do some auto inferral and scanning and decide if we should build anything. If we find either a msbuild project (anything that has an extension of *proj) or a solution file (.sln), we will build either the project or the solution as long as there is only one solution or one project in the directory. If there is a solution and a project, we will give preference to the solution.  If there’s more than one project or more than one solution, we issue an error message because we can’t decide which one to build.


Now, what if you wanted to pick the project instead when a solution is encountered, but didn’t want to specify the project name as an argument? Old habits die hard – when building Visual Studio code, we are used to issuing a single command to build the current project instead of having to specify the project name that we are specifying. So the only way to get this to work was to think of supporting a /IgnoreProjectExtensions switch that has the following usage model:


      msbuild /IgnoreProjectExtensions:vcproj;sln


Now how exactly does this simplify our lives, you ask?  We would use a .rsp file that sits next to msbuild.exe that we will add in our environment – after which, simply issuing msbuild will ignore what we ask it to ignore in the solution file.


What do you think? Something you’d find useful?  Or would you rather prefer the “clean” command line interface that we have today, and don’t think this switch is worth it? The internal debate is about the fact that we don’t want to add command line switch after command line switch to msbuild.exe as we please unless there is a specific customer scenario that we are trying to enable.  But DevDiv build is also one of our biggest internal customers :) So we look to you to tell us!


Cheers.


[Author: Faisal Mohamood]

Comments (11)

  1. RW says:

    More switches and options are always best.

    More choices is always better than less choices.

    The feature sounds like it would require minimal dev time to make anyway.

    Might as well add it.

  2. Wagahai says:

    "Keep it simple".

    In such situations, I can, and expect to, specify it myself. The benifits of a /IgnoreProjectExtensions switch are too minimal. I do not see a strong, compelling reason to add it.

  3. Hubert says:

    I think that more general – wildcard based solution would be better.

    Something along:

    msbuild /IgnoreProjectFiles:*.vcproj;*.sln

  4. axl says:

    IMHO, if you really want a specific file to be built, and you’ve got plenty of potential build files getting in your way, wouldn’t you have to specify it explicitly anyway? Type it in once and use cmd-line history.

    Instead of ignoring extensions, wouldn’t it be more useful to be able to change/define the search order?

    /DefaultProjectFiles:.proj;.sln

    Would build foo.proj before foo.sln and ignore any other files *.*proj.

  5. Seth says:

    "Keep it simple" – don’t add the switch

    Determining what a command-line utility should do if you execute it without any options is a very subjective matter IMO. I for one expect a utility to ‘explain’ me how to use it if I execute it without any options. The next time I execute it, I will specify the proper parameters. Most Visual C++ tools like CL, LINK, DUMPBIN etc. behave like this – and that’s what I am used to.

    Besides, I’ll never have the described problem because my project files are always at least one directory below my solution file. So if I want to build the solution, I CD to the solution folder and execute MSBuild from there. If I would want to build an individual project using MSBuild (but in these cases I always use VS), I would CD to the project folder and execute MSBuild from there.

    Having a switch to specify how MSBuild should behave if no switches are specified does seem a bit awkward. If you put that switch in a .rsp file, then why not simply put the name of the project you want to build in the .rsp file?

  6. KeithH says:

    If you choose to implement the switch please consider using something else (a comma perhaps) to separate different extensions.  MSH (Monad) use semi-colon to delimit separate commands.  So in order to get that command line to work I’d have to escape the semi-colon:

    msbuild /IgnoreProjectExtensions:vcproj`;sln

    Blech.

  7. Marek Sieradzki says:

    Why would anyone want to type this switch? Wouldn’t it be better to have something like /projectFirst?

    Anyway Windows XP does have tab completion in its shell. I don’t really understand what’s the problem.

  8. I added a similar wish to the MSBuild wiki a while back. See:

    http://channel9.msdn.com/wiki/default.aspx/MSBuild.WishProjFilePresidence

    I agree with Axl here. Add a switch that allows us to set the extension precedence. If there’s a .proj file, I would want to prioritize that rather than the .sln. How about something like this:

    /PrioritizeProjectExtensions:proj;sln

    Keep up the good work.

    Thanks, Jamie.

  9. Eric says:

    The extension would help solve another problem — If my solution has a setup project or rptproj, neither of which are in a format that msbuild recognizes, there is currently no way to tell it to "compile this .sln, but ignore these problem project types" — If I could exclude certain project extentions, then this would solve that problem as well.

  10. James says:

    Don’t add this switch.  More switches make the msbuild harder to learn, so switches should do something pretty useful  to offset this.  And I don’t think the switch is useful enough.

  11. John Mills says:

    How about fixing the *.rptproj break in msbuild first.