🙋 Feature Request
😯 Problem to Solve
NI clients of the Nimble/Spright/OkBlazor packages need those assemblies signed with the NI certificate, so that end users don't see messages about unsigned/untrusted code. The Nimble repo, being public, does not have access to the NI certificate to do the signing.
💁 Proposed Solution
RDSS (Neil) has some support in the works for signing binaries from a GitHub Action. Once that is available, we should have our pipeline do the signing and publish the signed binaries/packages to Nuget.org (which would also include renaming the package names and assembly namespaces to be, i.e. NationatInstruments.NimbleBlazor, etc).
Some alternates were discussed in an HLD (Draft PR) which are not currently being pursued in favor of the GitHub Action approach. As a continued workaround, end applications can sign assemblies in their applications.
Workaround
Sign assemblies used by an application using standard signing workflows on an AzDo CI, see example PR.
🙋 Feature Request
😯 Problem to Solve
NI clients of the Nimble/Spright/OkBlazor packages need those assemblies signed with the NI certificate, so that end users don't see messages about unsigned/untrusted code. The Nimble repo, being public, does not have access to the NI certificate to do the signing.
💁 Proposed Solution
RDSS (Neil) has some support in the works for signing binaries from a GitHub Action. Once that is available, we should have our pipeline do the signing and publish the signed binaries/packages to Nuget.org (which would also include renaming the package names and assembly namespaces to be, i.e.
NationatInstruments.NimbleBlazor, etc).Some alternates were discussed in an HLD (Draft PR) which are not currently being pursued in favor of the GitHub Action approach. As a continued workaround, end applications can sign assemblies in their applications.
Workaround
Sign assemblies used by an application using standard signing workflows on an AzDo CI, see example PR.