Publisher Policy

In general, the publisher of an assembly simply sent a new version of the assembly to the administrator, who installed the assembly and manually edited the application’s or machine’s XML configuration files. In general, when a publisher fixes a bug in an assembly, the publisher would like an easy way to package and distribute the new assembly to all of the users. But the publisher also needs a way to tell each user’s CLR to use the new assembly version instead of the old assembly version. Sure, each user could modify his or her application’s or machine’s XML configuration file, but this is terribly inconvenient and error prone. What the publisher needs is a way to create policy information that is installed on the user’s computer when the new assembly is installed.

A publisher policy assembly is a way for a publisher to make a statement about the compatibility of different versions of an assembly. If a new version of an assembly isn't intended to be compatible with an earlier version, the publisher shouldn't create a publisher policy assembly. In general, use a publisher policy assembly when you build a new version of your assembly that fixes a bug. You should test the new version of the assembly for backward compatibility. On the other hand, if you’re adding new features to your assembly, you should consider the assembly to have no relationship to a previous version, and you shouldn't ship a publisher policy assembly. In addition, there’s no need to do any backward compatibility testing with such an assembly.

.NET Culture

Like version numbers, assemblies also have a culture as part of their identity. Cultures are identified via a string that contains a primary and a secondary tag. As the samples, German's

Primary Tag-de and CH as Secondary Tag; for British English itz en GB

In general, if you create an assembly that contains code, you don’t assign a culture to it. This is because code doesn’t usually have any culture-specific assumptions built into it. An assembly that isn’t assigned a culture is referred to as being culture neutral.

Now you can create one or more separate assemblies that contain only culture-specific resources—no code at all. Assemblies that are marked with a culture are called satellite assemblies. For these satellite assemblies, assign a culture that accurately reflects the culture of the resources placed in the assembly. You should create one satellite assembly for each culture you intend to support.

You’ll usually use the AL.exe tool to build a satellite assembly. You won’t use a compiler because the satellite assembly should have no code contained within it. When using AL.exe, you specify the desired culture by using the /c[ulture]:text switch, where text is a string such as “en-US,” representing U.S. English. When you deploy a satellite assembly, you should place it in a subdirectory whose name matches the culture text.

If you prefer, you can specify the culture by using the System.Reflection. AssemblyCultureAttribute custom attribute instead of using AL.exe’s /culture switch as

[assembly:AssemblyCulture("en-US")]

Salute to Master

CSIR (Council of Scientific and Industrial Research) honoured me by inviting to share the recent technology in IT industry. Itz 2 days South India conference. On Thursday (3rd Feb), I shared the latest technology in Microsoft platform.

Though I used to take sessions to college student community frequently, this is the first time in my life to run an official conference. To be frank, itz kind of bit nervous during the inaugural function. They had 2 industry speakers per day. During the inaugural process, I was one of the celebrity for the lighting (kuthu vilaku) event. After the official introduction, the huge conference stage was only to me. My agenda was to share overview at 11-12:30, 3-4 deep dive and 5-5:30 hands on demo. In between, the other speaker covered.

On attending some interactive, impressive, inspiring sessions in my career, I thought of following the same methodology. Took the packet collar mike, walked inside the crowd, asked few interactive questions, shared reward(jst choc) to them. Sessions reached quite well. My prof Ms TamilSelvi was part of the crowd and enjoyed the transition in her product on last 20 years.

Committee shared a wonderful momento with overwhelming positive feedback and standing applause from the audience. When they shared vote of thanks at EOD (End Of the Day), I requested few mins for me. Exact script was as below:

• Itz immense pleasure for me to get this opportunity. Thanx to everyone in this conf.
• Exactly 2 decades ago, same person don't know how to speak cont in English, how to draft the presentation, how to connect audience. Today's credit goes to all my mentors especially my first one Prof TamilSelvi
• Thanx everyone!

On seeing my prof in 3rd row, she is full of tears (with joy). Jst before leaving conf, I told her that we used to feel proud when our IT products are appreciated by end customers. And today itz your turn, Mam. One of the glourious moments in my life. Salute to true masters!

PS: On Feb 1991 (2nd year of UG), I was selected for my first tech presentation (RISC/CISC) in TCE, Madurai. Felt worried and reluctant. My prof coached/groomed for 2 weeks to host on the stage. Now, itz Feb 2011.

Runtime resolves Type References

public static void Main() {

System.Console.WriteLine("Hi");

}

The above code is compiled and built into an assembly, say Program.exe. When you run this application, the CLR loads and initializes. Then CLR reads the assembly’s CLR header, looking for the MethodDefToken that identifies the application’s entry point method (Main). From the MethodDef metadata table, the offset within the file for the method’s IL code is located and JIT-compiled into native code, which includes having the code verified for type safety. The native code then starts executing. ILDasm.exe contains the attached left side images.

When JIT-compiling this code, the CLR detects all references to types and members and loads their defining assemblies (if not already loaded). As you can see, the IL code above has a reference to System.Console.WriteLine. Specifically, the IL call instruction references metadata token 0A000003. This token identifies entry 3 in the MemberRef metadata table (table 0A). The CLR looks up this MemberRef entry and sees that one of its fields refers to an entry in a TypeRef table (the System.Console type). From the TypeRef entry, the CLR is directed to an AssemblyRef entry: “mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089”. At this point, the CLR knows which assembly it needs.

Now the CLR must locate the assembly in order to load it. When resolving a referenced type, the CLR can find the type in one of three places:

1. Same file: Access to a type that is in the same file is determined at compile time (sometimes referred to as early bound). The type is loaded out of the file directly, and execution continues.
2. Different file same assembly: The runtime ensures that the file being referenced is in the assembly’s FileRef table of the current assembly’s manifest. The runtime then looks in the directory where the assembly’s manifest file was loaded. The file is loaded, its hash value is checked to ensure the file’s integrity, the type’s member is found, and execution continues.
3. Different file, different assembly: When a referenced type is in a different assembly’s file, the runtime loads the file that contains the referenced assembly’s manifest. If this file doesn’t contain the type, the appropriate file is loaded. The type’s member is found, and execution continues.

GacUtil

If an assembly is to be accessed by multiple applications, the assembly must be placed into a well-known directory, and the CLR must know to look in this directory automatically when a reference to the assembly is detected. This well-known location is called the global assembly cache (GAC), which can usually be found in c:\windows\assembly directory

The GAC directory is structured: It contains many subdirectories, and an algorithm is used to generate the names of these subdirectories. You should never manually copy assembly files into the GAC; instead, you should use tools to accomplish this task. These tools know the GAC’s internal structure and how to generate the proper subdirectory names. While developing and testing, the most common tool for installing a strongly named assembly into the GAC is GACUtil.exe.

you can invoke GACUtil.exe, specifying the /i switch to install an assembly into the GAC, and you can use GACUtil.exe’s /u switch to uninstall an assembly from the GAC. Note that you can’t ever place a weakly named assembly into the GAC. If you pass the file name of a weakly named assembly to GACUtil.exe, it displays the following error message: “Failure adding assembly to the cache: Attempt to install an assembly without a strong name.”

Deployment Modes

There are two kinds of deployment in .NET framework.

They are (1) private deployment, in which assemblies are placed in the application’s base directory (or a subdirectory thereof) for the application’s sole use. Deploying assemblies privately gives a company a large degree of control over the naming, versioning, and behavior of the assembly.

(2) global deployment, in which assemblies can be accessed by multiple applications. The assemblies that ship with the Microsoft .NET Framework are an excellent example of globally deployed assemblies, because all managed applications use types defined by Microsoft in the .NET Framework Class Library (FCL).

Key differences are listed as: A private deployment is available to a particular applications where they are kept. And cannot be references outside the scope of the folder where they are kept. In contrast, global deployment are accessible globally/shared across the machine to all the applications. For using those assemblies you need to register the assembly with a strong name in the global assembly cache(GAC) using gacutil.exe. GAC can be found on all the computers with .Net framework installed. Therez an alternative without GAC and the solution is published at http://devcity.net/Articles/254/1/article.aspx. Based on the business need, you can choose the deployment mode.

Assembly Linker

Assembly Linker is useful if you want to create an assembly consisting of modules built from different compilers (if your compiler doesn’t support the equivalent of C#’s /addmodule switch) or perhaps if you just don’t know your assembly packaging requirements at build time. You can also use AL.exe to build resource-only assemblies, called satellite assemblies, which are typically used for localization purposes. This utility can produce an EXE or a DLL PE file that contains only a manifest describing the types in other modules. Letz see an illustration.

al /out:FullName.dll /t:library FirstName.netmodule LastName.netmodule

In this example, two separate modules, FirstName.netmodule and LastName.netmodule, are created. Neither module is an assembly because they don’t contain manifest metadata tables. Then a third file is produced: FullName.dll, which is a small DLL PE file (because of the /t[arget]:library switch) that contains no IL code but has manifest metadata tables indicating that FirstName.netmodule and LastName.netmodule are part of the assembly. The resulting assembly consists of three files: FullName.dll, FirstName.netmodule and LastName.netmodule.

Happy New Year 2011 with happy learning.