When to Strongly Name an Application Entry Point
Junfeng wonders why you might want to strongly name an exe. Sometimes strong naming your exe can be a very useful, but like any feature it's not necessarily always the tool you need for the job. For instance, when running a simple managed .exe off of your local machine, there's probably not much of a reason to give it a strong name. Junfeng points out that strongly named assemblies are often used when there is a need to share assemblies between applications, by allowing the strongly named assembly to live in the GAC. And it is true that adding an .exe to the GAC isn't a very common scenario; however this is only one of the reasons to provide an assembly with a strong name. Since strong names have many other uses, there are several scenarios under which you would want to strongly name your application's entry point. Some of these are:
- The executable is a friend of another assembly
- You need to elevate the trust of the application the executable is the entry point to
The most obvious reason to sign an exe is when you need to use CAS to increase the level of trust given to an application by the default policy. In fact, in the default policy, we give FullTrust to all assemblies signed with the Microsoft key pair. By signing the various managed tools that ship with the framework and SDK with this key, we are able to ensure that they always run with FullTrust, regardless of what the user changes the grant set of the MyComputer code group to be. In order to do this, you'll need your exe to be signed so that it can be matched with a StrongNameMembershipCondition. As Eric mentioned last time, this topic could be an entire entry on its own ... I'll come back to look at doing this safely next time. For now, lets keep looking at reasons you might want to strong name your exe.
Another reason is the new friend assembly feature of Whidbey. When creating a friend assembly, you use the InternalsVisibleToAttribute to specify the assembly that has access to internal members of your assembly. Although the friend assembly does not have to be strongly named in all cases, it does if the assembly with the InternalsVisibleToAttribute is signed. This means that in the situation where you have a strongly named library (perhaps a library exposing an interface to plug ins), and your application's entry point needs access to its internal members, you'll have to strongly name the application. In fact, when working with friend assemblies, its generally a good idea to strong name in all cases. This prevents a malicious assembly with the same simple name the friend assembly from being able to use your code in ways you hadn't planned for.
That logic actually generalizes out. Basically, if you're using a feature that treats an assembly as "special", you should always strong name that assembly and refer to it by that strong name. For instance, lets say I had a customer tracking application that was able to be extended by arbitrary code. Since access to my object model implies that an the extension code would have access to confidential customer information, I need to control what code can be loaded into my application. To solve this problem, the administrator of my client system has set up a table of trusted assemblies in our customer database. If you're not in that database, you don't get loaded into the customer tracking app. Since the assemblies in the trusted table are treated as special by my application, I should make sure they are strongly named, and always referenced with their full strong name.
When we release beta 2 of Whidbey, we'll take a look at some other features that were designed with this principal in mind, and might also cause you to want to strongly name your application's exe.