Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update Testing/Sample App Toolkit Dependencies #39

Closed
22 tasks
michael-hawker opened this issue Mar 28, 2023 · 0 comments · Fixed by #41
Closed
22 tasks

Update Testing/Sample App Toolkit Dependencies #39

michael-hawker opened this issue Mar 28, 2023 · 0 comments · Fixed by #41

Comments

@michael-hawker
Copy link
Member

Describe the bug

We kind of have a chicken-and-egg problem here. We needed some Toolkit code in order to make it nicer to work with our sample app and testing infrastructure while building it.

However, this code also lives in the Toolkit and needs to be ported/updated itself. This makes it hard to test and work with as we now have conflicts between the old version with dual namespaces and the new version with unified namespaces.

We need to solve two problems with this issue:

  • Migrate to the initial unified namespace package (coming soon™)
  • Provide a property flag <ExcludeToolkitNuGetDependencies>true</ExcludeToolkitNuGetDependencies> (or something) which guards including that package in the dependent tooling bits (tests/sample app) - would probably live in the common props in the root I guess? We'll have to think about where this needs to be set and how this works a bit more.

We need the later so that when we're actually building the sample app or tests within the single or all component projects which actually include the source for that code that we have a single reference. i.e. the source itself. Otherwise if we also include the package there'll be a conflict between the pre-built version and the source code (which we may have updated and want to test).

Therefore when the flag is enabled, we can put it in the csproj for any dependent packages we're using so that within the source repo, the source gets used, and for other things like Labs where that source doesn't live it'll pick up whatever last version of the package we've setup in the tooling module here.

Steps to reproduce

N/A

Expected behavior

Able to work on/test code that we depend on in our tooling.

Screenshots

No response

Code Platform

  • UWP
  • WinAppSDK / WinUI 3
  • Web Assembly (WASM)
  • Android
  • iOS
  • MacOS
  • Linux / GTK

Windows Build Number

  • Windows 10 1809 (Build 17763)
  • Windows 10 1903 (Build 18362)
  • Windows 10 1909 (Build 18363)
  • Windows 10 2004 (Build 19041)
  • Windows 10 20H2 (Build 19042)
  • Windows 10 21H1 (Build 19043)
  • Windows 11 21H2 (Build 22000)
  • Other (specify)

Other Windows Build number

No response

App minimum and target SDK version

  • Windows 10, version 1809 (Build 17763)
  • Windows 10, version 1903 (Build 18362)
  • Windows 10, version 1909 (Build 18363)
  • Windows 10, version 2004 (Build 19041)
  • Other (specify)

Other SDK version

No response

Visual Studio Version

No response

Visual Studio Build Number

No response

Device form factor

No response

Additional context

No response

Help us help you

Yes, I'd like to be assigned to work on this item.

michael-hawker added a commit to CommunityToolkit/Windows that referenced this issue Mar 31, 2023
We need to come back and finish porting/fixing these tests once we sort out the namespace conflict by having the old versions in the dependencies of the tooling

See: CommunityToolkit/Tooling-Windows-Submodule#39
michael-hawker added a commit to CommunityToolkit/Windows that referenced this issue Apr 4, 2023
We need to come back and finish porting/fixing these tests once we sort out the namespace conflict by having the old versions in the dependencies of the tooling

See: CommunityToolkit/Tooling-Windows-Submodule#39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
1 participant