Repository navigation
Wildcards are not supported in vc projects, they have been replaced with explicit files #6214
Description
Environment
Windows build number: [run `[Environment]::OSVersion` for powershell, or `ver` for cmd]
Windows Terminal version (if applicable):
Any other software? Visual Studio 16.6.0
Steps to reproduce
I recently upgraded VS to 16.6.0 and this pops up before build. It seems the VS is not happy with the current vcproj file.
Expected behavior
Actual behavior
Reacted by Cory Kramer, TheQwertiest and CJohnson
Activity
zadjii-msft commentedon May 27, 2020
Ho boy, they sure aren't, and we're learning this the hard way. We've got a discussion out with the VS team about this most recent change, so I guess we'll use this thread to track it.
For now, I think the mitigation is to just not check in any the changes that VS makes to our projects silently, until we can figure out a better mitigation going forward.
Dustin L. Howett (@DHowett)'s driving this with that team so I'll stick him as the assignee.
WSLUser commentedon May 27, 2020
Isn't being explicit technically more performant? Instead of having the system look for everything, you're telling it exactly where everything is.
zadjii-msft commentedon May 27, 2020
Yea but unfortunately, the
Resources.reswlocalization in our CI actually relies on the fact that there are wildcards in the paths, because we don't know which directories for which languages exist quite yet. There's a much bigger discussion happening internally.ZhilkinSerg commentedon Jun 2, 2020
Can't it be an optional thing? It is a real drawback for multi-platform projects - e.g. we do not have to list newly added source files in
MakefileorCMakeLists.txtfor https://github.com/CleverRaven/Cataclysm-DDA/, but will have to do that now for VS projects? Basically, any contributor, who adds new source files, will have to fiddle with VS solutions and add new files there, even when they are not on a Windows machine.DHowett commentedon Jun 2, 2020
It's more like "we just need to do the work to remove the wildcards" than "it can be made optional." You're preaching to the choir here: I am upset about this change too. It violates everyone's mental model for how MSBuild should work, but... here we are.
It appears as though wildcards were never supported for vcxproj files and they just happened to work. I was pointed to the official documentation on the matter. 😦
Lordmau5 commentedon Jun 3, 2020
I'm happy to see that there is a thread about this.
Can we please have the option for this in the settings for VS?
I have a project in which wildcards work perfectly fine and this update makes it so I have to effectively set the files to read-only.
I can understand as to why it would not be officially supported / endorsed - it could potentially break certain projects' workflows.
However, not all projects are the same and what doesn't work for one can still work for another.
DHowett commentedon Jun 3, 2020
You're asking the wrong people, friend. Best I can do is tell them that there's some community unrest because of this change. 😄
Lordmau5 commentedon Jun 3, 2020
Oh I just realized this is in the MS Terminal repository, my apologies.
And yeah - community unrest is indeed present.
Again, it might not be as vocal as it could be, but I do feel this shouldn't just ... outright be thrown out of the window...
alabuzhev commentedon Jun 3, 2020
Please do - maybe reports from MS teams will get more attention than from us mere mortals.
Is there any open issue for this on the VS bugtracker we can comment / vote for?
Of course, it was never officially supported, but it worked nicely for years and now a lot of projects are broken :(
Move all wildcards into targets or expand them
Move all wildcards into targets or expand them (#6406)
Move all wildcards into targets or expand them (#6406)
Update Fork (#1)