BC30560: ​'mycontrol_​ascx' is ambiguous in the namespace '_ASP'

Anyone ever got this error before and know how to fix it?

It just started happening to me for no apparent reason. All I did was edit the file. It is not compiled by Visual Studio, but dynamically:

<%@ Control Language="C#" src="mycontrol.ascx.cs"
    Inherits="MyNamespace.MyStuff.MyControl" %>

Even though it is used on several pages, it only occurs on one of them. It has been in use for several years (so I know the code works).

Someone else had this problem with .NET 1.0 (I am using 1.1): error generated while debug is off, but no one answered. When debug is set to 'true' it works, when removing (or setting to 'false') the error occurs. Restarting the server is not an option (I did restart IIS, but that didn't work).

Does your control also inherit:

System.Web.UI.INamingContainer

?

No. All it is in the code behind is:

namespace MyNamespace.MyStuff
{
    public class MyControl : UserControl
    {
        #region Web Form Designer generated code
        override protected void OnInit(EventArgs e)
        {
            //
            // CODEGEN: This call is required by the ASP.NET Web Form Designer.
            //
            InitializeComponent();
        }
        /// <summary>
        ///        Required method for Designer support - do not modify
        ///        the contents of this method with the code or.
        /// </summary>
        private void InitializeComponent()
        {
            this.Load += new System.EventHandler(this.Control_Load);       
        }
        #endregion
       
        private void Control_Load(object sender, EventArgs e)
        {
            // do something
        }
    }
}

Changing the namespace does not fix it either. It is fine in all the pages it is used on except for one.

Edit:
I do have an assembly with the same namespace in the bin folder (MyNamespace.MyStuff.dll), but all it has it data access classes, no custom control code.

I was hoping it was a temporary glitch, so I changed debug back to false. Problem still occurs. How come no one else has this problem (and those that do never get an answer). I use the same code on another site and there are no issues, and also on other pages in the same site.

Microsoft (R) Visual Basic .NET Compiler version 7.10.6001.4
for Microsoft (R) .NET Framework version 1.1.4322.2032
Copyright (C) Microsoft Corporation 1987-2002. All rights reserved.

C:\WINNT\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files\root\63f9fc51\3d007a0e\telq_wit.0.vb(1002) : error BC30560: 'mycontrol_ascx' is ambiguous in the namespace '_ASP'.

            Dim __ctrl As _ASP.mycontrol_ascx
                          ~~~~~~~~~~~~~~~~~~
F:\intranet\folder\default.aspx(238) : error BC30560: 'mycontrol_ascx' is ambiguous in the namespace '_ASP'.

            __ctrl = New _ASP.mycontrol_ascx
                         ~~~~~~~~~~~~~~~~~~
F:\intranet\folder\default.aspx(238) : error BC30560: 'mycontrol_ascx' is ambiguous in the namespace '_ASP'.

        Protected MyControl As _ASP.mycontrol_ascx

The file 'telq_wit.0.vb' does not seem to exist (is it deleted when an error occurs?).


The exception:

System.Web.HttpException: External component has thrown an exception. ---> System.Web.HttpCompileException: External component has thrown an exception.
   at System.Web.Compilation.BaseCompiler.ThrowIfCompilerErrors(CompilerResults results, CodeDomProvider codeProvider, CodeCompileUnit sourceData, String sourceFile, String sourceString)
   at System.Web.Compilation.BaseCompiler.GetCompiledType()
   at System.Web.UI.PageParser.CompileIntoType()
   at System.Web.UI.TemplateParser.GetParserCacheItemThroughCompilation()
   --- End of inner exception stack trace ---
   at System.Web.UI.TemplateParser.GetParserCacheItemInternal(Boolean fCreateIfNotFound)
   at System.Web.UI.TemplateParser.GetParserCacheItemWithNewConfigPath()
   at System.Web.UI.TemplateParser.GetParserCacheItem()
   at System.Web.UI.TemplateControlParser.CompileAndGetParserCacheItem(String virtualPath, String inputFile, HttpContext context)
   at System.Web.UI.TemplateControlParser.GetCompiledInstance(String virtualPath, String inputFile, HttpContext context)
   at System.Web.UI.PageParser.GetCompiledPageInstanceInternal(String virtualPath, String inputFile, HttpContext context)
   at System.Web.UI.PageHandlerFactory.GetHandler(HttpContext context, String requestType, String url, String path)
   at System.Web.HttpApplication.MapHttpHandler(HttpContext context, String requestType, String path, String pathTranslated, Boolean useAppConfig)
   at System.Web.MapHandlerExecutionStep.System.Web.HttpApplication+IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

Did you try inheriting System.Web.UI.INamingContainer in your control? Might help with the conflict...

Harlequin wrote:

Did you try inheriting System.Web.UI.INamingContainer in your control? Might help with the conflict...

That didn't help. I thought it might have been a namespace conflict (I have an assembly in my bin folder in the same namespace as the user control), but it didn't seem to be (because I changed the namespace the control was in and it still happened).

Edit:
I guess I will have to wait until the next reboot (one caused by Windows Update) as I can't reboot the server because it is used for our helpdesk.

    Probably it's not the problem with the user control, it's the problem with the page containing the control, can you post the code related to that page here?

Sheva

footballism wrote:

    Probably it's not the problem with the user control, it's the problem with the page containing the control, can you post the code related to that page here?

Sheva

There are several user controls, but only one of them is called mycontrol.ascx

It is making no sense at all. Changing src="mycontrol.ascx.cs" to CodeBehind="mycontrol.ascx.cs" makes it work. But when I look in the bin directory of the web application, none of the assemblies contain the definition of the control. So it is somehow not deleting the temporary assembly when recompiling. Like I said before, it has only just recently happened (the server does now have .NET 2.0, but the web app uses 1.1).

Is there a way to reset permissions for the "Temporary ASP.NET Files" folder, or delete the contents of it?

Edit:
This is the error on MSDN2 (I can't find it on MSDN 1)
'<name>' is ambiguous in the namespace '<namespacename>'. Why does it not occur in debug mode? It is not ambiguous, there is only one control for the whole site with that name (and it is even under its own namespace).

Do you have any dll's in your bin directory you renamed recently?

Like:
/bin/MyClassLibrary.dll
...to...
/bin/MyClassLibrary.BAK.dll

sbc wrote:

Is there a way to reset permissions for the "Temporary ASP.NET Files" folder, or delete the contents of it?

    You are right, the real culprit behind it is that the temporary dll files won't delete, you can clear the IE cache(via Internet Explorer->Tools->Internet Options), then the temporary files will be cleared too.

Edit: if you want to manually clear the temporary file folder, then you have to shut down the ISS to turn the write lock off on this foler, then you can arbitrarily delete the dll files.

Sheva

I guess I will have to keep it in debug mode as it is the only solution that consistently works. I would have thought if there was an ambiguous control in the application the error would occur in debug mode, but obviously not.

Does the ASP.NET compiler compile all cs files it finds in a directory (regardless of whether or not it is referenced by a control)?

Perhaps somehow the installation of .NET 2.0 has affected .NET 1.1 (that is the only thing I can think of that would do this), even though the web app doesn't use .NET 2.0

Harlequin wrote:

Do you have any dll's in your bin directory you renamed recently?

Like:
/bin/MyClassLibrary.dll
...to...
/bin/MyClassLibrary.BAK.dll

No. But I deleted them all then regenerated but no such luck.

It seems like an obscure bug in the compiler that no one can seem to replicate.

sbc wrote:

Perhaps somehow the installation of .NET 2.0 has affected .NET 1.1 (that is the only thing I can think of that would do this), even though the web app doesn't use .NET 2.0

A friend of mine uses dasBlog on Windows Server 2003. Installing .NET 2.0 apparently broke it. His fix was to ensure that .NET 1.1 apps live in a different application pool from .NET 2.0 apps. Application pools share worker processes, and a process can only load one version of the .NET Framework, whichever is the first to load.

I don't know if this is relevant to your problem, but if you're on Windows Server 2003, it's probably worth trying.

Mike Dimmick wrote:

sbc wrote:Perhaps somehow the installation of .NET 2.0 has affected .NET 1.1 (that is the only thing I can think of that would do this), even though the web app doesn't use .NET 2.0

A friend of mine uses dasBlog on Windows Server 2003. Installing .NET 2.0 apparently broke it. His fix was to ensure that .NET 1.1 apps live in a different application pool from .NET 2.0 apps. Application pools share worker processes, and a process can only load one version of the .NET Framework, whichever is the first to load.

I don't know if this is relevant to your problem, but if you're on Windows Server 2003, it's probably worth trying.

It's Windows 2000 Advanced Server. Do you think setting "Application Protection" to "High (Isolated)" would work?

The server hosts two intranet sites, and several others (for testing web sites before uploading to remote location).

Enough time has passed, I hope you found a solution. I had the same error on a Server 2003 Small Biz edition, also replicated in XP MCE and after lots of pouring through Google and Google groups, I found a solution in the comments of a Scottgu article. It suggested using adding the ClassName directive to the Controls ascx page. That resolved the problem.

dean-o said:

Enough time has passed, I hope you found a solution. I had the same error on a Server 2003 Small Biz edition, also replicated in XP MCE and after lots of pouring through Google and Google groups, I found a solution in the comments of a Scottgu article. It suggested using adding the ClassName directive to the Controls ascx page. That resolved the problem.

Thank you for posting that dean-o. I still haven't found a solution and it's happening to me right now. Hopefully that ClassName directive will work for me.

Thanks again!

*EDIT*
That fix did not work

I still have no idea  how to get this to work. I am using user controls as header/footer/sideBar and when I change them, and refresh the page it throws this error. How do I get this to not happen on live? Can I force a cache clear or something?

vipergtsrz said:

dean-o said:

*snip*

Thank you for posting that dean-o. I still haven't found a solution and it's happening to me right now. Hopefully that ClassName directive will work for me.

Thanks again!

*EDIT*
That fix did not work

I still have no idea  how to get this to work. I am using user controls as header/footer/sideBar and when I change them, and refresh the page it throws this error. How do I get this to not happen on live? Can I force a cache clear or something?

Not sure if you still have the same issue, but I did and since this was one of the first google hits, I thought I'd add my solution.

Reading around on the web it seems that there is no "fix-for-all'.

Clearing caches, removing old dll's and the like, rebooting a couple of times etc did not solve my problem. It started when I loaded a new version of a third-party dll. Attempting renaming and the likes of that is not feasable for me.

Finally, I discovered in my web.config that it still had a reference in the assemblies section to the old version of the dll. Completley removing that tag solved the problem!

If I am not mistaken, this is a relic of older versions of the framework where you had to specify referenced assemblies (or even got them automatically?). This project is currently running on Framework 2.0, but it has been on earlier versions as well, so probably residual code from 1.0 or 1.1 that caused this.

Hi Guys,

I was having a similar problem when trying to publish a website to a local folder, but only when in "Release" mode, not "debug" mode. I removed a lot of the temporay folders withnames like "dc38e696" for my project in "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files" and the issue went away.

Hope that helps someone!

Regards,
Duane.