Help with warnings getting started building the project

[EmJayGee]

Hi, I'm getting set up in the environment to try building to see if I can lend a hand on some of the low hanging fruit issues and I'm running into a few issues getting a good build.

I'm going to start from the beginning. First, opening the solution in VS and then getting it to install the missing components is required, it's not possible to proactively install those components from what I can tell. Is that right? That was surprising.

Second, when using razzle to set up the environment (I'm old school NT person so razzle and bcz make me feel warm and fuzzy inside even if it's just a facade), I get a warning:

C:\Users\micha\source\repos\terminal>tools\razzle
Setting up dev environment...
WARNING: Error reading msbuild project information, ensure that your input solution or project file is valid. NETCore and UAP projects will be skipped, only packages.config files will be restored.
The dev environment is ready to go!
C:\Users\micha\source\repos\terminal>

Warnings are never good things to ignore; I get this problem on both my desktop and laptop. (my laptop is ridiculously fast)

Here are more warnings with a debug build:

87>C:\Users\micha\source\repos\terminal\src\cascadia\TerminalSettingsEditor\AddProfile.xaml(63,56): XamlCompiler warning WMC1506: OneWay bindings require at least one of their steps to support raising notifications when their value changes [C:\Users\micha\source\repos\terminal\src\cascadia\TerminalSettingsEditor\Microsoft.Terminal.Settings.Editor.vcxproj]

and then with a release build, I was able to repro the warnings I got on the debug build on my desktop:

Build succeeded.

       "C:\Users\micha\source\repos\terminal\OpenConsole.sln" (Clean;Build target) (1) ->
       "C:\Users\micha\source\repos\terminal\src\host\ft_host\Host.FeatureTests.vcxproj.metaproj" (Clean;Build target)
       (15) ->
       "C:\Users\micha\source\repos\terminal\src\tools\nihilist\Nihilist.vcxproj" (Clean target) (28) ->
       (CoreCppClean target) ->
         C:\Program Files\Microsoft Visual Studio\2022\Professional\MSBuild\Microsoft\VC\v170\Microsoft.CppClean.target
       s(77,5): warning : Access to the path 'c:\users\micha\source\repos\terminal\bin\x64\debug\arm64\conduit.environm
       ent.dll' is denied. [C:\Users\micha\source\repos\terminal\src\tools\nihilist\Nihilist.vcxproj]
         C:\Program Files\Microsoft Visual Studio\2022\Professional\MSBuild\Microsoft\VC\v170\Microsoft.CppClean.target
       s(77,5): warning : Access to the path 'c:\users\micha\source\repos\terminal\bin\x64\debug\arm64\te.processhost.u
       ap.exe' is denied. [C:\Users\micha\source\repos\terminal\src\tools\nihilist\Nihilist.vcxproj]
         C:\Program Files\Microsoft Visual Studio\2022\Professional\MSBuild\Microsoft\VC\v170\Microsoft.CppClean.target
       s(77,5): warning : Access to the path 'c:\users\micha\source\repos\terminal\bin\x64\debug\arm\netfx4.5\wex.commo
       n.managed.dll' is denied. [C:\Users\micha\source\repos\terminal\src\tools\nihilist\Nihilist.vcxproj]
         C:\Program Files\Microsoft Visual Studio\2022\Professional\MSBuild\Microsoft\VC\v170\Microsoft.CppClean.target
       s(77,5): warning : Access to the path 'c:\users\micha\source\repos\terminal\bin\x64\debug\arm\te.model.managed.d
       ll' is denied. [C:\Users\micha\source\repos\terminal\src\tools\nihilist\Nihilist.vcxproj]

Are these "expected warnings"?

Thanks,
Mike

[zadjii-msft]

opening the solution in VS and then getting it to install the missing components is required, it's not possible to proactively install those components from what I can tell. Is that right?

To the best of my knowledge, there's not another way for us to script the install of those components. At least the .vsconfig makes the process a lot easier. If there's a commandline we can run to install those components, I'd be all ears (@crutkas this might play into a discussion we were having two weeks ago)

WARNING: Error reading msbuild project information

This one I've seen for a while now, but it's never really affected anything so far as I can tell. #12707 may help here, not sure though. If you wanna help figure out the root cause here, I'm all ears.

XamlCompiler warning WMC1506: OneWay bindings

Yea we should probably fix those 😋

warning : Access to the path

Those are certainly not expected! I don't think I've ever seen that, unless like, those files were in use by the OS while the build was running. But it seems extremely unlikely that the ARM version of TAEF in our repo was in use while you were building....

[EmJayGee]

I am building on Windows 10; I don't know if that perhaps makes a difference. I tried setting the whole terminal directory tree to be hands off for defender in case that was the problem but I thought pretty much all the issues with it causing access denied had been fixed in the win8 timeframe. I checked permissions on the files and I have full control on them. I didn't check attributes, d'oh! so they might be read only but I don't know why the tools might be opening the files for write access.

I'm not running any antivirus other than defender.

I can install the file monitor from sysinternals and see what's really going on with file accesses causing conflicts but I thought it was pretty weird that something would be accessing those paths and getting access denied too.

I had studiously avoided learning much about msbuild hoping it would go away but that seems to not be the case so I guess I need to put my big boy pants on and figure out what's going on.

I'll see what I can do and update the discussion as I find more data.

Mike

[zadjii-msft]

If you can just delete those files manually in explorer, then try building again, maybe the issue will just go away? Who knows 🤷 Maybe it'll give you more info as to who has the file locked at least.

[EmJayGee]

I haven't tried this yet, more issues incoming.

[EmJayGee]

I can't run the test cases and after doing some amount of research, it looks like a lot of people get the dependencies installed for the first time by building the solutions for things like this in visual studio and then running them. So I tried that and I'm hitting more problems. This is with the latest VS and I have a separate clean enlistment. I'm building x64 debug.

10>WindowsTerminal.vcxproj -> C:\Users\micha\source\repos\Clean\terminal\bin\x64\Debug\WindowsTerminal\WindowsTerminal.exe
11>------ Build started: Project: TestHostApp, Configuration: Debug x64 ------
12>------ Build started: Project: CascadiaPackage, Configuration: Debug x64 ------
11>TestHostApp.vcxproj -> C:\Users\micha\source\repos\Clean\terminal\bin\x64\Debug\TestHostApp\TestHostApp.exe
11>C:\Program Files\Microsoft Visual Studio\2022\Professional\MSBuild\Microsoft\VisualStudio\v17.0\AppxPackage\Microsoft.AppXPackage.Targets(1946,5): error APPX1111: Payload contains two or more files with the same destination path 'Microsoft.Terminal.Settings.Editor\ColorSchemes.xbf', but they are different sizes. Source files: 
11>C:\Program Files\Microsoft Visual Studio\2022\Professional\MSBuild\Microsoft\VisualStudio\v17.0\AppxPackage\Microsoft.AppXPackage.Targets(1946,5): error APPX1111: C:\Users\micha\source\repos\Clean\terminal\bin\x64\Debug\Microsoft.Terminal.Settings.Editor\Microsoft.Terminal.Settings.Editor\ColorSchemes.xbf
11>C:\Program Files\Microsoft Visual Studio\2022\Professional\MSBuild\Microsoft\VisualStudio\v17.0\AppxPackage\Microsoft.AppXPackage.Targets(1946,5): error APPX1111: C:\Users\micha\source\repos\Clean\terminal\bin\x64\Debug\TerminalApp\Microsoft.Terminal.Settings.Editor\ColorSchemes.xbf
11>Done building project "TestHostApp.vcxproj" -- FAILED.
========== Build: 8 succeeded, 1 failed, 69 up-to-date, 3 skipped ==========

[zadjii-msft]

Ah, this stuff happens all the time. I haven't figured out why - I think it's because we're a little off the rails of a standard project setup here. Something causes some duplicate .xbfs to get generated and then also referenced by another project. It's totally harmless, just a build tools issue. Usually the easiest fix is some variation of

del bin\x64\Debug\Microsoft.Terminal.settings.editor\Microsoft.Terminal.settings.editor\*.xbf

[EmJayGee]

I find this answer somewhat unsettling but I will give it a go. It seems like it would hurt reproducibility of the build if this happens regularly. Do you know what causes it?

[zadjii-msft]

Meh, it happens randomly, and only on partial rebuilds. I haven't the faintest idea who in the toolchain is responsible, but I'd bet it's XAML.