starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-09-25 00:15:10 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Wildcards are not supported in vc projects, they have been replaced with explicit files #8615

New Issue
Closed
opened 2026-01-31 01:33:50 +00:00 by claunia · 9 comments
claunia commented 2026-01-31 01:33:50 +00:00
Owner
Copy Link

Originally created by @skyline75489 on GitHub (May 27, 2020).

Originally assigned to: @DHowett on GitHub.

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

Originally created by @skyline75489 on GitHub (May 27, 2020). Originally assigned to: @DHowett on GitHub. <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING: 1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement. 2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement. 3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number). 4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement. 5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement. All good? Then proceed! --> <!-- This bug tracker is monitored by Windows Terminal development team and other technical folks. **Important: When reporting BSODs or security issues, DO NOT attach memory dumps, logs, or traces to Github issues**. Instead, send dumps/traces to secure@microsoft.com, referencing this GitHub issue. If this is an application crash, please also provide a Feedback Hub submission link so we can find your diagnostic data on the backend. Use the category "Apps > Windows Terminal (Preview)" and choose "Share My Feedback" after submission to get the link. Please use this form and describe your issue, concisely but precisely, with as much detail as possible. --> # Environment ```none 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 <!-- A description of how to trigger this bug. --> 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 <!-- A description of what you're expecting, possibly containing screenshots or reference material. --> # Actual behavior <!-- What's actually happening? -->
claunia commented 2026-01-31 01:33:52 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (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.

@DHowett's driving this with that team so I'll stick him as the assignee.

@zadjii-msft commented on GitHub (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. @DHowett's driving this with that team so I'll stick him as the assignee.
claunia commented 2026-01-31 01:33:52 +00:00
Author
Owner
Copy Link

@WSLUser commented on GitHub (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.

@WSLUser commented on GitHub (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.
claunia commented 2026-01-31 01:33:52 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 27, 2020):

Yea but unfortunately, the Resources.resw localization 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.

@zadjii-msft commented on GitHub (May 27, 2020): Yea but unfortunately, the `Resources.resw` localization 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.
claunia commented 2026-01-31 01:33:53 +00:00
Author
Owner
Copy Link

@ZhilkinSerg commented on GitHub (Jun 2, 2020):

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.

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 Makefile or CMakeLists.txt for 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.

@ZhilkinSerg commented on GitHub (Jun 2, 2020): > 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. 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 `Makefile` or `CMakeLists.txt` for 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.
claunia commented 2026-01-31 01:33:53 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jun 3, 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. 😦

Do not use this approach if you intend to edit the project file later by using the Visual Studio IDE. If you create a .vcxproj file manually, the Visual Studio IDE might not be able to edit or load it, especially if the project uses wildcards in project items.
Walkthrough: Using MSBuild to Create a Visual C++ Project

The Visual Studio C++ project system currently does not support wildcards in project items.
.vcxproj and .props file structure

@DHowett commented on GitHub (Jun 3, 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. 😦 > Do not use this approach if you intend to edit the project file later by using the Visual Studio IDE. If you create a .vcxproj file manually, the Visual Studio IDE might not be able to edit or load it, especially if the project uses wildcards in project items. > [Walkthrough: Using MSBuild to Create a Visual C++ Project](https://docs.microsoft.com/en-us/cpp/build/walkthrough-using-msbuild-to-create-a-visual-cpp-project?view=vs-2019) > The Visual Studio C++ project system currently does not support wildcards in project items. > [.vcxproj and .props file structure](https://docs.microsoft.com/en-us/cpp/build/reference/vcxproj-file-structure?view=vs-2019)
claunia commented 2026-01-31 01:33:53 +00:00
Author
Owner
Copy Link

@Lordmau5 commented on GitHub (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.

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. 😦

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.

@Lordmau5 commented on GitHub (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. ___ > 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. 😦 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.
claunia commented 2026-01-31 01:33:53 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jun 3, 2020):

Can we please have the option for this in the settings for VS?

You're asking the wrong people, friend. Best I can do is tell them that there's some community unrest because of this change. 😄

@DHowett commented on GitHub (Jun 3, 2020): > Can we please have the option for this in the settings for VS? You're asking the wrong people, friend. Best I can do is tell them that there's some community unrest because of this change. :smile:
claunia commented 2026-01-31 01:33:54 +00:00
Author
Owner
Copy Link

@Lordmau5 commented on GitHub (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...

@Lordmau5 commented on GitHub (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...
claunia commented 2026-01-31 01:33:54 +00:00
Author
Owner
Copy Link

@alabuzhev commented on GitHub (Jun 3, 2020):

Best I can do is tell them that there's some community unrest because of this change

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 :(

@alabuzhev commented on GitHub (Jun 3, 2020): > Best I can do is tell them that there's some community unrest because of this change 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 :(
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-Build Issue-Task Needs-Tag-Fix Product-Meta Resolution-Fix-Committed
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#8615
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?