LinkedResource currently isn't very useful. You cannot set the name in the file table except by specifying the actual path the hash is calculated from.
Unless you change your current working directory to the directory of the assembly, you have to specify the full path to the resource, resulting in that full path being recorded in the assembly - which is definitely never what you want, and breaks terribly if you ever try to deploy such an assembly.
Otherwise if you specify a path that doesn't exists when writing the file you end up with an empty hash. This makes sn.exe (the strong name tool) unable to recalculate the hash as no space is reserved in the assembly.
These changes attempts to fix that by letting the user explicitly specify the name in the file table independently of the file path and the resource name, as well as letting the user specify the hash to be delay calculated (fills in a zero hash) as well as explicitly specifying the hash.
Hey @jbevain could I persuade you into taking a quick look at this? I'm trying to create that piece of "external automation" mentioned in this System.Data.SQLite issue, but I would rather not have to maintain my own fork just for that - and it would probably improve my chances of convincing them to use that for the official builds.
I just want to vote for poizan42 proposal. I am having the same problem!
I'll have a look, thanks for reporting the issue!
Uhm bump? Anything I can do to have this merged?
@jbevain or anyone else with push access?
Make LinkedResource actually useful; allow specifying how to calculat…
…e hash, explicitly setting file name of resource in assembly and allow for delay calculated hash using e.g. sn.exe -Ra
More LinkedResource improvements:
Invalidate old data when HashSource / File is changed.
Detect delay hashed linked resources when reading assembly.
Rebased and fixed indentation