Open vatirim opened 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.
Sure, why not.
How to reproduce:
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: