[PR #104] [MERGED] Update custom attribute fixing to include every custom attribute #109

Closed
opened 2026-02-25 21:30:43 +03:00 by kerem · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/brutaldev/StrongNameSigner/pull/104
Author: @Chri-s
Created: 7/19/2025
Status: Merged
Merged: 7/22/2025
Merged by: @brutaldev

Base: masterHead: more-custom-attributes


📝 Commits (1)

  • 0216f8f Update custom attribute fixing to include every custom attribute

📊 Changes

10 files changed (+401 additions, -38 deletions)

View changed files

📝 src/Brutal.Dev.StrongNameSigner.TestAssembly.A/A.cs (+35 -1)
📝 src/Brutal.Dev.StrongNameSigner.TestAssembly.A/Brutal.Dev.StrongNameSigner.TestAssembly.A.csproj (+1 -0)
src/Brutal.Dev.StrongNameSigner.TestAssembly.A/CustomTypeAttribute.cs (+18 -0)
📝 src/Brutal.Dev.StrongNameSigner.TestAssembly.A/Properties/AssemblyInfo.cs (+2 -1)
src/Brutal.Dev.StrongNameSigner.Tests/AppDomainAssemblyTester.cs (+87 -0)
📝 src/Brutal.Dev.StrongNameSigner.Tests/Brutal.Dev.StrongNameSigner.Tests.csproj (+1 -0)
📝 src/Brutal.Dev.StrongNameSigner.Tests/SignAssemblyTests.cs (+122 -0)
📝 src/Brutal.Dev.StrongNameSigner.Tests/TestAssemblies/Brutal.Dev.StrongNameSigner.TestAssembly.A.dll (+0 -0)
📝 src/Brutal.Dev.StrongNameSigner.Tests/TestAssemblies/Brutal.Dev.StrongNameSigner.TestAssembly.A.pdb (+0 -0)
📝 src/Brutal.Dev.StrongNameSigner/SigningHelper.cs (+135 -36)

📄 Description

This pull request adds support for handling custom attributes with type references at all levels in signed assemblies, including assembly, module, type, and method levels. It also adds test coverage to validate these changes.

Previously, custom attributes containing type references were only updated at the assembly level during signing. This limitation caused issues when attributes referencing types from other assemblies appeared at other levels.

In the System.Waf project, the class MefSettingsService uses an [Export(typeof(ISettingsService))] attribute.
ISettingsService is defined in a separate assembly (System.Waf.Core). When both System.Waf.Wpf and System.Waf.Core are signed, the ExportAttribute in System.Waf.Wpf still points to the unsigned ISettingsService, because the attribute was not updated during signing.

As a result, MEF fails to resolve the export and throws an exception at runtime.

With this PR, type references inside custom attributes across all levels will be correctly updated to reference the signed assemblies. This ensures MEF resolves types correctly after signing.

To add tests for this, I had to update the Brutal.Dev.StrongNameSigner.TestAssembly.A.dll file. If you don't want to trust my updated binary file, you can recompile the TestAssembly.A project and copy that dll to the TestAssemblies folder.


🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/brutaldev/StrongNameSigner/pull/104 **Author:** [@Chri-s](https://github.com/Chri-s) **Created:** 7/19/2025 **Status:** ✅ Merged **Merged:** 7/22/2025 **Merged by:** [@brutaldev](https://github.com/brutaldev) **Base:** `master` ← **Head:** `more-custom-attributes` --- ### 📝 Commits (1) - [`0216f8f`](https://github.com/brutaldev/StrongNameSigner/commit/0216f8f18afece9f7187f81b13b62bc0f9b462cf) Update custom attribute fixing to include every custom attribute ### 📊 Changes **10 files changed** (+401 additions, -38 deletions) <details> <summary>View changed files</summary> 📝 `src/Brutal.Dev.StrongNameSigner.TestAssembly.A/A.cs` (+35 -1) 📝 `src/Brutal.Dev.StrongNameSigner.TestAssembly.A/Brutal.Dev.StrongNameSigner.TestAssembly.A.csproj` (+1 -0) ➕ `src/Brutal.Dev.StrongNameSigner.TestAssembly.A/CustomTypeAttribute.cs` (+18 -0) 📝 `src/Brutal.Dev.StrongNameSigner.TestAssembly.A/Properties/AssemblyInfo.cs` (+2 -1) ➕ `src/Brutal.Dev.StrongNameSigner.Tests/AppDomainAssemblyTester.cs` (+87 -0) 📝 `src/Brutal.Dev.StrongNameSigner.Tests/Brutal.Dev.StrongNameSigner.Tests.csproj` (+1 -0) 📝 `src/Brutal.Dev.StrongNameSigner.Tests/SignAssemblyTests.cs` (+122 -0) 📝 `src/Brutal.Dev.StrongNameSigner.Tests/TestAssemblies/Brutal.Dev.StrongNameSigner.TestAssembly.A.dll` (+0 -0) 📝 `src/Brutal.Dev.StrongNameSigner.Tests/TestAssemblies/Brutal.Dev.StrongNameSigner.TestAssembly.A.pdb` (+0 -0) 📝 `src/Brutal.Dev.StrongNameSigner/SigningHelper.cs` (+135 -36) </details> ### 📄 Description This pull request adds support for handling custom attributes with type references at all levels in signed assemblies, including assembly, module, type, and method levels. It also adds test coverage to validate these changes. Previously, custom attributes containing type references were only updated at the assembly level during signing. This limitation caused issues when attributes referencing types from other assemblies appeared at other levels. In the [System.Waf](https://github.com/jbe2277/waf) project, the class [MefSettingsService](https://github.com/jbe2277/waf/blob/6b1c5cc274452016ad9e71085db5cb89dc52655a/src/System.Waf/System.Waf/System.Waf.Wpf/Presentation/Services/MefSettingsService.cs#L7) uses an `[Export(typeof(ISettingsService))]` attribute. `ISettingsService` is defined in a separate assembly (System.Waf.Core). When both System.Waf.Wpf and System.Waf.Core are signed, the ExportAttribute in System.Waf.Wpf still points to the unsigned `ISettingsService`, because the attribute was not updated during signing. As a result, MEF fails to resolve the export and throws an exception at runtime. With this PR, type references inside custom attributes across all levels will be correctly updated to reference the signed assemblies. This ensures MEF resolves types correctly after signing. To add tests for this, I had to update the [Brutal.Dev.StrongNameSigner.TestAssembly.A.dll](https://github.com/brutaldev/StrongNameSigner/compare/master...Chri-s:StrongNameSigner:more-custom-attributes?expand=1#diff-3a131a6649977e45059aa749f4a7a20e75ad1a6cc047a6fa9f7f875d770d683b) file. If you don't want to trust my updated binary file, you can recompile the TestAssembly.A project and copy that dll to the TestAssemblies folder. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
kerem 2026-02-25 21:30:43 +03:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/StrongNameSigner#109
No description provided.