Share via

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

  • Article

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

  • Anonymous
    March 23, 2006
    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.

  • Anonymous
    March 23, 2006
    "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.

  • Anonymous
    March 23, 2006
    I think that more general - wildcard based solution would be better.
    Something along:

    msbuild /IgnoreProjectFiles:.vcproj;.sln

  • Anonymous
    March 23, 2006
    The comment has been removed

  • Anonymous
    March 24, 2006
    The comment has been removed

  • Anonymous
    March 24, 2006
    The comment has been removed

  • Anonymous
    March 26, 2006
    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.

  • Anonymous
    March 26, 2006
    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.

  • Anonymous
    August 02, 2006
    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.

  • Anonymous
    October 30, 2006
    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.

  • Anonymous
    March 23, 2007
    How about fixing the *.rptproj break in msbuild first.