Prizes & Awards
My Profile
Active Members
TodayLast 7 Days
more...
|
 New Feature: Community Sites:
Create your own .NET community website and start earning from Google AdSense !
It's Free !
|
Still Going Strong
Posted Date: 30 Jul 2005 Resource Type: Articles Category: .NET Framework
|
Posted By: Balamurali Balaji Member Level: Diamond
Rating:  Points: 10
|
Introduction
You may wish to share your assemblies with other applications. Most of the times, you build your class library into a dll and copy the assembly locally into the applicationi\bin folder of other applications. The best way, as suggested by MSDN, is to put it in to GAC.
GAC stores all shared assemblies, signed with a public key pair along with the version. Many developers feel difficult in calling the strong-named assemblies from their client applications.
You have a private assembly in the local class-library application\bin folder and also a shared assembly in the \\winnt\assembly folder. Your client application, that references to the private assembly compiles successfully. The dilemma here is, whether it uses the private or the shared one in the windows folder.
Catch in the configuration!
The main benefit of placing your assembly is that the client application that references them can still run smoothly, even if the private assembly is deleted or moved to another folder. But, it doesn’t happen just like that. You need to include an app.config.file that configures your client during runtime to scan through the specified folders from where the assembly is referenced.
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing publicPath="c:\winnt\assembly"/>
<dependentAssembly>
<assemblyIdentity name="baladll" publicKeyToken="df01a06f36c34e95" culture="neutral" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
In the above sample, I request the client to search for the referenced assembly in the \\winnt\assembly folder, if not exist in the client bin folder, or the referenced private assembly (original) is deleted or moved. You must also include the <assemblyidentity> element that specifies the name of the assembly, publickkeytoken, version and culture. PublicKeyToken may be easily obtained by copying from the output of gacutil /l.
My sample class library looks like below:
using System;
namespace baladll
{
public class Arithmetic
{
public int add(int x, int y)
{
return x+y;
}
}
}
After compiling this to a target type of class library, I generated a keyfile using sn.exe. Then again signed this assembly with this keyfile included in the AssemblyInfo, I re-compiled the assembly, thus making it a strong-name assembly. I placed it in the GAC.
Now, the calling client application (in this case, I use C# windows application), adds a reference to the private assembly baladll. On a click of a button, calls the method and places the return value in a textbox.
using System;
using baladll;
namespace balaClientl
{
…………….
…………….
private void button1_Click(object sender, System.EventArgs e)
{
Arithmetic a = new Arithmetic();
textBox1.Text = a.add(10,20).ToString();
}
You may remove the private assembly “baladll” now, and it is ok for the calling client application to run as it found it in the GAC. This will not be working if you try to compile the (client) calling application as you still need a reference to the original private assembly only.
Summary
Strong-named assemblies are only useful when the referenced private assemblies are moved very often within your system. It is a useful mechanism for multiple applications to reference the assembly in the GAC.
|
Responses
|
| Author: Ami Desai 16 Jan 2006 | Member Level: Silver Points : 0 | Please help me while adding shared assembly in window application
|
|