GACView is a software for Windows-based operating system that act as an alternative to the standard .NET assembly viewer on Window Explorer. This application displays additional information for each assembly such as modified date, file size, full path of the assembly file and file version. In addition, it can also delete an assembly that cannot be uninstalled in a simple regular way.

GACView doesn’t require any installation process or additional DLLs. In order to start using it, just copy the executable file (gacview.exe) to any folder you like, and run it. The main window of GACView displays the list of all assemblies installed in the GAC. You can select one or more assemblies, and then uninstall them, delete them (If regular uninstall fails), or save the assemblies information to file. You can also install new assemblies by using “Install Assembly” option under the File menu, or by simply dragging the assembly that you want to install into the main window of GACView.

Using GACView 

GACView doesn’t require any installation process or additional DLLs. In order to start using it, just copy the executable file (gacview.exe) to any folder you like, and run it. The main window of GACView displays the list of all assemblies installed in the GAC. You can select one or more assemblies, and then uninstall them, delete them (If regular uninstall fails), or save the assemblies information to file. You can also install new assemblies by using “Install Assembly” option under the File menu, or by simply dragging the assembly that you want to install into the main window of GACView. 

Notice About GAC Install Options 

The 2 GAC install options (under Options menu) were added according to the assembly GAC API documentation, but it seems that these options don’t really affect the way that an assembly is installed in the GAC. When a new version of assembly is installed, the new version is added to the GAC without overwriting the previous versions, even if you select one of these install options. (Bug in GAC APIs ??) 

System Requirements 

Although this utility is designed to work with .NET environment, the utility by itself wasn’t written in .NET, which means that it can work in all versions of Windows, even if .NET Framework is not installed. 

Versions History 

• Version 1.11 

• The configuration is now saved to a file, instead of the Registry. 

• Version 1.10 

• Added support for .NET 2.x 

• New column: Processor Architecture. (for .NET 2.x) 

• Version 1.01 – Added support for Windows XP visual styles. 
• Version 1.00 – First release. 

Command-Line Options 

License 

This utility is released as freeware. You are allowed to freely distribute this utility via floppy disk, CD-ROM, Internet, or in any other way, as long as you don’t charge anything for this. If you distribute this utility, you must include all files in the distribution package, without any modification. 

The Global Assembly Cache (GAC) is a folder in Windows directory to store the .NET assemblies that are specifically designated to be shared by all applications executed on a system. 

The concept of GAC is the result of the .NET architecture whose design addresses the issue of “DLL hell” that existed in COM (Component Object Model). Unlike in COM, there is no need for the assembly in GAC to be registered before its use. Each assembly is accessed globally without any conflict by identifying its name, version, architecture, culture and public key. 

The GAC is a machine-wide code cache used for side-by-side execution of assemblies. The GAC implements the feature of shared library where different applications reuse the code placed in the files located in a common folder. In .NET 4.0, its default location is: %windir%\Microsoft.NET\assembly

The GAC is also the first in the search path while loading a .NET assembly. The only requirement for an assembly to be deployed in GAC is that it should have strong name. The CLR (Common Language Runtime) refers an assembly based on specific version mentioned by the calling application. The virtual file system of GAC helps to fetch the version-specific assembly. 

The two tools related to GAC are GAC Tool (gacutil.exe) and Assembly Cache Viewer (shfusion.dll). GAC Tool is used to check for assembly existence, register a shared assembly, view and manipulate contents of GAC, etc. Being a system folder, it requires administrator privileges to be used. Assembly Cache Viewer is used to display the details (version, culture, etc.) associated with the assemblies contained in the cache.

GAC provides the benefits of code reuse, file security (due to its installation in ‘systemroot’ directory and hence deletion is only by users with Administrator privileges), side-by-side execution (allowing multiple versions of an assembly maintained in the same folder), etc.

One of the drawbacks in using GAC are that the version of .NET Framework installed in the system where GAC is used and the one used for compiling the application need to be same. Also, strong names cannot be applied to assemblies (like third party code) on which the assemblies residing in the GAC folder depend upon. 

Usage 

There are two ways to interact with the GAC: the Global Assembly Cache Tool (gacutil.exe) and the Assembly Cache Viewer (shfusion.dll). 

Global Assembly Cache Tool 

gacutil.exe is an older command-line utility that shipped with .NET 1.1 and is still available with the .NET SDK.  

One can check the availability of a shared assembly in GAC by using the command: 

gacutil.exe /l <assemblyName>

One can register a shared assembly in the GAC by using the command: 

gacutil.exe /i <assemblyName>

Or by copying an assembly file into the following location: 

%windir%\assembly\

Note that for .NET 4.0 the GAC location is now: 

%windir%\Microsoft.NET\assembly\

Other options for this utility will be briefly described if you use the /? flag, i.e.: 

gacutil.exe /?

 Assembly Cache Viewer 

The newer interface, the Assembly Cache Viewer, is integrated into Windows Explorer. Browsing %windir%\assembly\ (for example, C:\WINDOWS\assembly) or %WINDIR%\Microsoft.NET\assembly, displays the assemblies contained in the cache along with their versions, culture, public key token, and processor architecture. Assemblies are installed by dragging and dropping and uninstalled by selecting and pressing the delete key or using the context menu. 

With the launch of the .NET Framework 4, the Assembly Cache Viewer shell extension is obsolete.[3] 

Example of use 

A computer has two CLI assemblies both named AssemblyA, but one is version 1.0 and the other is version 2.0. Since it is required that both be compiled to a file named AssemblyA, they cannot exist in the same directory within the FAT32 file system. Instead, the virtual file system of the GAC can be used by programs that need to use each version of the assembly specifically. 

Implementation :

The GAC as a construct does not actually exist within the Windows OS. It is implemented and managed by the CLI. The folders within %systemroot% named assembly and Microsoft.NET\assembly (for .NET 4.0) contain all globally available assemblies with managed filenames so that the version and public key tokens can be included. Each version can therefore exist within the same location and be called without requiring subsequent versions to preserve code entry point locations as usual. Windows Explorer allows the drag-and-drop installation of assemblies into this folder only if they would otherwise be permitted to be installed from the command line. 

A calling application may specify a version of an assembly when referencing it, so the run-time can simply refer to the filename to use the correct one. 

Pitfalls :

The Global Assembly Cache mechanism helps to avoid older DLL hell, but it still has some drawbacks, such as:  

• By default, applications will only run with the version of the .NET Framework used to compile it, which can cause the application to fail on machines with newer versions of the .NET Framework installed — even when the application would normally run properly with the newer version. 

• It is sometimes necessary to use conditional compilation if some of the core .NET calls (used in the application) are only supported for some versions of the framework. 
• .NET applications that rely on native code risk incompatibilities, even with the GAC mechanism. 
• Every assembly that is added to the GAC must be strongly named. The process of making an assembly “strongly named” can be quite painful in some situations. For example, if an assembly depends on another assembly that is not strongly named, it cannot be registered in the GAC. In cases where the code of the third-party assembly is not in the programmer’s possession, transforming the assembly to be strongly named can in fact be impossible. 
• Browsing for files using standard Windows APIs doesn’t allow selection of DLLs located under the “assembly” folder when Explorer is showing the user-friendly view of the GAC. 

GACView doesn’t require any installation process or additional DLLs. In order to start using it, just copy the executable file (gacview.exe) to any folder you like, and run it. The main window of GACView displays the list of all assemblies installed in the GAC. 

How to view assemblies in GAC as like Explorer files and folders :

If you navigate to Assembly folder say C:\Windows\assembly in Explorer, you could see the assemblies without folder structure where as you will see a structured directories like GAC_32, GAC_MSIL, Nativeimages, tmp folders in Command prompt. If you want to browse the GAC like any other folder structure. you can try this simple regedit entry-
Create a DWORD value named “DisableCacheViewer” and set it to value 1 under reghives -HKLM\Software\Microsoft\Fusion
Now explore to c:\windows\assembly, you will see something like this. 

 Advantages: 

• Loading assemblies from GAC mean less overhead and security that your application will always load correct version of .NET library 
• You shouldn’t ngen assemblies that are outside of GAC, because there will be almost no performance gain, in many cases even loss in performance. 
• You’re already using GAC, because all standard .NET assemblies are actually in GAC and ngened (during installation). 
• Using GAC for your own libraries adds complexity into deployment, I would try to avoid it at all costs. 

• Your users need to be logged as administrators during installation if you want to put something into GAC, quite a problem for many types of applications.
• So to sum it all, start simple and if you later see major performance gains if you put your assemblies into GAC and NGEN them, go for it, otherwise don’t bother. GAC is more suitable for frameworks where there is expectation for library to be shared among more applications, in 99% of cases, you don’t need it. 

Assemblies are designed to simplify application deployment and to solve versioning problems that can occur with component-based applications.

The word Assembly means it is A group of some parts that fit together to form a self-contained unit.

* So in asp.net, An assembly is a collection of single or multiple files.
* Assembly physically exist as DLLs or EXEs
* The constituent files can be any file types like image files, text files etc. along with DLLs or EXEs
* The assembly also contains metadata that is known as assembly manifest.
* The assembly manifest contains data about the versioning requirements of the assembly, like author name of the assembly, the security requirements to run and the various files that form part of the assembly.
* When you compile your source code by default the exe/dll generated is actually an assembly.
* More accurately, an assembly is the primary unit of deployment, security, and version control in the .NET Framework.

Advantages of Assemblies:

1. ASP.Net assemblies has a lot of good advantages when compare to conventional DLLs that the developers use to develop earlier. In the case of DLLs if a DLL has to be shared with some other application, it has to be registered in that particular machine. But, In the case of Asp.net assemblies there is no such type of registration required. Here we just need to do is to copy the assembly and put in the bin directory of the application that is going to use it.

2. If we need to share a particular assembly with any other applications., we can do so by placing the assembly in the Global Assembly Cache (GAC). But before we going to do it we need to give a strong name to that assembly. Strong name is similar to GUID(It is supposed to be unique in space and time) in COM, components. Strong Name is only needed when we need to deploy assembly in Global Assembly Cache (GAC).Strong Names helps GAC to differentiate between two versions. Strong names use public key cryptography (PKC) to ensure that no one can spoof it. PKC use public key and private key concept.

3. Another advantage of using ASP.Net assemblies is the ability to read the contents of an assembly. Each assembly has a manifest that has details about the assembly itself.

4. The System.Reflection namespace has classes like Assembly which can be used to get the details of the assembly and with that it is also possible to load an assembly dynamically at runtime.

Major Features of  GACView

• Programming tool for .NET developers who wish to use something other than the .NET assembly viewer inside Windows Explorer
• View the assembly name, version, culture, public key, token, signature, modified date, file size, full path of the assembly file, file version, and much more
• Perform a search within the .NET assembly information
• Export information to an external file

What is GAC