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.
I'd like solution explorer to be a view on the file system. By doing this project files would be incredibly merge friendly, because they would only be updated for metadata (prefer many files to one file with many sections in that case too) or exclusions. This might open the door for more convention based project configuration/structure than even today.
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
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.
Nathan Black commented
@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...
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 Paterson commented
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 Kursawe commented
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.
Andy Yong commented
They will have to figure out a way to exclude file from project...
@JohnStaelens absolutely! web development roundtripping between sublime and VS is such a pain because of this
John Staelens commented
Rahul Mittal commented
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?
Gordon Tucker commented
How is this not in VS yet? This would make nearly all our merge conflicts go away
I just lost a whole week merging, and around 30% of the time was csproj files. And it's not even the first time.
MS, please please please implement this.
Hi, 3-voted this one: here is the particular scenario I setup and which would benefit from this:
I'm part of a team building a rather large application split into a .NET client and a Java server. Both parts communicate through Soap + Google Protobuf. Tjherefore the wsdl/proto contracts are shared between the 2 technologies.
On the .NET side I have set up a generation chain that takes wsdl, protobuf (as well as other input data) and generates proxies in cs files. Because I don't want to modify the corresponding csproj each time I gen my source cs, I use the *.cs trick. Everything works well except when somebody changes the project from Visual Studio... And this happens once in a while... It's be much more secure if the csproj could remember it should include files based on a wildcard.
Guido Smeets commented
sounds like a plan. while at it though, maybe also make them sort items in some way, that would solve 80% of the merge issues as well.
This will also help with the nasty problem of csproj merge conflicts because of high churn.
Think of this like .ignore files for Visual Studio rather than .includes. You add more often than you ignore.