Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

MUXControlsInnerLoop solution fails to build

See original GitHub issue

Describe the bug The MUXControls solution builds successfully, and the test app deploys and runs properly. However, the MUXControlsInnerLoop solution fails to build with the following errors:

1>\microsoft-ui-xaml\BuildOutput\Debug\x64\Microsoft.UI.Xaml\XamlMetadataProviderGenerated.cpp(424,1): error C2872: 'ElementFactoryGetArgs': ambiguous symbol
1>\microsoft-ui-xaml\BuildOutput\Debug\x64\Microsoft.UI.Xaml\XamlMetadataProviderGenerated.cpp(425,1): error C2872: 'ElementFactoryGetArgs': ambiguous symbol
1>\microsoft-ui-xaml\BuildOutput\Debug\x64\Microsoft.UI.Xaml\XamlMetadataProviderGenerated.cpp(432,1): error C2872: 'ElementFactoryGetArgs': ambiguous symbol
1>\microsoft-ui-xaml\BuildOutput\Debug\x64\Microsoft.UI.Xaml\XamlMetadataProviderGenerated.cpp(433,1): error C2872: 'ElementFactoryGetArgs': ambiguous symbol
1>\microsoft-ui-xaml\BuildOutput\Debug\x64\Microsoft.UI.Xaml\XamlMetadataProviderGenerated.cpp(461,1): error C2872: 'ElementFactoryRecycleArgs': ambiguous symbol
1>\microsoft-ui-xaml\BuildOutput\Debug\x64\Microsoft.UI.Xaml\XamlMetadataProviderGenerated.cpp(462,1): error C2872: 'ElementFactoryRecycleArgs': ambiguous symbol
1>\microsoft-ui-xaml\BuildOutput\Debug\x64\Microsoft.UI.Xaml\XamlMetadataProviderGenerated.cpp(469,1): error C2872: 'ElementFactoryRecycleArgs': ambiguous symbol
1>\microsoft-ui-xaml\BuildOutput\Debug\x64\Microsoft.UI.Xaml\XamlMetadataProviderGenerated.cpp(470,1): error C2872: 'ElementFactoryRecycleArgs': ambiguous symbol

Steps to reproduce the bug

Clone this repo (commit 865e4fcc00e8649baeaec1ba7daeca398671aa72)
Open the MUXControls solution and build it.
Deploy the MUXControlsTestApp project.
Open the MUXControlsInnerLoop solution and build it. Observe that it fails.

Expected behavior MUXControlsInnerLoop should build successfully on a fresh clone if the MUXControls solution builds successfully.

Version Info Commit 865e4fcc00e8649baeaec1ba7daeca398671aa72

Windows 10 version	Saw the problem?
Insider Build (xxxxx)
May 2020 Update (19041)	Yes
November 2019 Update (18363)
May 2019 Update (18362)
October 2018 Update (17763)
April 2018 Update (17134)
Fall Creators Update (16299)
Creators Update (15063)

Device form factor	Saw the problem?
Desktop	Yes
Xbox	N/A
Surface Hub	N/A
IoT	N/A

Additional context

Issue Analytics

State:
Created 3 years ago
Comments:5 (5 by maintainers)

Top GitHub Comments

1reaction

yoshiaskcommented, Jun 29, 2020

Deleting the BuildOutput folder fixes both solutions! It would be great if the docs included this, at least until both solutions play nicer together. I’ll open a PR to add this to the developer guide.

0reactions

kmahonecommented, Jun 29, 2020

I agree that the documentation should be improved here. The MUXControlsInnerLoop.sln is a little bit of a hack. The issue is that it is identical to MUXControls.sln, just with various pieces optionally removed. So they share the same build output locations (including objs, temporary files, generated files, etc.). So before using MUXControlsInnerLoop.sln, it definitely makes sense to fully clean the repo (e.g. with ‘git clean -dfx’, or just by deleting the BuildOutput directory.