It's possible to add additional references as part of your project. Similar to the default code files that are created with a new project, each project template has a default set of referenced libraries. Actually, it has a set of imported namespaces and a subset of the imported namespaces also referenced across the project. This means that while you can easily reference the classes in the referenced namespaces, you still need to fully qualify a reference to something less common. For example, to use a StringBuilder you'll need to specify the fully qualified name of System.Text.StringBuilder. Even though the System.Text namespace is referenced it hasn't been imported by default. For Windows Forms applications targeting .NET 4, the list of default referenced namespaces is fairly short, as shown in Table 1-4.
TABLE 1-4: Default References In a New Project reference description
Often referred to as the root namespace . All the base data types (String, Object, and so on) are contained within the System namespace . This namespace also acts as the root for all other System classes.
This dll contains a collection of namespaces, some of which are required to support LINQ to in-memory objects, as well as support for several OS-level interfaces .
Classes associated with ADO.NET and database access . This namespace is the root for SQL Server, Oracle, and other data access classes .
Defines a collection of extension methods used by the core DataSet class . These are used when working with LINQ to DataSets .
Classes used for ClickOnce Deployment . This namespace is covered in more detail in Chapter 34.
Provides access to the GDI+ graphics functionality
Classes used to create traditional Windows-based applications . This namespace is covered in more detail in Chapters 14 and 15 .
Root namespace for all of the XML classes
Root namespace to support the Language Integrated Query (LINQ) native language queries for XML data sources .
The preceding list of referenced libraries is for .NET 4, so if you instead create a project that targets .NET 2.0, this list will be shorter. Keep in mind that changing your target framework does not update any existing references. If you are going to attempt to target the .NET 2.0 Framework, then you'll want to remove references that have a version higher than 18.104.22.168. References such as System.Core enable new features in the System namespace that are associated with .NET 3.5.
To review details about the imported and referenced namespaces, select the References tab in your project properties display, as shown in Figure 1-10. This tab enables you to check for unused references and even define reference paths. More important, it is from this tab that you select other .NET Class Libraries and applications, as well as COM components. Selecting the Add drop-down button gives you the option to add a reference to a local DLL or a Web service.
When referencing DLLs you have three options: Reference an assembly from the GAC, reference an assembly based on a file path, or reference another assembly from within your current solution. Each of these options has advantages and disadvantages. The only challenge for assemblies that are in the GAC is that your application is dependent on what is potentially a shared resource. In general, however, for assemblies that are already in the GAC, referencing them is a straightforward, easily maintainable process.
In addition to referencing libraries, you can reference other assemblies that are part of your solution. If your solution consists of more than a single project, then it is straightforward and highly recommended to use project references in order to enable those projects to reference each other. While you should avoid circular references — Project A references Project B which references Project A — using project references is preferred over file references. With project references, Visual Studio can map updates to these assemblies as they occur during a build of the solution. It's possible for Visual Studio to automatically update the referenced assemblies in your executable project to be the latest build of the referenced DLLs that are part of the same solution. Note that the target needs to be an executable. Visual Studio will automatically update references between DLL projects in a common solution.
This is different from adding a reference to a DLL that is located within a specified directory. When you create a reference via a path specification, Visual Studio can check that path for an updated copy of the reference, but your code is no longer as portable as it would be with a project reference. More important, unless there is a major revision, Visual Studio usually fails to detect the types of changes you are likely to make to that file during the development process. As a result, you'll need to manually update the referenced file in the local directory of the assembly that's referencing it. For your own code often it's best to leverage project references, rather than path-based references. However, for third party controls where you'll often only have an installed location, one which isn't likely to change as you move between machines, a path based reference can work.
On the other hand an alternative solution which is commonly used, is to ensure that instead of referencing third party controls based on their location, that instead 'copy local' references are used so that the version specific copy of the control deploys with the code that depends on it. This means that different versions of the controls can exist on the same server in different applications. Additionally because a local copy of the control is with the application, the application can be XCopy deployed without needing to register the controls.
Was this article helpful?
What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.