Type safety basically means using strongly-typed data to protect against nasty bugs caused by type errors. A “strong type” is a programming construct that imposes certain rules or restrictions on specific data and how the data can be used. A “type error” is a bug that only appears at runtime (as opposed to compile time), and can have a considerably undesirable impact on data – often it only appears when you discover that something has gone terribly wrong. So, we should always strive to write type-safe code.

Here is an example. The following method call would not be considered type safe:

To compare: In non-web projects, Visual Studio project files manage the locations of referenced assemblies. When a non-web project is built, Visual Studio looks into the project file and looks through its list of referenced assemblies. For each one, it compares the version in the local obj directory with the one located at the hint path in the project file. If it’s different, then the project can copy down the new version before it continues to build. This is how the projects can manage when “project references” and other references change.