Code libraries are convenient ways to package and reuse components. They provide a portable way to encapsulate code in a single file, allow for inheritance and modification of these files, and permit distribution of discrete units of functionality. You can combine components from many different projects into a single code library. For example, you might choose a custom control from one project, a component from another project, and a form from yet another project, and put them all into your code library. You can also customize the library for special purposes. The only limitation is that all files in a single code library must be written in the same language.
A code library is basically an assembly that compiles to a DLL. For more information, see Components and Assemblies.
One of the features of the .NET Framework is the common language specification (CLS). The common language runtime compiles all code written in a CLS-compliant language to the same kind of intermediate code — MSIL. This means that code libraries written in any CLS-compliant language will be accessible from all other languages that support the common language specification. Therefore, a code library written in Visual Basic, for instance, can be used in an application written in C#, C++, or any other CLS-compliant language.
When designing your components and code libraries, it is important to keep in mind that some languages do not support optional parameters. If you think a language that does not support optional parameters may use your code library, then you should take into account that all parameters will have to be supplied for any methods that are called. One way to ensure that a method can be called with any number of optional parameters is to provide multiple overloads of that method. For more information, see Method Implementation in Components.
The access level of the component in your code library will directly determine how these components can be used by the client application. Client components can only access public components. Components marked Friend (internal in C#) are accessible only to other members of the code library. Private and protected components cannot be accessed from outside the class, (although Protected classes can be accessed by derived classes; for more information, see Access Modifiers).
Visual Basic allows for the implementation of modules. If you are implementing modules for distribution in a code library, it is important to realize that other programming languages that don't support modules will see modules as classes containing only shared members. Therefore, other languages will need to use the name of the module as a qualifier to access the members of the module. Accurate documentation of your code library will help prevent problems.
If you plan to make your code library available to more than one application at a time, you might want to install the assembly into the global assembly cache. For a discussion of issues involved in this, see Working with Assemblies and the Global Assembly Cache.
If you plan to make your code library available to COM clients, there are additional considerations to take into account. For more information, see Exposing .NET Framework Components to COM.