Fix missing .xaml references #11805
Merged
Fix missing .xaml references #11805
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
zadjii-msft
added
Area-Build
miniksa
previously approved these changes
Nov 22, 2021
lhecker
reviewed
Nov 22, 2021
| --> | ||
|
|
||
| <ProjectReference Include="$(OpenConsoleDir)src\cascadia\TerminalControl\dll\TerminalControl.vcxproj"> | ||
| <!-- Private:false and ReferenceOutputAssembly:false, in combination with |
There was a problem hiding this comment.
huh, I was the murderer in 20bfcce
zadjii-msft
added
the
AutoMerge
|
Hello @zadjii-msft! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
ghost
pushed a commit
that referenced
this pull request
Nov 23, 2021
I'm working on making the FastUpToDate check in Vs work for the Terminal project. This is one of a few PRs in this area. FastUpToDate lets vs check quickly determine that it doesn't need to do anything for a given project. However, a few of our projects don't produce all the right artifacts, or check too many things, and this eventually causes the `wapproj` to rebuild, EVERY TIME YOU F5 in VS. This third PR deals with the Actual fast up to date check for the CascadiaPackage.wapproj. When #11804, #11805 and this PR are all merged, you should be able to just F5 the Terminal in VS, and then change NOTHING, and F5 it again, without doing a build at all. The wapproj `GetResolvedWinMD` target tries to get a winmd from every cppwinrt executable we put in the package. But we DON'T produce a winmd. This makes the FastUpToDate check fail every time, and leads to the whole wapproj build running even if you're just f5'ing the package. EVEN AFTER A SUCCESSFUL BUILD. Setting GenerateWindowsMetadata=false is enough to tell the build system that we don't produce one, and get it off our backs. ### teams chat where we figured this out [3:38 PM] Dustin Howett however, that's not the only thing that "GetTargetPath" checks. [3:38 PM] Dustin Howett oh yeah more info: wapproj calls GetTargetPath on all projects it references [3:38 PM] Dustin Howett when it calls GTP on WindowsTerminal.vcxproj it is getting back a winmd (!) [3:39 PM] Dustin Howett here's the magic [3:39 PM] Dustin Howett  [3:39 PM] Dustin Howett it checks if any Link items specify GenerateWindowsMetadata 
lhecker
approved these changes
Nov 23, 2021
ghost
merged commit 
This pull request was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I'm working on making the FastUpToDate check in Vs work for the Terminal project. This is one of a few PRs in this area.
FastUpToDate lets vs check quickly determine that it doesn't need to do anything for a given project.
However, a few of our projects don't produce all the right artifacts, or check too many things, and this eventually causes the
wapprojto rebuild, EVERY TIME YOU F5 in VS.This second PR deals with some projects MYSTERIOUSLY depending on the
.xamlfiles fromTerminal.Control, even when they by all accounts shouldn't. TerminalSettingsModel ISN'T EVEN A XAML project, so I have no idea why it thinks it needs these xaml files. The TerminalAppLib project thinking it needs them - makes more sense, but is still confusing.Below are my verbatim notes, which led to the solution in this PR.
Just copying the xaml files from
bin\x64\debug\microsoft.terminal.control\microsoft.terminal.control\*.xamltobin\x64\debug\microsoft.terminal.settings.model.lib\microsoft.terminal.controlseemed to fix this.the .xbfs were already there
It's very unclear why these were ever needed? They aren't used in the build for
Microsoft.Terminal.Settings.Model.Lib. They aren't copied as a part of the build either - no .xaml files are copied at all in factDoes TSE have these .xamls in it's output?
UPDATE: checking out main, and building again - ran into this again. WHY??
Cleaned again, then built TerminalApp.vcxproj. File is no longer needed? nothing makes sense.
obj\x64\Debug\Microsoft.Terminal.Settings.Model.Lib\Microsof.CA5CAD1A.tlog\Microsoft.Terminal.Settings.Model.Lib.write.1u.tlog:From the build:
21>Project is not up-to-date: build output 'c:\users\migrie\dev\public\terminal\bin\x64\debug\terminalapplib\microsoft.terminal.control\searchboxcontrol.xaml' is missingas well.