The values you are getting are not hashes (as in they are not file content hashes), they are GUIDs. Each DLL - PDB pair is assigned a GUID when they are build. Each build of a DLL has a different GUID, even if they are build from exactly the same source code! This means that the only way you will get the PDB's from the symbol server is if you use exactly the same DLL. The fact that you are getting a completely different GUID indicates to me that you aren't using the same DLL. So the scenario's that I can come up with in that case are:
- Your symbol nuget package has a different dll from your normal nuget package. This seems unlikely if you generate both at the same time, however if you build the package and the binaries more than once, that is possible.
- You are not using the dlls from a nuget package that has had its symbol package registered with your symbol server
- You are not using the dll from a nuget package at all
The reason your 'fix' works is because Visual Studio apparently only uses the GUID to create the symbol search path but doesn't check the PDB GUID when it loads it. In other words, it assumes (fairly) that the symbol server puts the symbols in the correct location.
The best way to fix your problem would be to find out where you are getting the different DLLs from. You can use the dumpbin utility to find out which PDB is linked to which DLL by using
dumpbin.exe /headers mypackage.dll
That should produce an output that contains somewhere the path of the PDB file and(!) the GUID that links the DLL and the PDB. If you compare the GUIDs and the timestamps of the DLL on your computer with the ones in the DLL / PDB on the symbol server you should be able to figure out where things went wrong.