The .NET Framework allows sharing of assemblies through the GAC. The GAC is a %systemroot%\assembly directory on a computer on which .NET Framework is installed. GAC can be managed through %systemroot% \Microsoft.NET\Framework\ version GACUTIL.exe or the Assembly Cache Viewer extension of Windows Explorer; see Figure 23.4. Additional details of using this tool can be found at: http://msdn2.microsoft.com/library/34149zk3.aspx. Figure 23.4. Assembly Cache Viewer.Assemblies must have a strong name to be stored in GAC, so the .NET runtime can uniquely identify each assembly, even assemblies with the same name. A strong name is the combination of the assembly's name , the four-part version number, the culture (if provided), a public key, and a digital signature stored in the assembly's manifest. Visual Studio 2005 made it very simple to sign an assembly through the Signing tab of the Project Designer. To access the Signing tab, select a project node in Solution Explorer, and then on the Project menu, click Properties. When the Project Designer appears, click the Signing tab. By default, Reporting Services does not allow calls to strong-named custom assemblies directly from reports . This is probably a good thing because enabling SSRS to call strong -named assembly poses security risks. To enable calls to strong-named custom assembly in Reporting Services, you can use one of the methods described in Table 23.1. Both methods described in Table 23.1 have security risks associated with them. Table 23.1. Methods of Enabling a Strong-Named Assembly
Security risks are especially relevant to the strong-named custom assemblies that require more than Execute permissions (discussed in the later section, "Assemblies That Require Other Than Execute Permissions"). |