strong name validation user feedback RRS feed

  • Question

  • In an attempt to see the usage of strong name I wanted to build a small experiment.

    Create a simple .NET 2.0 C# forms application that uses an AxInterop and Interop assemblies. All three assemblies are signed.

    Ran the application and the form is shown as expected.

    Then I made a change to source code of the AxInterop\Interop, recompiled the code and gave the assembly a new version number.

    Ran the application from explorer and the application did not start and no error message was displayed. First I though, did I really double click on the icon, so I tried again but the same happend. Even tried console mode but no feedback. Checked fuslogvw output and it states correctly that assembly reference did not match assembly definition and that there was revision number mismatch. What was odd is the lack of user feedback. Is this correct behaviour? A regular user would not have a clue why the application did not start as expected.

    Thursday, December 22, 2011 10:03 AM

All replies

  • From what I can understand the CLR decrypts the hash key included in the assembly using the public key, calculates a hash key of the assembly and compares the two. If they are the same everything works fine. What should happen if they are different, i.e. the assembly has been changed for whatever reason? Does the CLR kill the application in this situation or does the context matter? For instance, you might have a huge with a tree structure of assemblies, if a leaf assebly on level 6 fails due to strong name it seems odd to kill the application. Does the hosting .NET assembly have any inpact on the behaviour when strong name validation fails?

    Friday, December 23, 2011 8:01 AM
  • Firstly, you can catch a dump file to check whether there happens any errors. Use ADPlus to capture a dump file. ADPlus is shipped with Debugging Tools For Windows which available at here, you can try this command to capture a dump file:


    adplus -crash -o d:\dumps -pn MyApplication


    Then, I think that there are some errors or exceptions cause the application exits, but some codes in your application can handle the exceptions and exit silently. I see that your application is build as .NET 2.0. In the .NET Framework version 2.0, the common language runtime allows most unhandled exceptions in threads to proceed naturally.


    Exceptions in Managed Threads

    Paul Zhou [MSFT]
    MSDN Community Support | Feedback to us
    • Proposed as answer by Paul Zhou Tuesday, January 3, 2012 7:09 AM
    Monday, December 26, 2011 8:53 AM