Fix unique ID #8963
Fix unique ID #8963
Conversation
TIHan
left a comment
TIHan
left a comment
There was a problem hiding this comment.
This looks good to me!
We should always get the right stamp no matter if it was a "PublicKey" or "PublicKeyToken". Very simple.
|
Still seeing this issue when using a nightly installer (https://aka.ms/dotnet/net5/dev/Sdk/dotnet-sdk-win-x64.exe). Is the fix not included in there? |
|
The fix merged into F# 5 builds in version 11.0.0-beta.20217.1, so anything after that will have it. That build was inserted into the SDK build here. I'm currently trying to track how/where those builds happen to see how far away from the nightly installer it is. I'll keep looking and reply here as soon as I can find it. |
|
Just checked the latest nightly that you mentioned at at the time of this post it only contains F# 20214.4, and build 20217.1 contains this fix. I'm not sure when they promote a new build for download, but I'd keep checking back. |
|
Digging a little more it looks like that SDK build was merged into the installer just an hour ago so I'd expect a new build within a day or so. |
|
Thanks a lot. |
5 participants
Fixes #8881 and #8743
This occurred because when we load an assembly reference from a local dll we get it including the public key, but when it is an imported assembly ref, it contains just the pktoken. The code that we use to determine reference equality When writing the assembly was using the full PublicKey information, I.e PublicKey and PublicKeyToken. This resulted in references from imported assemblies not matching references from local assemblies.
Anyway the fix was fairly straightforward, always use the public key token for testing assembly equality,
/cc @kerams , @cartermp