[GH-ISSUE #21] Failed to resolve assembly Windows.Foundation.UniversalApiContract #18

New issue

Closed

opened 2026-02-25 21:30:28 +03:00 by kerem · 2 comments

kerem commented

2026-02-25 21:30:28 +03:00

Owner

Originally created by @cubed-it on GitHub (Apr 22, 2016).
Original GitHub issue: https://github.com/brutaldev/StrongNameSigner/issues/21

Originally assigned to: @brutaldev on GitHub.

Hi there,

I dont know what the issue is, maybe someone could help me with this little problem please. I guess it looks for C:\Program Files (x86)\Windows Kits\10\References\Windows.Foundation.UniversalApiContract\1.0.0.0\Windows.Foundation.UniversalApiContract.winmd
Why it cannot find it? Is there anything I can do?

Thank you!

1> Strong-name signing 'C:\Users\dbr.CONNEXT_NT\.nuget\packages\WinRTXamlToolkit.UWP\2.0.0\lib\uap10.0\WinRTXamlToolkit.dll'... 1>EXEC : warning : Failed to resolve assembly: 'Windows.Foundation.UniversalApiContract, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'

Originally created by @cubed-it on GitHub (Apr 22, 2016). Original GitHub issue: https://github.com/brutaldev/StrongNameSigner/issues/21 Originally assigned to: @brutaldev on GitHub. Hi there, I dont know what the issue is, maybe someone could help me with this little problem please. I guess it looks for C:\Program Files (x86)\Windows Kits\10\References\Windows.Foundation.UniversalApiContract\1.0.0.0\Windows.Foundation.UniversalApiContract.winmd Why it cannot find it? Is there anything I can do? Thank you! `1> Strong-name signing 'C:\Users\dbr.CONNEXT_NT\.nuget\packages\WinRTXamlToolkit.UWP\2.0.0\lib\uap10.0\WinRTXamlToolkit.dll'... 1>EXEC : warning : Failed to resolve assembly: 'Windows.Foundation.UniversalApiContract, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'`

kerem

2026-02-25 21:30:28 +03:00

closed this issue
added the
question
label

kerem commented

2026-02-25 21:30:28 +03:00

Author

Owner

@brutaldev commented on GitHub (Apr 22, 2016):

You need to in include C:\Program Files (x86)\Windows Kits\10\References\Windows.Foundation.UniversalApiContract\1.0.0.0 in your list of directories to process, otherwise it's not going to know where the dependencies are. This is explained under Dealing With Dependencies.

Remember that signed assemblies cannot reference unsigned assemblies, so 'Windows.Foundation.UniversalApiContract' will need to be signed as well since from your error message I can see that it currently isn't (PublicKeyToken=null). So regardless, you will have to include the path to it so that it can be processed along with the assemblies your are trying to sign.

Signing these additional Windows Foundation assemblies may not be a good idea, since other applications and almost certainly other assemblies will be referencing the unsigned versions. You may want to create a private copy of them with your application so you don't sign the one's everyone else is pointing to. Make sure you update the references in your application to the new "private" location.

@brutaldev commented on GitHub (Apr 22, 2016): You need to in include `C:\Program Files (x86)\Windows Kits\10\References\Windows.Foundation.UniversalApiContract\1.0.0.0` in your list of directories to process, otherwise it's not going to know where the dependencies are. This is explained under [Dealing With Dependencies](https://github.com/brutaldev/StrongNameSigner#dealing-with-dependencies). Remember that signed assemblies cannot reference unsigned assemblies, so 'Windows.Foundation.UniversalApiContract' will need to be signed as well since from your error message I can see that it currently isn't (PublicKeyToken=null). So regardless, you will have to include the path to it so that it can be processed along with the assemblies your are trying to sign. Signing these additional Windows Foundation assemblies may not be a good idea, since other applications and almost certainly other assemblies will be referencing the unsigned versions. You may want to create a private copy of them with your application so you don't sign the one's everyone else is pointing to. Make sure you update the references in your application to the new "private" location.

kerem commented

2026-02-25 21:30:28 +03:00

Author

Owner

@cubed-it commented on GitHub (Apr 22, 2016):

Okay, that does not sound like a good idea. But thanks for the detailed answer!

@cubed-it commented on GitHub (Apr 22, 2016): Okay, that does not sound like a good idea. But thanks for the detailed answer!