Replies: 2 comments
-
OK, maybe this is what is causing the failure for Uno.WinUI to be recognized by Windows? |
Beta Was this translation helpful? Give feedback.
0 replies
-
Yup. That was it. Updated the Windows package references (in the UnoLibCrossRuntime.csproj): <When Condition="$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'windows'">
<ItemGroup>
<PackageReference Include="Microsoft.WindowsAppSDK" Version="1.3.230724000" />
<PackageReference Include="Microsoft.Windows.SDK.BuildTools" Version="10.0.22621.756" />
</ItemGroup> Thank you for your patience with me. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I've spent a big chunk of time this week investigating the conversion of my collection of cross platform uno libraries from a terrible (but works) home grown collection of build files (.csproj, .props, .targets) to using the build files found in the UnoLib-CrossRuntime template as a foundation. In working on a simple example to demonstrate a different question about using UnoLib-CrossRuntime, I ran into the following scenario:
Above you can see (far right red circle) that I have an UnoLib-CrossRuntime (UnoLibCrossRuntime.*) and I've referenced Uno.WinUI.Markup (center red circle). In the left pane, I'm trying to edit the provided MyCustomControl.cs file and am starting to add
using Uno.WinUI.Markup
when Intellisense complains thatUno.WinUI
namespace isn't available to the Windows, Skia and Wasm targets. So, I smack myself on the forehead and add a reference toUno.WinUI.Markup
to UnoLibCrossRuntime.Skia.csproj and UnoLibCrossRuntime.Wasm.csproj. But:Uno.WinUI
is still not available to the Windows target.My first guess is I did something wrong. Any ideas?
Here's a zip of the solution, if it's helpful: UnoApp1.zip
Beta Was this translation helpful? Give feedback.
All reactions