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.
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.
Visual Studio – VS IDE Project and Build Team
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
Still waiting for a solution nearly 4 years later. MS's response is 2+ years old.
Drew Noakes commented
Isn't this taken care of with VS2017's .csproj file format now?
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?
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
Microsoft giveth the project.json and Mircosoft taketh away project.json.... Visual Studio you could help ease the merge pain!
Sema Jha commented
We supply best and missy organization so which you will have the capacity to conquer your reality that is crushed and aloneness in Udaipur city for enjoy unlimited with call girls in Udaipur area.
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.
Sema Jha commented
I saw my rivals are escorting somebody, and they earned a considerable measure than our month to month levy. Visit our website for more details about call girls in Surat area. http://www.surat-escorts.in/
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.
Fix this instead of adding tooling for a language, library, third party build tool used by less than 3% of the VS user base.
Silly considering this is a standard feature in Linux/Unix based development tool systems for over 20 years.
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 Smirnov commented
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 Semushin commented
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):
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 Gray commented
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 ;)
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 Kumar commented
This is definitely needed feature for a big, geographically divided team. I already see Java world solves this (live maven, graddle etc.,) problem.
Michael Paterson commented
@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 Day commented
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.