I suggest you ...

VS IDE should support file patterns in project files

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.

3,632 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Corey KaylorCorey Kaylor shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →
    cromwellryancromwellryan shared a merged idea: Make project files exclusionary vs inclusionary  ·   · 

    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

    25 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • 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.

      • FredFred 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.

      • FredFred commented  ·   ·  Flag as inappropriate

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

      • FredFred 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)

      • Viktor SmirnovViktor Smirnov commented  ·   ·  Flag as inappropriate

        Just include all files by default and let users exclude whatever they want. Similar to .gitignore. Dealing with .csproj merges is a constant mess.

      • Sergey SemushinSergey Semushin commented  ·   ·  Flag as inappropriate

        I would also like to point out the following problem. Sadly I haven't tested it with C# projects but with C++ adding files using wildcards increase time and memory consumption on project opening tremendously compared to non-wildcard project. Here's issue I've created and imo I've received very strange response (maybe some supporters of this feature would be interested):

        https://connect.microsoft.com/VisualStudio/feedback/details/1347894/opening-project-with-wildcards-in-filenames-takes-significantly-more-time-and-requires-significantly-more-memory-than-project-with-the-explicit-list-of-files

        Seeing now how this feature is on top, I hope that if file patterns will be refurnished in next version, my issue have a chance to be resolved too.

      • Derek GrayDerek Gray commented  ·   ·  Flag as inappropriate

        With Visual Studio 2013, it seems that adding files and folders that fall under a wildcard will not cause the wildcard to be expanded in the .csproj, but removing files or folders that fall under that same wildcard will cause the wildcard to be expanded in the .csproj.

        So if you could just address that, all would be well ;)

      • neographikalneographikal commented  ·   ·  Flag as inappropriate

        I love the .net environment but I absolute hate the csproj files and all the conflicts that come with it if you are working with multiple people on a project. Rather than a pattern, removing the files as a whole would be ideal. If a file is in the project directory structure, it is there for a reason and should be included. Maybe for some special cases use something like a git ignore and be done with it.

      • Vadivel KumarVadivel Kumar commented  ·   ·  Flag as inappropriate

        This is definitely needed feature for a big, geographically divided team. I already see Java world solves this (live maven, graddle etc.,) problem.

      • Michael PatersonMichael Paterson commented  ·   ·  Flag as inappropriate

        @Nathan Black that's an amazing idea! We are building an angularjs app that has _nothing_ to do with asp.net. That being said, I love Visual Studio and want to continue using it as my daily development but I don't want to dictate to others which OS/IDE (if any) they should use. I'm considering treating the project as a web site instead of a web application which I think might solve the problem in a round-about way.

      • Wes DayWes Day commented  ·   ·  Flag as inappropriate

        This leads to a place where solution and project files are mostly empty.
        The next step is to move to conventions based approach for solutions and projects, so that in the default case no solution or project files are even necessary.
        They would only be necessary for cases in which you wish to override the default conventions.

      • Nathan BlackNathan Black commented  ·   ·  Flag as inappropriate

        @micheal patternson I'm that Sublime Text guy :) I wildcard it and it works until the VS guys add a file and VS just expands them all again.

        What's sad is I first recognized this as a problem in 2006. The fact it is still an issue in 2014 shows that Dev Div is far disconnected from us developers. Oh well back to Sublime...

      • EwenEwen commented  ·   ·  Flag as inappropriate

        For a lot of build configs etc I import a .csproj file - Visual Studio tends not to ****** those.

        <Import Project="blah\blah\blah.csproj"> It also keeps Absolute file paths intact.

      • Michael PatersonMichael Paterson commented  ·   ·  Flag as inappropriate

        This would really be great for teams that develop on different platforms for the same project. I love Visual Studio on Windows and others on my team use Sublime Text on a Mac. This would definitely make it a much better experience.

      • Philipp KursawePhilipp Kursawe commented  ·   ·  Flag as inappropriate

        That is really anyoing and I have to wonder how the teams of MSFT handle projects with a lot of files without the wildcard msbuild feature.

      • Anonymous commented  ·   ·  Flag as inappropriate

        @JohnStaelens absolutely! web development roundtripping between sublime and VS is such a pain because of this

      • John StaelensJohn Staelens commented  ·   ·  Flag as inappropriate

        Also, make it so that VS will watch the directories under a /**/ pattern. We have a team that does most of their work in Sublime Text but it would be nice for people who work in both .Net and JavaScript to be able to see any new files when added to a specific directory structure (when we get latest) without having to unload and load the project.

      • Rahul MittalRahul Mittal commented  ·   ·  Flag as inappropriate

        Would also like to add that if I have a **/*.cs and **/*.aspx.cs rule in my project file, the latter gets ignored. Can we ensure the latter overrides the former regardless of whether the latter is defined before or after the former?

      ← Previous 1

      Feedback and Knowledge Base