Digitally sign CommunityToolkit DLL files

[marticliment]

Describe the bug

Digitally sign the dll files provided in nuget packages, so AVs can trust the files and do not delete the file, causing an application crash.

I am experiencing quite a few crashes because the file CommunityToolkit.WinUI.Controls.TokenizingTextBox.dll could not be found, likely been deleted or blocked by an AV.

Steps to reproduce

N/A

Expected behavior

N/A

Screenshots

See no signatures available:

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 10 21H2 (Build 19044)
• Windows 10 22H2 (Build 19045)
• 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)
• Windows 10, version 2104 (Build 20348)
• Windows 11, version 22H2 (Build 22000)
• Other (specify)

Other SDK version

No response

Visual Studio Version

2022

Visual Studio Build Number

No response

Device form factor

Desktop

Additional context

No response

Help us help you

No, I'm unable to contribute a solution.

[michael-hawker]

@marticliment we don't see this issue:

Can you clarify which version and where you are pulling the package from? Are you pulling nuget packages from a DevOps feeds? As we only sign the MainLatest integrations and the packages on NuGet. Every file in the package should be signed as well as the package itself. I see this validated in NuGet Package Explorer as well:

[marticliment]

My bad. This seems to happen only when publishing with Trim enabled. regular dotnet build does have the appropiate signatures

[michael-hawker]

@marticliment thanks for the clarification.

@Sergio0694 is that expected for trimmed dlls? We of course don't trim the things in NuGet as by definition they have to contain everything. But an app can pull and trim those before it ships, so how does that work afterwards? Is that up to the app to maintain the integrity of its uniquely trimmed component dll afterwards?