search

picrap / SignReferences

Because open source causes CS1577 to strong naming fans.
MIT License
1 stars 0 forks source link

signing fails after update of unsigned assembly #3

Open vatirim opened 9 years ago

vatirim commented 9 years ago

How to reproduce:

  1. add unsigned assembly A to a project P
  2. add SignReferences nuget package and configure signing keys
  3. compile project P -> assembly gets signed
  4. update assembly A (e.g. if A is from an own project -> recompile)
  5. recompile project P
  6. SignReferences no longer tries to sign A

I have tracked this down in the code of SignReferences to AssemblyReference.cs:SaveLoad. This fails if an assembly with the same strong name has been loaded already. Visual Studio seems to reuse msbuild processes between builds and they keep their AppDomain where the previous SignReferences call has loaded it. Work around: kill msbuild process or restart Visual Studio. Just reusing that loaded old assembly does not help because that may have a different signing status than the new one. I think one needs to create a new AppDomain per ProjectSigner instance and make AssemblyReference use it. Working with multiple AppDomains is not easy but I don't see another way. Qu'est ce que t'en dis ? :fr:

vatirim commented 9 years ago

Another strange side effect which may be related: After killing the msbuild process after step 4, SignReferences wants to sign again but this time the ildasm.exe GUI shows up and does not close on its own. The GUI has the assembly open and seems to know the out file name too. Only restarting VS prevents the GUI from showing up. If I use the GUI to save the il file in the temp folder, the rest of the signing works. I thought, maybe some process is locking the assembly to be signed. So I called idasm.exe with the same parameters as does SignReferences, while the idasm GUI was still up. This second call worked as it should and created the .il. Also running the same C# code (to start idasm) in another test project works. Very strange. This means, even if one would fix the issue above of the FileLoadException, there might still be this issue which hits afterwards.

picrap commented 9 years ago

Sure, why not.