Visual Studio Wears Sabots

This post addresses the problem of compiler errors reporting missing namespaces for solutions composed of multiple projects.

15th century Netherlands textile laborers were believed to throw their wooden shoes, called sabots (sah-BOW), into the cogs of mechanized looms, to prevent their occupation from being rendered obsolete by automated processes; hence, the supposed root and historical context of the word, sabotage.

One would expect Visual Studio to be an industrious little worker, and that it is.  In fact, it works so hard to make our development experience easier, it often runs right out of its clogs, which then fall deep into the whirling cogs of the .NET Framework.  In some cases, Visual Studio sabotages a project, resulting in the following symptoms:


Symptoms

• You are working with a Command Prompt, ASP.NET Web Forms, or other deployable project
   
• You have added one or more references to the project, in addition to the default references
   
• Visual Studio reports namespaces of referenced assemblies are not found, producing the following compiler error:
  
  

  The type or namespace name '(NAMESPACE)' could not be found (are you missing a using directive or an assembly reference?)

  
  
• When adding the solution to Team Foundation Server, you receive the following error:
  
  

  The project that you are attempting to add to source control may cause other source control users to have difficulty opening this solution or getting newer versions of it. To avoid this problem, add the project from a location below the binding root of the other source controlled projects in the solution.

• Namespaces of referenced assemblies do not appear in Intellisense, also resulting in the same compiler error:
  
  

  The type or namespace name '(NAMESPACE)' could not be found (are you missing a using directive or an assembly reference?)

• The compiler reports the following error, in the output window:
  
  

  The referenced assembly "(ASSEMBLY NAME), Version=4.2.36.0, Culture=neutral, PublicKeyToken=xxx, processorArchitecture=MSIL" could not be resolved because it has a dependency on "(REFERENCED NAMESPACE), Version=4.0.0.0, Culture=neutral, PublicKeyToken=xxx" which is not in the currently targeted framework ".NETFramework,Version=v(.NET FRAMEWORK VERSION),Profile=Client". Please remove references to assemblies not in the targeted framework or consider retargeting your project.

Versions of .NET Framework that are able to generate this error include (as of publication of this post) 3.5 and 4.0.  Versions 1.0-3.0 are not subject to this problem.

Cause of Problem

The problem is that Visual Studio defaults project settings of deployable project types to .NET Framework (VERSION NUMBER) Client profile.  Visual Studio assumes you will be deploying the project to other computers, which may not (and usually don't) have the full .NET Framework installed.

What we basically have here is a need for more framework.  The Client version simply doesn't have enough resources to support the project.

The Client version of .NET Framework is a stripped-down, deployable version, which is much more portable.  The client becomes portable by shedding all assemblies generally attributed to large, robust applications.  For example, the System.Web assembly is often included by common libraries, used by several internal applications of a company, or a product suite.  However, System.Web is deemed to be "robust", and is therefore excluded from the Client profile.  (Why an ASP.NET Web Forms project defaults to Client profile is beyond me.)

Solution

Simply view the project's Application properties (menus Project > (PROJECT NAME) Properties...), and then set the Target framework to the full framework version, instead of its Client version.  The issue should be immediately resolved, and all referenced namespaces and assemblies will be accessible to the project.