The type 'x' is defined in an assembly that is not referenced. You must add a reference to assembly 'abc123'.
I have a .NET 2.0 web application that references my assembly 'abc123'. The assembly exists in the GAC and I've verified that it is the correct(same) version. The rest of application has no issues except for one .aspx page. The page in question has a repeater that displays a user control as one of its "fields". Upon binding a list of type y to the repeater I pass the user control a list of type x (a property of y) as shown here:
<uc1:usercontrol id="ucusercontrol " runat="server" myPublicUserControlProperty='<%#Eval("CollectionOfX") %>'/>
On the user control's property set, I bind the list of type x to a gridview in the user control.
One strange thing to note is that this report works fine on my development pc but not on any servers once I deploy. My pc is Windows XP, IIS6, VS2005. The servers are Windows Server 2003, IIS6.
I hope I explained that well enough. Thanks in advance for any insight you can provide.
I'm Mike's coworker, and we worked out a solution.
The type X is defined in his assembly, that is only in the GAC. Even though his ASP.NET web appplication did have a reference, it was failing to load from the GAC only for this UserControl. The rest of the application worked as expected. We confirmed the failed loading by placing a copy of the assembly in the bin directory, and everything worked. We removed the assembly, and the problem came back.
Our solution was to manually add an entry to the web.config in the assemblies section to point ASP.NET to the GAC.
It looks like any time you reference a type in the page (not the code-behind), you need the assembly information defined in the web.config file or in a page directive.
<assemblies>
<add assembly="MyAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=[MyPublicKeyToken]"/>
</assemblies>
There's also a bug that can manifest itself with similar symptoms, described here.
The workaround is to delete everything in the C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\ directory, and it only seems to manifest itself in debug mode.
When troubleshooting these types of problems, the Fusion Log Viewer has always been a great help.
I found that if type x is actually a class in your App_Code, dirtying it and re-saving often forces the web app to recompile and solves the problem.
More often than not, it is because of the cached assemblies. One way resolve this issue is by making the "strong reference" in the proj or config file. Refer this blog post
I had the exact same error, but I had a public constructor in my class that used as a parameter, an object from another project.
I resolved the problem by making that constructor internal.
For me it was a version control pull problem.
In Visual studio, open "References" in your Solution explorer, and scroll through it.
If anything has a yellow warning triangle on it, remember the name, remove it, and add it back again (or have ReSharper do it for you).
Happened to me several times after pulling a project when a co-worker added a new package and references.
