| In This Chapter -
Understanding the Role of Attributes -
Annotating Types and Members -
Viewing Attributes with the MSIL Disassembler -
Extracting Attributes Using Reflection -
Creating Custom Attributes -
Component Attributes -
COM Interop Attributes -
Summary Earlier in the book we mentioned that the sweeping changes in .NET required sweeping changes to the Visual Basic language. When you define, code, and compile a project in Visual Studio .NET, you are creating an assembly. Only part of that assembly is an executable. Another significant part of an assembly is the self-describing metadata. Metadata, or additional declarative information, was added to combat "DLL Hell." Until now, Windows applications were coded and compiled, and additional information was stored in the registry separately from those compiled applications. Applications such as regtool5.dll or GetSetting and SaveSetting in VB6 were used to read the extra data an application needed to function correctly. This extra data included the location and registration of dependent files, About information, and application settings. The problem was that the extra information an application needed did not travel with the application. Further, DLLs were registered based on filename. A newer file with the same name as a predecessor would overwrite registry settings, breaking existing applications. Metadata travels with an application in .NET, binding the application to its supporting data in an assembly. Additionally, application uniqueness is not based on just filename. Application uniqueness is based on the name, a strong name, version, and locale, allowing assemblies with the same name to coexist. The role attributes play is that of providing a means of specifying that metadata. Attributes allow you to provide simple application and About information as well as provide advanced control over code and request security permissions. Historically, Windows programming required that developers specify extra data in a variety of places like the registry, .INI files, and setup script files. The .NET Framework binds that metadata to the assembly, which also contains the executable. The combination of an assembly storing metadata and the executable eliminates "DLL Hell." This combination of metadata and executable supports xcopy deployment, too. Note The xcopy.exe command-line tool originally shipped with the MS-DOS operating system. (It was B.A.S.I.C. that made Microsoft a very profitable company, but it was MS-DOS that led to desktop domination and tremendous profitability.) The xcopy.exe program is a tool (still in Windows XP) that allows you to copy files and folders with a single command. By xcopy deployment, Microsoft means that you can deploy your applications by copying them. The term implies that you can deploy your .NET applications without complicated installation scripts or tools, and you won't need to register DLLs. This is not exactly true. Add-ins, wizards, and applications that use COM will still need to register GUIDs, and consequently have more complicated deployment models. This requirement will go away if COM goes away. You may still need to persist external application settings and the registry is still a convenient place to do this.
In this chapter you will learn how to define assembly and type and member attributes. You will learn how to subclass attributes in order to define custom attributes, and how to discover information about an assembly using the IL disassembler and reflection. | 
