Public Key Specification When Referencing A Strong Named DLL

**Tom** · Aug 1 '08, 01:05 AM

Re: Public Key Specification When Referencing A Strong Named DLL

Hey folks --

I am now past baby step #1 in using the GAC and am hoping this follow
up posting might be of benefit to some that are new to using the GAC
for the first time.

Some of the instructional references I found suggested dragging the
DLL file into the proper GAC folder. Other references said to use the
Configuration tool. I tried each of these and they both failed. The
problem is you need to do *both* !! And why this is not emphasized
somewhere in the instructional documentation is beyond me. Perhaps
because it is so elementary? I don't know. From the perspective of a
first time GAC user, it seems to me that explanations should not
require this ever so tiny leap in understanding.

I now think of the configuration tool as the means of storing or
registering the public key, DLL name, hash, and version number (plus
additional information) into a database repository on the computer.

The placement of the DLL file itself is an obvious requirement too. It
needs to (or most safely "should") reside in a common directory ...
but certainly this is NOT the only step in the process.

Some texts talk of the need for policy files too. The default behavior
for a newly installed DLL is satisfactory. Policy files are for
maintenance and updating DLL components on older and established
applications. Don't let the policy file implications confuse the issue
when using the GAC for the first time ... just ignore them.

Additionally, there is the need for the calling application to
reference the public key created using the sn.exe utility. How this is
done appears to be different among the various .Net languages?
Fortunately, one C# text I have states that >"If you're using the
Visual Studio .NET IDE, public keys for strong-named assemblies are
automatically retrieved when you compile an application." I found this
to be true for VS2005. So ... don't let some of the Basic.Net
information found via a C# Google search confuse the issue.

Some texts also discuss "signing" and usage of Authenticode practices
in the same section as strong naming. This caused me to think during
the midst of several failed attempts that signing might also be
needed? Not true. Ignore signing when using the GAC for the first
time.

-------------------
So here is a step-by-step guideline for strong naming C# DLL
assemblies using VS2005 and placing them into the GAC:

1) Create you DLL project.

2) Debug it without signing by referencing it within a testing program
with a property setting of: Copy Local = true.

3) Right click on the project folder within the Solution Explorer and
select "Properties ". Then select the "Signing" grouping and check the
"Sign the assembly" check box. Use the drop down menu to choose
"<New...>" and fill in the Key file name and optional password
protection fields. Note: There is no longer any need to use the
command line and the direct usage of the sn.exe utility.

4) Build a release version of your solution/project.

5) For prevention of accidental deletion ... use file explorer and
Ctrl-drag the .dll file found in the bin/release folder into a secured
folder. One such folder is the one containing the .Net classes. To
locate this folder ... examine the properties of an included .Net
reference class of your project. (For example: System.Data,
System.Windows. Forms, System.Drawing, etc.) Usage of two File Explorer
instances simplifies this task.

6) Open the registration tool using the following command:

Start Programs Administrative Tools Microsoft .NET Framework
2.0 Configuration

----------------------------------------
Note: In the above path, if the "Administra tive Tools" selection is
not visible ... use the following path to check the appropriate check
box:

Start Settings Taskbar & Start Menu... Advanced (tab)
----------------------------------------

Expand the "My Computer" node and select the "Assembly Cash" node.
Right click "Assembly Cash" and choose "Add...". Then browse to the
..dll location to make the appropriate entry of the signed .dll file.

7) Return to the testing program and delete the old reference to your
unsigned dll and delete the files within the solution's bin directory.
You don't want a residual copy of the unsigned dll lingering around
and causing confusion. Add a new reference to your now signed dll.
Within the reference properties for the dll ... set >Copy Local =
false. Rebuild the test program. Note: Within C# there is no need to
reference the public key of the private/public key pair created and
stored in the .snk file. The .snk file should be visible within the
project folder of the signed assembly. Full functionality of the
testing program should be observed.

You can also reuse a previously created .snk file by browsing to it in
the above step #2 ... rather than using "<New...>". The .snk file is
just a simple file and can be stored in a convenient location. Perhaps
the safest location is in the GAC? -- however; I have not yet tested
storing the .snk within the GAC. You decide. Only when created locally
using "<New...>" will it be automatically placed in the project
folder.

=============== =============== =============== =============

Hopefully the above step-by-step guidelines makes the signing of
assemblies an easier to learn task.

There are many more related topics to explore to automate the
inclusion of dll or other assemblies into the GAC. One area is that of
'Fusion' ... but I am not yet there. I am still building and running
my own dll's on my own computer. Commercial implementations require
some additional work.

I encourage 1'st time GAC users to clarify and improve upon the above
guideline. I hope the steps needed are more clearly expressed above
than the texts and online sources I found ... but having completed the
task with many failed attemps along the way ... I might have easily
missed an important step or two.

-- Tom

On Wed, 30 Jul 2008 13:58:36 -0500, Tom <Thomas-911@earthlink.n et>
wrote:

>My unsigned DLL works in my project that references it as long as I
>set Copy Local = true.
>
>Now I have signed the DLL with the sn.exe generated keys but have not
>yet moved the DLL into the GAC.
>
>Can I use a strong named DLL outside the GAC with Copy Local = false
>by providing a reference to the public key?
>
>If yes to above, please tell me how to reference the public key within
>the IDE of the project that calls upon a signed DLL.
>
>I am hopeful that there is a way to simply browse to the .snk file
>within the IDE and auto generate the appropriate attribute within the
>AssemblyInfo.c s file.
>
>Thank you for any assistance.
>
>-- Tom

Public Key Specification When Referencing A Strong Named DLL

Public Key Specification When Referencing A Strong Named DLL

Comment