[ACCEPTED]-Why does the message BC30560 'mymodule_ascx' is ambiguous in the namespace 'ASP' come up sometimes then go away?-asp.net

I recently came across this problem and 12 it was only happening on one server even 11 though all were running the same code. I 10 thoroughly investigated the problem to make 9 sure there were no user controls with clashing 8 names, temp files were cleared out, etc.

The 7 only thing that solved the problems (it 6 seems permanently) is changing the batch 5 attribute of the compilation element to 4 false in the web.config, as suggested in 3 the following link:

http://personalinertia.blogspot.com/2007/06/there-bug-in-compiler.html

<compilation debug="true" batch="false">

I firmly believe that 2 this is in fact a bug in the compiler as 1 suggested on that site.

I just solved this problem with the assistance 9 following link: http://www.netomatix.com/development/usercontrols2.aspx

In a nutshell, your class 8 is called MyModule. However, if you do 7 not specify the ClassName property in the 6 @Control directive, the compiler may append 5 _ascx to the control's class, which results 4 in MyModule_ascx. Since the page can't 3 find MyModule_ascx, it blows up in your 2 face. You need to explicitly tell it the 1 ClassName...

<%@ Control Language="vb" AutoEventWireup="false" CodeBehind="MyModule.ascx.vb" ClassName="MyModule" %>

Another possibility:

http://channel9.msdn.com/forums/TechOff/157050-BC30560-mycontrolascx-is-ambiguous-in-the-namespace-ASP/

Seemed to have some 1 success with changing

src="mycontrol.ascx.cs"

to

CodeBehind="mycontrol.ascx.cs"

I've just suffered this. Stuff that worked 11 fine and was untouched for months started 10 randomly failing after some unrelated updates. I'd 9 recompile and the problem would disappear 8 only to reappear somewhere else.

I seem 7 to have resolved it by clearing out the 6 ASP.NET temporary folder, e.g. C:\Windows\Microsoft.NET\Framework\v2.0.xxxxx\Temporary 5 ASP.NET Files. This required an IIS restart 4 to really clean it out.

Update: I tried adding 3 tempDirectory="e:\someotherfolder" to the compilation element of the web.config and that 2 seems to have had some success. Also added 1 batch="false" but not sure if that's had an effect.

I used to have this problem sometimes too. If 9 I remember correctly it was caused by something 8 like the following:

<%@ Page Inherits="_Default" %>

or perhaps

<%@ Page ClassName="_Default" %>

Or something 7 like that. I'm not 100% sure which attribute 6 it was (it's been a while).

But look look 5 for something like _Default in your Page 4 directive and replace them with actual class 3 names in all of your files. For some reason, ASP.Net 2 doesn't always interpret the _Default correctly, yielding 1 temporary ambiguous references.

Similar to the two previous answers, you'll 16 most probably have a "copy and pasted" copy 15 of an existing page in the same site, and 14 this will then contain the same @Page directives 13 which will lead to a clashing of functions 12 (especially because everything in .Net defaults 11 to Partial Classes.) This little gem has 10 bitten me all-too-often.

Just update the 9 "Inherits" to point to something specific 8 to your page (i.e.: your page name prefixed 7 by an underscore -- as it's more-often-than-not 6 guaranteed to be unique), and ensured that 5 you haven't got two Public Partial Classes 4 named the same in different code-behind 3 files (otherwise Page_Load in _Default [default.aspx], will 2 clash with Page_Load in _Default [copy of 1 default.aspx])

Try to change web.config, set batch to false 1

<compilation batch="false">
</compilation>

For me this error was a red herring. In 10 reality one of the user controls had errors 9 caused by .NET 2.,0 to 4.5 migration, which 8 had to be fixed in the code, but VS threw 7 this misleading error messages. After multiple 6 attempts to upgrade the projects it finally 5 started erroring on the actual lines of 4 code, but I don't know how to reproduce 3 this after hours of frustration and fruitless 2 attempts to apply solutions from all over 1 the Internet.

Also ran into this with MasterPages on projects 5 that were originally .net 1.1 and 2.0 projects 4 and later converted. In both cases, the 3 @MasterType directive referenced the virtualpath. I 2 changed to <%@ MasterType TypeName="MasterPages_MasterPage" %>, cleaned 1 the solution and the problem went away. HTH

Rebuild Solution worked for me.

0