title: Visual Studio 2008 losing intellisense for ASCX with CodeBehind (but works for CodeFile)?
body: <p>I have the following definition at the top of my .ASCX file:</p>
  
  <pre><code>&lt;%@ Control Language="C#" AutoEventWireup="true" CodeBehind="ArticleView.aspx.cs" Inherits="MyNameSpace.ArticleView" %&gt;
  </code></pre>
  
  <p>In that control I make use of &lt;%= %> blocks to refer to members that I've declared in the code-behind file.  If I compile and deploy the control, it works fine.  But in Visual Studio I get a lot of design-time errors, "{some variable} does not exist in the current context."  And Intellisense breaks too: it works for members of UserControl, but can't find my own declared members.  There are other issues as well.  In general, everything points to the fact that the ASP.articleview_ascx class getting generated is somehow not inheriting from the MyNameSpace.ArticleView class.</p>
  
  <p>I've found that if I switch the CodeBehind attribute to "CodeFile":</p>
  
  <pre><code>&lt;%@ Control Language="C#" AutoEventWireup="true" CodeFile="ArticleView.aspx.cs" Inherits="MyNameSpace.ArticleView" %&gt;
  </code></pre>
  
  <p>suddenly Intellisense works and all the design-time errors disappear.  But I don't want to do runtime compilation, or deploy my .ASCX.CS files - so I can't use CodeFile.</p>
  
  <p>I've checked the simple stuff, like making sure that my CodeBehind filename is correct &amp; the Inherits class has the proper namespace, etc.  (And since it works properly after changing the attribute to CodeFile, those must be pointing at the right place....)  But what am I missing?  Why can't it handle the CodeBehind attribute?</p>
  
  <p>Thanks,<br>
  Steve</p>
  
  <hr>
  
  <p>Update: from a thread below - basic question was, why not just use CodeFile?  Answer: when I try to deploy using CodeFile= in my files, after deploying I receive the following stack trace (presented in its entirety):</p>
  
  <blockquote>
    <p>/_layouts/Pages/ViewPage.aspx.cs' does not exist. at System.Web.UI.Util.CheckVirtualFileExists(VirtualPath virtualPath) at System.Web.UI.TemplateParser.ProcessCodeFile(VirtualPath codeFileVirtualPath) at System.Web.UI.TemplateParser.ProcessMainDirectiveAttribute(String deviceName, String name, String value, IDictionary parseData)</p>
  </blockquote>
  
  <p>(This is from a request to /_layouts/Pages/ViewPage.aspx.  ViewPage is the page that has several other controls including the ArticleView mentioned in my original example.  It just happens to be the first file that fails - if I go back to CodeBehind= in ViewPage, then included ASCX with CodeFile= will fail in the same way.)  This seems to be the page compiler complaining because the inherited codebehind class can't be found in any loaded DLL, so it expects there must be a CS file to do on-demand compilation.</p>
  
  <p>The issue here is that I don't want to deploy CS files, just ASPX/ASCX.  Having read through many articles like <a href="http://www.west-wind.com/presentations/AspNetCompilation/AspNetCompilation.asp" rel="nofollow noreferrer">this great one</a> I'm aware of the various new models of deployment, although I've never used anything but a Web Application Project (converted forward from VS2003, we were late adopters of 2005 &amp; the WAP model had already been added by the time we switched up from 2003.)  Over many VS2005/8 projects, I've never had a problem with CodeBehind=, until this Intellisense issue showed up...  though it doesn't help that in this case I'm deploying to SharePoint, which introduces a whole new level of complexity.</p>
  
  <p>Since I've not deployed using CodeFile before, it's very likely that I'm missing some option I'm supposed to set in VS when building, in order to force a pre-compile.  I just need to be able to deploy, as I do today, as a set of ASPX/ASCX with a single codebehind DLL.  And that's working today with CodeBehind= ... it just has the originally mentioned Intellisense problem, which is really what I want to fix :)</p>
  
  <p>Will post more as I identify what files might be relevant to the question...</p>