-
Notifications
You must be signed in to change notification settings - Fork 675
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
NuGet package lib folder content is not copied to output path of Packaged WinUI 3 apps #6429
Comments
In addition to above, when I create a control library NuGet package that depends on FontAwesome and other packages I receive the following errors:
In this case the |
@evelynwu-msft FYI |
I can confirm this is still not working as of WinAppSDK 1.2.220930.4-preview2. This is caused by this piece in the targets and props files: 1.2.220930.4-preview2\buildTransitive\MrtCore.targets <!-- We want MRT Core to NOT be used in WAP or UWP projects. Instead, we want the in-box PRI generation tooling to be used. -->
<PropertyGroup>
<EnableCoreMrtTooling Condition="'$(EnableCoreMrtTooling)'=='' and '$(WindowsAppContainer)'!='true' and '$(MSBuildProjectExtension)' != '.wapproj'">true</EnableCoreMrtTooling>
</PropertyGroup> 1.2.220930.4-preview2\buildTransitive\Microsoft.Build.Msix.Common.props <!-- We are currently incompatible with the MRT Core tooling (conflicts due to duplicated,
but not identical, logic and race conditions that depend on order of Nuget imports). For now
we will disable the MRT Core tooling with an eye on resolving the incompatibilities once we
share a repo. Tracked by http://task.ms/31928041-->
<EnablePriGenTooling>false</EnablePriGenTooling>
<EnableCoreMrtTooling>false</EnableCoreMrtTooling> Running unpackaged enables This is causing issues for library authors that need to include assets, and forces app developers to run unpackaged. |
Still not working in WindowsAppSDK 1.6.240923002. The problem is now even worse in 1.6 since an indirect reference through a second wrapper library does not work for the decoupled WebView2 versioning made in 1.6 (see microsoft/WindowsAppSDK#4807 and MicrosoftEdge/WebView2Feedback#4837).
The compile error only appears when referencing the nuget package in a library, which makes this bug (#6429) important to solve again. |
Describe the bug
When a NuGet package includes additional files in the lib folder, these files are not copied to the OutputPath of a Packaged WinUI 3 application, but additional files in the lib folder are copied to output path if the project is a Class Library for WinUI 3. In order to get the additional files to be copied to the output of the Packaged app, a class library is needed and a project reference is required from the Packaged app to the Class Library.
In my case I am trying to use
FontAwesome5
version2.1.6
which includes support for WinUI 3. See screenshot below of NuGet package structure.Steps to reproduce the bug
FontAwesome5
version2.1.6
FontAwesome5
folder within output.What works:
FontAwesome5
version2.1.6
FontAwesome5
folder within output.Expected behavior
Additional files within NuGet package should be copied to output regardless of project type.
Screenshots
NuGet package version
WinUI 3 - Windows App SDK 1.0 (If you're seeing your issue in older previews of WinUI 3, please try this release)
Windows app type
Device form factor
Desktop
Windows version
May 2020 Update (19041)
Additional context
No response
The text was updated successfully, but these errors were encountered: