"Control cannot be created because Visual Studio cannot find the control’s type in the control assembly"

I just got a new machine, an Acer laptop with enough bells and whistles to make a developer happy (Core 2 Duo, 2GHZ, 2 GB RAM). As usual I test drive it on a Web Application Project I was working on in VS 2005. The source files came from an old laptop of mine. The new laptop has been painstakingly updated with all the required patches, and Service Packs, both for the OS (SP2 for WinXP) and the VS 2005 (SP1). I even installed the .NET Framework in sequence (1.1 and its SP, 2.0 and its SP; no .NET Framework 3 though; I have no need for it yet).


But then while working on one of the web pages, all of a sudden I encountered this error ("Control cannot be created because Visual Studio cannot find the control’s type in the control assembly"). This happens when I drag and drop an Ajax Control from the Toolbox to my web pages. Thinking it has something to do with my entire project, I tried compiling and it compiled fine. In fact, I can even run and debug the application. That means the application is fine; it's the IDE that's acting out.

What I did was to create a fresh Web Application Project, and add the files from the existing project one by one to the new project. I referenced all the usual suspects, the AjaxControlToolkit DLL, the System.Web.Extensions, etc, until I can compile the project and debug it.

Then I tried doing the Drag and Drop operation of an Ajax control again from the toolbox. Still the same error: "Control cannot be created because Visual Studio cannot find the control’s type in the control assembly".

As usual, being a good developer, I did what is expected of me: I searched the Internet, and look for possible solutions. Surely, I said, somebody must have come across the same problem as I did. In fact, a lot of people did. Some have successfully fixed their machines, some still crying for help. I tried all the solutions mentioned:

1. Double-checking the web.config file for outdated entries (entries which are not supported by the current Framework, in case this came from a beta project for example (which it is not), (look here);
2. added the ASPNET account to the project folder;
3. created a new Web Site project (instead of Web Application Project) since this might be related to the type of project (see this one, although it refers to a Vista issue for WAP);
4. I even registered it in GAC as suggested in the ASP.NET forum here.

All in all, I created 6 new Web Application Projects and Web Site projects just to test this issue.

To no avail.

What worked for me? Here's what:

1. I opened the project properties, and set to "Use the Visual Studio Development Server".
2. I checked the "NTLM Authentication". (Upon doing another test, it turns out this is optional in my case. See if this works for you).
3. Save.

Voila! Everything is working fine!!! (Even if I removed the AjaxControlToolkit DLL from the GAC)

But I know this is not yet the final solution since what if I want to use IIS instead of the VS2005 web server? Well, that's another adventure. I'm quite satisfied as it is now.

UPDATE:
It turns out, it has something to do with my project settings. I used to have this setting when I'm encountering the error: I have the "Use IIS Web server" setting, and the "Project Url" points to this: "http://localhost/cpms/v2". Note that my project is named "CPMSNet_Web4". If you looked at the URL, that URL points to another folder (which means it is not the same folder containing my current web application project).

You might ask why would I do that, that is point my project to use a different target URL than the one my actual project is pointing to? Let me show you my setup and rationale for this setting:

1. Again, the URL shows that my target points to "http://localhost/cpms/v2". When I use this, I get the expected error we are talking about.
2. Notice that the URL is not the usual Protocol://Machine/VirtualDir setup. Instead of the Protocol://Machine/VirtualDir, what I have is Protocol://Machine/VirtualDir/SubVirtualDir. This means that my ASP.NET project is actually a sub-virtual directory of another (parent) virtual directory.
3. The target URL is the URL where I publish my project.

Question is: why the setup?

The short answer is: the root virtual directory is a Classic ASP project that shares some Session variable with the new ASP.NET project (the subweb). It's a solution to a goal: migrate the application on a per requirement/module, not in one big bang.

It turns out that if I point the URL to my current project, the problem goes away completely.

I hope this helps those who are having the same problem as I do.