I suggest you ...

VS IDE should support file patterns in project files

This suggestion is migrated to Developer Community. Please use below link to view the current status.
Patterns should be preserved and unmodified when working with *proj files. If I specify a pattern with something like **/*.cs for my code files. If I add a new .cs file that fits that pattern the .csproj file should not be modified.

MSBuild already respects this, but the IDE will always modify the project file.

For numerous scenarios this could simplify the diff / merge process.

4,213 votes
Sign in
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Corey Kaylor shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    Hello everyone and thank you for the feedback. We are actively investigating ways to improve how Visual Studio handles project content. This suggestion falls into that category. Unfortunately, we will not be able to address this feedback for the Visual Studio 2015 release. We will update the community when our plans in this area have gained more clarity.

    Will Buik,
    Visual Studio – VS IDE Project and Build Team


    Sign in
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      • Anonymous commented  ·   ·  Flag as inappropriate

        Nice thank you for upload post I m learn something when read every comment getting some new information do you want It services like

        <a href="https://www.nncinfotech.com/">Top 10 IT Companies in Surat</a>
        <a href="https://www.nncinfotech.com/">Top web design company in surat</a>
        <a href="https://www.nncinfotech.com/"> Top ecommerce development company in surat</a>
        <a href="https://www.nncinfotech.com/">customized app in surat</a>

      • Nick commented  ·   ·  Flag as inappropriate

        Pretty ridiculous that this has over 4,000 votes, has existed for FIVE YEARS and has not been addressed.

      • Josh Wood (SK83RJOSH) commented  ·   ·  Flag as inappropriate

        Is there any chance we'll see this make it's way into C/C++ projects? I use wildcards for custom build tools for certain file types, and it's rather unfortunate that VS2017 automatically expands the wildcards any time I edit / build the project.

      • Kevin Pilch [MSFT] commented  ·   ·  Flag as inappropriate

        Just an update that this is well supported in the new project system used by .NET Core and .NET Standard in Visual Studio 2017, but we haven't done the work to support it for existing project types. Over time, we'll hopefully be able to move more project types over to the new project system once we work out any compat issues there.

      • Bradley Landis commented  ·   ·  Flag as inappropriate

        to expand on the comment by Ambrose Little I also found the following:

        When you delete the file and the wildcard gets expanded in the csproj file, it adds the file you just deleted to that list (which means you can no longer build). It also adds some temporary files.

      • Ambrose Little commented  ·   ·  Flag as inappropriate

        I was testing this out today, and VS seems to do okay with something like this for the compiles:
        <Compile Include="**/*.cs" />
        <Compile Remove="bin/**/*.cs" />
        <Compile Remove="obj/**/*.cs" />

        It seems to do fine loading, building, and even adding files w/o problem. BUT if you remove a CS file, it expandos the whole list again. :(

        Please add full support. Resolving csproj merge "conflicts" is a daily PITA for many teams. Adding full glob/wildcard support would solve almost all of that I am sure.

      • Pablo commented  ·   ·  Flag as inappropriate

        It seems to be working with wildcards with VS 2015 update 3, I didn't see it expanding in vcxproj, but there is clearly a bug that it tries to expand that in .vcxproj.filters file. The crazy part of this bug is that VS seems to add entire list of files "squared". I have 132 files added by my wildcard, and VS adds 17424 (132*132) entries to .vcxproj.filters. Total WTF

      • Henry commented  ·   ·  Flag as inappropriate

        Still waiting for a solution nearly 4 years later. MS's response is 2+ years old.

      • Anonymous commented  ·   ·  Flag as inappropriate

        Dilbert would refer to the many pet extensions in VS as 'resume driven development'

        Does it take a $10,000,000+ purchaser of VS development tools to talk to a MS VP to get fixes into VS?

      • Anonymous commented  ·   ·  Flag as inappropriate

        After 15+ years of Visual Studio since v6.0, I've no time or money to spend on extensions, third party add-ins, custom build steps, extensibility, etc.

        I don't add it to our build/deploy/auto-unit test/package cycle if it is not built into VS.

        Basis for that is the 1+ man-year I've personally spent fixing/working around/removing such time wasters from the projects I've be on.

        Customers purchase business functionality and not cool development tool add-ins

      • kev commented  ·   ·  Flag as inappropriate

        Microsoft giveth the project.json and Mircosoft taketh away project.json.... Visual Studio you could help ease the merge pain!

      • Piotr commented  ·   ·  Flag as inappropriate

        Here's my proposal, leave the sad and painfull .NET and it's ecosystem for a better and happier experience with another language/platform and a smarter IDE.

      • Anonymous commented  ·   ·  Flag as inappropriate

        Counter proposal:

        1. Have the Visual Studio team publish in Github an API specification for what Visual Studio does with project files.

        2. Ask for community feedback.

        3. Use that as the basis for requirements for this new functilnality

        This drives the Visual Studio team to build actual requirements and lay out a business case for spending $X on implementing it.

        Hammer that out until it is ready to send out for a RFP.

      • Fred commented  ·   ·  Flag as inappropriate

        Fix this instead of adding tooling for a language, library, third party build tool used by less than 3% of the VS user base.

      • Fred commented  ·   ·  Flag as inappropriate

        Silly considering this is a standard feature in Linux/Unix based development tool systems for over 20 years.

      • Fred commented  ·   ·  Flag as inappropriate

        1. Enumerate the API needed by VS when dealing with project files
        2. Send it out for request for proposals
        3. Select a vendor to do implementation, including non-Windows operating systems
        4. Put it into VS 2017

        Avoids VS becoming a can do everything but needs weeks to get configured product (eclipse)

      ← Previous 1 3

      Feedback and Knowledge Base