Kapil Sachdeva's Blog - SmartCard Serenity

http://www.techworld.com/opsys/news/index.cfm?NewsID=2627

"The move towards smart cards is the way forward," said Gates in his keynote at IT Forum, in Copenhagen this morning. "The idea is to have a smart card that connects up in the best way - a .Net based smart card."

Microsoft partner Axalto "has done a super job on this", said Gates. "We will be using their smartcards internally - each employee will use those to get in and out of the buildings as we used to connect to our machines. We're requring them. We will completely replace passwords."

By having .Net capability, said Gates, "we think this brings different logic down to the card itself, giving a richness and continuity to the platform that only exists in that .Net environment." Axalto said this was the first commercial deployment of Axalto’s .Net-based smart cards.

For the press release goto: http://www.axalto.com/Company/press/news.asp?id=220

Finally its out of the lab as the product which is not only going to make systems secure but revolutionize the Smartcard technology with the help of excellent on-card & off-card application developement framework i.e .NET.

Side-by-Side execution is a great facility but if shared assembly (assembly in GAC) developers maintain backward compatability configuring the publisher's policy for shared assemblies make .NET Rock.

There are basically 2 ways to configure your shared assembly -

• Use the SnapIn [AdministrativeTools\Microsoft .NET Framework 1.1 Configuration]
• Use the policy assembly.

The SnapIn is really fast, neat and less-error prone way to do but in most practical situations not usable.

To configure via SnapIn, right click on Configured assemblies node in the left pane, select 'Add' menu option. After this configuration is intuitive.

Using policy assembly is the way mostly every shared assembly developer will use as it is just to be installed in GAC and then its upto the CLR to do the magic of assembly binding.

Steps for creation of the assembly are :

• Create a policy file
• Put the above created policy file in assembly using al
• Install the above created assembly in GAC.

Here is the snippet for sample policy file which says that CLR should bind the host application reference to version 1.1.0.0 instead of 1.0.0.0

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<runtime>
     <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <dependentAssembly>
            <assemblyIdentity name="LibInGac" publicKeyToken="5bb6adc75ec4790c" culture="neutral" />
        <bindingRedirect oldVersion="1.0.0.0" newVersion="1.1.0.0"/>
         </dependentAssembly>
    </assemblyBinding>
</runtime>
</configuration>

Now run the al with the following command line :

al /link:LibInGac.dll.config /out:policy.1.0.LibInGac.dll /keyfile:mysnk.snk /version:1.1.0.0

Important thing here is to get the above command line correct.

1. /link:name_of_file.config
2. /out:policy.MajorVersionOfOldAssembly.MinorVersionOfOldAssembly.OriginalAssemblyName.dll
3. /keyfile:key_pair_file
4. /version:Version_for_policy_file

/version is an important option as you may want to override your previous policy assembly. CLR will look into the policy assembly with greater version number.

/Key_pair_file should be the same key-pair with which assembly being accessed (here LibInGac) was signed.

/out:policy.MajorVersion.MinorVersion.AssemblyName.dll

I was looking at GDN quick start sample and found out after hit-n-trial that options provided to 'al' are wrong. Also MSDN does not specify major version and minor version are that of original assembly or new assembly.