DevMenuControl.xbf conflict

max-pv commented 3 years ago

I am trying to automate a build for an RNW app that is using packaging project to provide access to Win32 APIs such as registry, WMI, and so on (we are slowly migrating from legacy win32 to UWP). As far as I understand, this is a recommended way of migrating from Win32 to UWP APIs.

The problem I'm facing is that while I can build the packaging project and generate an appx bundle locally, for some reason I can not do that on CI/CD because of the following problem (below a screenshot of MSBuild binary log):

This issue only happens when the build configuration is set to "Release".

I found that there has been a fix for DevMenunControl.xbf already (https://github.com/microsoft/react-native-windows/pull/7377) by @vmoroz, so perhaps I can get some help with my problem as well. I tried copying the diff from the PR into Package.wapproj, but that didn't help, and honestly, it was a shot in the dark 🤷

Here is repo where I've setup a Hello World RNW application, and a Win32 app, wrapped in a packaging project: https://github.com/br4in3x/rnw-devconf

The app doesn't do anything currently, it's a sample of how our enterprise app is structured.

Any help would be greatly appreciated! 🙏

ghost commented 3 years ago

This issue lacks the environment info requested in the bug template. Please edit your issue report to add this information.

If you are using latest version:

npx react-native --version:
npx react-native run-windows --info:

Otherwise if --info doesn't exist:

react-native -v:
npm ls rnpm-plugin-windows:
npm ls react-native-windows:
node -v:
npm -v:
yarn --version:

max-pv commented 3 years ago

npx react-native --version: 5.0.1

npx react-native run-windows --info:

System:
    OS: Windows 10 10.0.19042
    CPU: (16) x64 AMD Ryzen 7 2700 Eight-Core Processor
    Memory: 5.13 GB / 15.95 GB
  Binaries:
    Node: 14.17.3 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.5 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
    npm: 7.7.4 - C:\Program Files\nodejs\npm.CMD
  npmPackages:
    react: 16.13.1 => 16.13.1
    react-native: 0.64.1 => 0.64.1
    react-native-windows: 0.64.6 => 0.64.6
  Installed UWP SDKs:
    10.0.14393.0
    10.0.16299.0
    10.0.17134.0
    10.0.17763.0
    10.0.18362.0
    10.0.19041.0

asklar commented 3 years ago

You may be hitting microsoft/microsoft-ui-xaml#3017 BTW can you upgrade to the latest 0.64 version (0.64.14)

chrisglein commented 3 years ago

Clarifying question: Error message says DevMenuControl.xbf not DevConfControl.xbf. Just at typo in the bug report? Or is ther another file in there?

rectified95 commented 3 years ago

@br4in3x I've just built your app (which I downloaded from: https://github.com/br4in3x/rnw-devconf) in x64 Release mode twice, and didn't see the problem you're reporting.

I did have to play around with enabling preview .NET SDK versions, since you're targeting .NET 6, but after that it built fine. I even did a thorough clean build, including deleting node_modules and all Windows binaries to make sure the iterative build I did the first time didn't resolve the .xbf conflict.

Here's a screenshot for reference:

max-pv commented 3 years ago

@chrisglein Yes, it's DevMenuControl.xbf. Thank you, I fixed the typo 👍

max-pv commented 3 years ago

@asklar thanks, we're currently looking into this problem. I'll add a post to this issue when there is progress on this

max-pv commented 3 years ago

@rectified95 Thanks for checking it out! Yes, I'm using VS 2022, and it comes with .NET 6, sorry.. On the local machine, neither me nor my colleagues have this issue, and you are seeing the same result. The problem that we're getting happens when we try running VSBuild task on the Azure DevOps pipeline (using hosted runners). We were thinking that this maybe somehow related to the outdated version of VS on the agent, but it doesn't seem to be an issue (running VS 2019, MSBuild v16.10.2).

Here is how our VSBuild command looks like:

- task: VSBuild@1
  inputs:
    solution: 'apps/AppName/windows/appname.sln'
    msbuildArgs: '/p:AppxBundlePlatforms="x64" /p:platform=x64 /p:AppxPackageDir="$(build.artifactStagingDirectory)\AppxPackages\\" /p:AppxBundle=Always /p:UapAppxPackageBuildMode=SideloadOnly /p:AppxPackageSigningEnabled=true /p:PackageCertificateThumbprint="" /p:PackageCertificateKeyFile="$(signingCert.secureFilePath)" /v:diag /bl:$(build.artifactStagingDirectory)\$(Build.BuildNumber).binlog'
    platform: 'x64'
    vsVersion: '16.0'
    msbuildArchitecture: 'x86'
    configuration: '$(buildConfiguration)'

And if we look in the binary log produced by this build, here is the full MSBuild command with arguments:

"C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\msbuild.exe"  "C:\agent\_work\1\s\apps\AppName\windows\Package\Package.wapproj" /nologo /nr:false /dl:CentralLogger,"C:\agent\_work\_tasks\VSBuild_71a9a2d3-a98a-4caa-96ab-affca411ecda\1.187.0\ps_modules\MSBuildHelpers\Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll";"RootDetailId=2b748114-6370-48c6-a734-e8e513012883|SolutionDir=C:\agent\_work\1\s\apps\AppName\windows\Package"*ForwardingLogger,"C:\agent\_work\_tasks\VSBuild_71a9a2d3-a98a-4caa-96ab-affca411ecda\1.187.0\ps_modules\MSBuildHelpers\Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll" /p:AppxBundlePlatforms="x64" /p:AppxPackageDir="C:\agent\_work\1\a\AppxPackages\\" /p:AppxBundle=Never /p:UapAppxPackageBuildMode=SideloadOnly /p:AppxPackageSigningEnabled=false /v:diag /bl:C:\agent\_work\1\a\20210730.2.binlog /p:platform="x86" /p:configuration="Release" /p:VisualStudioVersion="16.0" /p:_MSDeployUserAgent="VSTS_c9d6ee57-7704-47af-9a94-39e083fbb1d9_build_4885_0

max-pv commented 3 years ago

@asklar we tried the workaround from the issue you linked and some more things, unfortunately nothing helped..

Here is the list of things tried:

Upgraded react-native-windows to 0.64.14 as suggested here (https://github.com/microsoft/react-native-windows/issues/8333#issuecomment-890371930)
Attempted to set a build target for "_FixMUXPri" as suggested here, but seemed to be limited to issues with direct NuGet project references not react-native-windows internal NuGet conflicts (https://github.com/microsoft/microsoft-ui-xaml/issues/3017#issuecomment-667628206)
Set "/p:VCRTForwarders-IncludeDebugCRT=false" MS Build argument as suggested here (https://github.com/microsoft/microsoft-ui-xaml/issues/3672#issuecomment-756209545)
Build as both x86 and x64 also suggested here (https://github.com/microsoft/microsoft-ui-xaml/issues/3672#issuecomment-756209545)
Add SkipAddPriPayloadFilesToCopyToOutputDirectoryItems to wapproj and csproj as done in the patch here: (https://github.com/microsoft/react-native-windows/pull/7377/files)
Set UseBundle to true to test a bundled Debug application in the pipeline, as suggested here (https://github.com/microsoft/react-native-windows/issues/4266#issuecomment-596266920)

We also found that the patch for the XBF duplicate I mentioned in the original post (https://github.com/microsoft/react-native-windows/pull/7377) is for Microsoft.ReactNative.Uwp.CppLib.props file, however, our application is C# based. Could this be an issue that this patch is not applied for the Microsoft.ReactNative.Uwp.CSharpLib.props and that's why we're getting this error?

asklar commented 3 years ago

re: cpplib vs. csharplib, yes that would make sense since the C# library doesn't get the logic from the cpp lib, could you try applying those two properties to the csharpLib.props file and see if that fixes it?

max-pv commented 3 years ago

@asklar unfortunately that didn't help :(

max-pv commented 3 years ago

I think this might be helpful: when building in debug mode, we don't get errors, but get a bunch of double write warnings, which I think turn into errors when building for release configuration. Had to black out our native module libraries names :)

asklar commented 3 years ago

hm. running out of ideas... the only thing that comes to mind is maybe a VS toolchain difference across versions. WAP is something VS team continues to update, so even across minor versions you might find differences, which would explain why you can only repro in CI and not locally. Can you share what version of VS your CI is using? (you can use the vswhere command / task to find out), and then install that version locally to try to reproduce the problem.

asklar commented 3 years ago

For internal folks, this could be related to https://task.ms/dd/1056299

@sbanni does this look right? Any ideas?

sbanni commented 3 years ago

@asklar That was fixed over a year ago, don't think the CI build would be that old.

@br4in3x I took a look at your sample project and didn't see anything that stood out as an alarm for me, is it possible for you to share a diagnostic (/v:diag) binlog (/bl) with us of the failure?

max-pv commented 3 years ago

@asklar thanks, I'll try to do what you proposed, and will send an update here. @sbanni thanks for taking a look at my project! It's possible to provide a binlog, but not through the GitHub because it's a private enterprise app. Let me ask how we can do that, and I'll get back to you

max-pv commented 3 years ago

@asklar apologies for a delay, here is the version of VS that is used on the CI that I got with & "${Env:ProgramFiles(x86)}\Microsoft Visual Studio\Installer\vswhere.exe":

"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -NoLogo -NoProfile -NonInteractive -ExecutionPolicy Unrestricted -Command ". 'C:\agent\_work\_temp\9b61ec7b-5416-4a9b-b700-ce594ef122bc.ps1'"
Visual Studio Locator version 2.7.1+180c706d56 [query version 2.7.3111.17308]
Copyright (C) Microsoft Corporation. All rights reserved.

instanceId: b51d0486
installDate: 7/16/2021 4:20:28 PM
installationName: VisualStudio/16.10.3+31424.327
installationPath: C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise
installationVersion: 16.10.31424.327
productId: Microsoft.VisualStudio.Product.Enterprise
productPath: C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\devenv.exe
state: 4294967295
isComplete: 1
isLaunchable: 1
isPrerelease: 0
isRebootRequired: 0
displayName: Visual Studio Enterprise 2019
description: Scalable, end-to-end solution for teams of any size
channelId: VisualStudio.16.Release
channelUri: https://aka.ms/vs/16/release/channel
enginePath: C:\Program Files (x86)\Microsoft Visual Studio\Installer\resources\app\ServiceHub\Services\Microsoft.VisualStudio.Setup.Service
releaseNotes: https://docs.microsoft.com/en-us/visualstudio/releases/2019/release-notes-v16.10#16.10.3
thirdPartyNotices: https://go.microsoft.com/fwlink/?LinkId=660909
updateDate: 2021-07-16T16:20:28.3831755Z
catalog_buildBranch: d16.10
catalog_buildVersion: 16.10.31424.327
catalog_id: VisualStudio/16.10.3+31424.327
catalog_localBuild: build-lab
catalog_manifestName: VisualStudio
catalog_manifestType: installer
catalog_productDisplayVersion: 16.10.3
catalog_productLine: Dev16
catalog_productLineVersion: 2019
catalog_productMilestone: RTW
catalog_productMilestoneIsPreRelease: False
catalog_productName: Visual Studio
catalog_productPatchVersion: 3
catalog_productPreReleaseMilestoneSuffix: 1.0
catalog_productSemanticVersion: 16.10.3+31424.327
catalog_requiredEngineVersion: 2.10.2174.31177
properties_campaignId: 
properties_channelManifestId: VisualStudio.16.Release/16.10.3+31424.327
properties_nickname: 
properties_setupEngineFilePath: C:\Program Files (x86)\Microsoft Visual Studio\Installer\setup.exe

chiaramooney commented 1 year ago

This issue should be resolved now once the build is cleaned.

microsoft / react-native-windows

DevMenuControl.xbf conflict #8333