Types and namespaces can't be found

Types and namespaces can't be found

• Lilia Vratch

  Michael
  
  Thank you for your suggestion. Your description of how I reference the two namespaces in the two files is completely correct.
  
  I tried out moving the "using" clause into the namespace, and unfortunately it doesn't work. I can't imagine it's a circular reference issue to be honest, since I have successfully written applications in .NET in the past where a co-dependency such as this exists. If the compiler is anything like the C++ compiler, on the first pass it will collect the namespace and type names and use the generated stubs before, on the second, it tries to resolve them (something like that anyway: my understanding of compilers has degenerated).
  
  Even with this current project, I've been at such a stage without any problems whatsoever. This is a recent occurrence. I've even backed up all the source files, removed every trace of the application from my machine and reconstructed the solution, but the same thing occurs, it's very strange.
  
  I've exhausted all avenues I can think of: removing everything from namespaces altogether (when it then complains it can't find the type, rather than the namespace) and so on, but no joy. So any further suggestions would be appreciated.
  
  Thanks, Mark
  

• Tommy 06

  I believe it is a circular reference issue. Why it works in some cases I don't know but it quite likely is related to how you use it. I believe the problem is that you do something like this:
  
  using System;
  ...
  using Timesheet.Pages;
  
  namespace Timesheet.Controls
  {
  //MyControl
  }
  
  using System;
  ...
  using Timesheet.Controls;
  
  namespace Timesheet.Pages
  {
  //MyPage using MyControl
  }

  I believe the problem lies in the fact that before the compiler will compile (and therefore define) the namespace Timesheet.Controls it must "bring in" the namespaces defined with the using statements. However when it determines that Timesheet.Pages is defined in the project it is naturally going to try and compile it first. However it will hit a road block because it needs Timesheet.Controls first. A circular reference.

  The solution (at least for VS2005) is to postpone the inclusion of a namespace until you actually need it. In the above example if you move the using statement inside the namespace declaration then the namespace will be defined before the compiler realizes a circular reference has occurred.

  using System;
  ...
  
  namespace Timesheet.Controls
  {
  using Timesheet.Pages;
  
  //MyControl
  }
  
  using System;
  ...
  
  namespace Timesheet.Pages
  {
  using Timesheet.Controls;
  
  //MyPage using MyControl
  }

  I'm not sure how the compiler handles references but I would gather that it compiles an entire file at a time but compiles the files in an order such that it can forefill reference requirements. Therefore this solution only works for now given your situation. I can imagine that you will later find cases (such as during maintenance) where it'll fail again. You still have the circular reference problem(Control A relies on Page B which relies on Control A). It works now because of a compiler implementation detail. I suspect that if you added another object to the circular list that it would fail again. You might want to consider adding a layer of isolation between your page and control so that you can break the circular reference issue.

  IMHO,
  Michael Taylor - 6/22/06

  
  

• Octayn

  Most modern compilers are single pass compilers although some still act as a multipass compiler. The C++ compiler actually doesn't support what you wanted. In C++ as soon as the compiler hits a symbol it must be declared or else it won't compile, hence the need for a forward reference syntax. The following won't compile in C++:
  
  void Foo ( )
  {
  Foo2();
  }

  void Foo2 ( )
  {
  }
  
  But through a forward reference (normally contained in a header file) it will. C# doesn't support forward references and therefore the compiler goes through some hoops to defer mapping a symbol to its actual type until absolutely necessary. I use to write compilers for a living and I can assure you that this is no easy task. The fact that C# pulls it off so well is an attribute to the compiler team at MS.

  Nevertheless I don't believe it is necessarily a circular reference as much as it is an incomplete reference when the parser gets to it. I think it is caused by how the web site is built and not a limitation of C# itself. In order to build the actual Page-derived class the build has to enumerate through the ASPX page and build the partial class behind the scenes. Since you have a control inside your page it'll want to compile the control's code. However it can't do that because your control requires access to the Timesheet.Pages namespace which it technically hasn't built yet (or at least finished building). Therefore it can't build the control class and you get the compilation error.

  I duplicated your problem by creating a simple website with the default page. I moved the default page to Timesheet.Pages and added a using to Timesheet.Controls. I then created a user control contained in the Timesheet.Controls namespace and added a using statement to Timesheet.Pages. I then compiled and it worked. Now I dropped the user control onto the page and it fails with the error you saw. I believe the interaction between the ASCX and the code is causing the compiler to lose its mind. Whether it is a bug or simply by design I don't know. Perhaps someone from the ASP.NET team will respond with an answer to your dilemma.

  Michael Taylor - 6/22/06

  
  
• Types and namespaces can't be found