1

Possible Duplicate: Converting .net exe to native win32 exe?

I have an assembly installed into the GAC that has been modified using reflexil and it is registered for strong name verification skipping using the sn -VR *,<public_token>. The problem is that this assembly had already been ngened and native image exist so the CLR is still loading the "old" version. When the app is copied to another pc with the modified assembly put into its local directory it runs just fine (no strong name verification is being performed by the framework when the assembly is in the local directory). So I tried to uninstall the ngened image using ngen uninstall <assembly name> command and it uninstalled successfully, then install it again using the modified assembly but it gives an error about strong name validation. So now I have a modified assembly in the GAC registered for verification skipping, no ngen image, and application that won't start on that machine. Do you have any solution to this problem. Thanks in advance.

Community
  • 1
  • 1
Mihail Shishkov
  • 14,129
  • 7
  • 48
  • 59
  • possible duplicate of [Converting .net exe to native win32 exe?](http://stackoverflow.com/questions/5687984/converting-net-exe-to-native-win32-exe) –  Feb 11 '14 at 12:10
  • 1
    This "duplicate" question has nothing to do with what I am asking here. – Mihail Shishkov Feb 11 '14 at 12:17
  • What you're asking is effectively impossible. The whole of GAC is built around uniquely identifiable assemblies, which is achieved by a combination of a strong name key (meaning noone without access to your private key can "steal" references to your library) and version. However, if you don't have the assembly in GAC, all is good. So - why do you need the assembly ngen'd / put in GAC? What problem are you actually solving? – Luaan Feb 11 '14 at 12:47
  • I've installed a program, and the installer has put some assemblies in the GAC and generated ngened images of them. There is a bug in one of the assemblies that is fixed (the assembly is modified so strong name is no longer valid) thus that assembly is registered for strong name verification skipping, but the program is still loading the ngened image of that assembly and when the ngened image is removed the program won't start at all, even with the modified assembly still in the GAC. When the app is copied to another PC with all the assemblies in the working directory it is working just fine. – Mihail Shishkov Feb 11 '14 at 13:31
  • 1
    just a thought: what if you uninstall native image before patching the buggy assembly? It should be running with IL, right? Try patching without the Native Image and then attempt NGEN install... My 2 cents... – m_eric Feb 13 '14 at 03:14
  • Thanks m_eric, that was a great idea and it worked. I don't know why i didn't try that in the first place. If you post that as an answer I will accept it. Thanks again. – Mihail Shishkov Feb 14 '14 at 00:43

0 Answers0