When using arcade to publish a project that sets AssemblyOriginatorKeyFile, StrongName.targets overrides the key file (because arcade imports set a default value for StrongNameKeyId):
|
<AssemblyOriginatorKeyFile>$(MSBuildThisFileDirectory)snk/35MSSharedLib1024.snk</AssemblyOriginatorKeyFile> |
I believe StrongName.targets should not be setting properties as this violates the convention that static properties are computed in props files. Maybe this logic should be moved to StrongName.props, which would allow my project's setting of AssemblyOriginatorKeyFile to take precedence.
I can work around this by:
- setting
StrongNameKeyId in my project to some unknown string, preventing arcade's override, and
- setting
PublicKey and PublicKeyToken to some unknown string to satisfy the check in
|
<Error Condition="'$(SignAssembly)' != 'false' and |
|
('$(PublicKey)' == '' or '$(PublicKeyToken)' == '' or '$(AssemblyOriginatorKeyFile)' == '')" |
I may have missed something, but I couldn't find any place where PublicKey or PublicKeyToken were actually used, so I think those shouldn't be required to be set in the first place. edit: they're used in the arcade InternalsVisibleTo generator - see below.
When using arcade to publish a project that sets
AssemblyOriginatorKeyFile,StrongName.targetsoverrides the key file (because arcade imports set a default value forStrongNameKeyId):arcade/src/Microsoft.DotNet.Arcade.Sdk/tools/StrongName.targets
Line 35 in 9800953
I believe
StrongName.targetsshould not be setting properties as this violates the convention that static properties are computed in props files. Maybe this logic should be moved toStrongName.props, which would allow my project's setting ofAssemblyOriginatorKeyFileto take precedence.I can work around this by:
StrongNameKeyIdin my project to some unknown string, preventing arcade's override, andPublicKeyandPublicKeyTokento some unknown string to satisfy the check inarcade/src/Microsoft.DotNet.Arcade.Sdk/tools/StrongName.targets
Lines 84 to 85 in 9800953
I may have missed something, but I couldn't find any place whereedit: they're used in the arcadePublicKeyorPublicKeyTokenwere actually used, so I think those shouldn't be required to be set in the first place.InternalsVisibleTogenerator - see below.