ASP.Net error: "The type 'foo' exists in both "temp1.dll" and "temp2.dll"
Asked Answered
S

26

110

When running a web application project, at seemingly random times a page may fail with a CS0433 error: type exists in multiple DLL's. The DLL's are all generated DLL's residing in the "Temporary ASP.NET Files" directory.

Scare answered 16/12, 2008 at 14:16 Comment(0)
S
136

Add the batch="false" attribute to the "compilation" element of the web.config file.

This problem occurs because of the way in which ASP.NET 2.0 uses the application references and the folder structure of the application to compile the application. If the batch property of the element in the web.config file for the application is set to true, ASP.NET 2.0 compiles each folder in the application into a separate assembly.

http://www.sellsbrothers.com/1995

http://support.microsoft.com/kb/919284

Scare answered 16/12, 2008 at 14:19 Comment(4)
Man, thanks for that. Was scrambling to fix this in a production site today. Don't know what caused it yet (had been working fine for so long!), but this has fixed the issue for us.Surgical
thanks. This works. Woke up this morning with this error. MY ISP discountasp.net must have changed something. If it were not for this post, I'd still have the error. Thumbs down for my ISP.Demigod
Helpful answer - syntax is here: <compilation ... batch="false"/>Across
Heed this warning: "This method is recommended only for small applications... This causes memory fragmentation."Flyleaf
A
22

This might happen if you place .cs files in App_Code and changed their build action to compile in a Web Application Project.

Either have the build action for the .cs files in App_Code as Content or change the name of App_Code to something else. I changed the name since intellisense won't fix .cs files marked as content.

More info at http://vishaljoshi.blogspot.se/2009/07/appcode-folder-doesnt-work-with-web.html

Aggri answered 26/8, 2013 at 10:48 Comment(0)
P
11

One possible reason for this error is that there are 2 aspx pages which are having the same name in their inherits= in the <@page language=......inherits=> line.

Changing the inherits= name solves the error.

Postprandial answered 20/4, 2012 at 6:1 Comment(1)
This solved my problem, seems copy/paste of a usercontrol is a bit tricky when you don't need the codebehind to do anything.Dentil
K
8

Just in case someone else shares my problem, I got this error when trying to publish a Web Site of a newly branched project, build worked perfectly.

Turns out I had forgotten to remove the checkbox for "Allow precompiled site to be updatable" under publish Settings -> Configure precompile.

Kleiman answered 16/2, 2016 at 8:5 Comment(0)
F
4

As another data point, I just had this problem without any evidence of circular references as described in the links in Ben's answer. Building my web site project would fail with a few of these errors, and setting compilation batch="false" fixed it, but I didn't want to go that route as this is a large-ish production website.

This solution was in a subfolder of my D:\svn folder, which I had mapped to S:. When I opened the solution from S:, these errors occurred, but if I went straight to D:\svn and opened the solution, no errors.

I also noticed that, despite having compilation batch="true" in my web.config, when opening the solution from the mapped S: drive all my .ascx files get compiled into their own assemblies. If I open it from the physical location, the .ascx files get compiled into their respective folders' assemblies (which is how batch="true" is supposed to work).

Strange.

Fumigate answered 3/4, 2009 at 15:2 Comment(0)
E
4

This error was due to conflict between class name of web form and wsdl stub(code behind file .cs) having the same class name i.e.

ASPX page: Dashboard Class: partiacl class Dashboard

AppCode/APIServices.cs: public partial class Dashboard

Error was reproducible only on publishing the website but build and debug did not inform any error.

Edger answered 30/8, 2011 at 8:56 Comment(0)
O
3

In my case deleting all output assemblies from bin folders in all projects in the solution solved the issue. Unfortunately I have no explanation for it.

Oratorio answered 6/3, 2013 at 20:29 Comment(0)
W
2

In my case I had renamed a project, so also the dll had been renamed. When I just copied the new dll but didn't think of deleting the old one from the server, I soon had a bunch of pairs of classes with the same names. Deleting the outdated dll's was doing the trick (of cause).

Withershins answered 10/7, 2012 at 6:48 Comment(0)
I
2

None of these answers worked for me, however I did fix the problem. Since I was using VS's Publish function to deploy the web application, I selected the option to delete all existing files prior to publish in the Publish Web wizard. This forced a clean copy of the application and everything worked fine from there.

This solution might be helpful if your local debugging copy works fine but published system isn't. Also great if you don't want to take the time to track down individual dlls to delete and don't mind the production files being deleted first.

Interdependent answered 5/1, 2015 at 0:53 Comment(0)
R
1

In my case, the problem was solved when I edited a Designer.cs file that still had the duplicated class name. for some reason, when i renamed the class "logout" to "logout2", in the designer file it was not automatically changed, and was still "logout", and this class name already existed in a precompiled dll in my project (that belongs to a third party web app that I work with and develop around of).

Ramify answered 19/12, 2011 at 15:49 Comment(1)
If you come up with a new way to cause the error message, feel free to add it :)Scare
G
1

Got this problem when put a part of an aspx page into the separate user control. On my machine everything was fine, on the server got an error.

Renamed the problem class and file.

http://support.microsoft.com/kb/919284 Method 2: Reorder the folders in the application is writing about possible circular references

Gridiron answered 15/5, 2012 at 15:36 Comment(0)
B
1

None of these solutions worked for me. Both of my conflicting DLLs were in C:\...\AppData\...\Temporary ASP.NET Files\...

The problem was that I had rolled back my source repo to an earlier version - before we moved a type from one project to another project within the same solution.

I tried deleting the newer DLL - which should not have even been there at all in the older codebase - from the "Temporary ASP.NET Files" location identified by msbuild. msbuild just put it back.

I also tried the web.config setting that some here have used successfully, but that did not work either. Although, as I write this, I realize that there were actually two MVC projects within the same solution and both had errors, so the problem may have been that I did not add the setting to both.

I tried rolling my source repo forward and cleaning and rolling back again and cleaning. Nothing.

I tried deleting everything the "Temporary ASP.NET Files" location. msbuild just put it back again.

Finally, I tried rebuilding in Visual Studio. Although the command line output and the "Errors" output both gave the same msbuild "Temporary ASP.NET Files" error, the Intellisense error - when hovering over the conflicted type - actually complained about DLLs in output directories. Apparently "Clean" and "Rebuild" were not doing their jobs. I manually deleted the DLLs in the output directories identified by Intellisense, and the problem was solved.

tl;dr - Make sure you're covering all of your web.configs with the batch setting, and try to leverage Intellisense for further clues.

Broeker answered 16/3, 2016 at 14:34 Comment(0)
E
1

My problem was linked to a .dll that was getting generated in my project folder.

If you are referencing another file, instead of doing everything you see above, what fixed my problem instantly was just deleting the .dll that was staying inside my /bin directory for my project.

The problem isn't necessarily a web.config fix - it's a circular reference that needs to get resolved. I realized that I cleared the old .dll in my original project file but not in the project that was referencing it.

I don't recommend making the modification to your web.config file because that's just a band-aid fix - not really addressing the actual problem. Do that if you don't feel like fixing the problem, but if you want to avoid future headaches, just remove the .dll from both places.

Eva answered 30/3, 2016 at 22:36 Comment(0)
M
1

I had a partial class with the same name in two different projects. I solved it by only leaving it in one project.

Macron answered 3/5, 2017 at 14:0 Comment(0)
C
1

None of this solutions worked for me. Compiling in "Release" mode worked, but when I switched to "Debug" I got umpteen of this error Messages.

I don't understand why, but a simple restart of Visual Studio was my solution.

Context answered 13/7, 2017 at 9:48 Comment(0)
C
0

Sometimes it may help to remove the solution and create it again. Since this use to happen when converted from VS2005 to vs2010 some references to framework 4.0 (after upgrading ) remains in the solution, even all projects are defined as 3.5.

Normally rebuilding the solution should clear these problems.

Cyanamide answered 6/3, 2013 at 8:10 Comment(0)
M
0

I had the same problem when I was compiling the application on a compiling server.

My controller had a simple static code, so I changed my ascx:

 <%@ Control Language="C#" AutoEventWireup="true" CodeBehind="controllerName.ascx.cs" Inherits="Controls.controllerName" %>

To

 <%@ Control Language="C#" AutoEventWireup="true" Src="controllerName.ascx.cs" Inherits="Controls.controllerName" %>

Also removed the partial keyword from the codebehind and added a namespace to the codebehind.

This:

using System;
using System.Web.UI;

/// <summary>
/// My controller
/// </summary>
public partial class controllerName: UserControl
{
    protected void Page_Load(object sender, EventArgs e)
    {
    }
}

To this:

using System;
using System.Web.UI;

namespace Controles
{
    /// <summary>
    /// My controller
    /// </summary>
    public class controllerName : UserControl
    {
        protected void Page_Load(object sender, EventArgs e)
        {
        }
    }
}

And that worked for me.

Manana answered 26/7, 2013 at 21:13 Comment(0)
S
0

For me this happened when I had my PrecompiledWeb/Publish location set to the current directory which was where the site's root folder was too.

My Web Site was then seeing the publish folder as part of the project when compiling/building and then finding duplicates in that manner.

i.e. Don't put the published/precompiled version of your site in your site's code folders.

Shelba answered 17/9, 2013 at 3:40 Comment(0)
M
0

I faced with the problem in compile time.

I agree with the batch="true" attributes, error is telling there exist 2 assembly

Solution 1: deleting one of them

Solution2: Configure one of them

Marchal answered 2/12, 2014 at 11:0 Comment(0)
E
0

If the DLL's are showing in a temporary folder, you should try cleaning your solution.

Euripus answered 11/3, 2015 at 11:53 Comment(0)
L
0

Posting my solution:

The issue was related to the "On-Access Scan" of Mcafee Antivirus. Disabling this solved the problem. Somehow, the ASP Temporary folder was not being used properly by ASP when the antivirus was ON.

Hope this helps someone.

Lactoflavin answered 7/7, 2015 at 15:17 Comment(2)
Did you know why? My team also have this problem, and they say it is because of McAfee, however, based on corporate IT rules, we cant deactivate antivirus (which shouldnt interfere!).Crofoot
We are still working on finding the exact cause. Unfortunately excluding the ASP Temporary folder from the On-Access Scan does not eprmanently solfe the issue.Lactoflavin
P
0

App_Code folder is causing the problem , put the class outside the folder (Works fine)

App_Code folder is not designed for Web Application Projects

http://vishaljoshi.blogspot.in/2009/07/appcode-folder-doesnt-work-with-web.html

Pyle answered 28/5, 2016 at 8:0 Comment(0)
O
0

Go to Add reference and search for both the dll, Both of the dll would have checked, uncheck one of the dll, as there are references to the same dll with different version ambiguity gets generated.

Occident answered 23/6, 2016 at 7:13 Comment(0)
K
0

My solution was to replace CodePage="...." with CodeBehind="..." in the .aspx file. Somehow it was left as CodePage during a migration from previous .NET versions. This page directive creates another dll file which conflicts with the projects dll file.

Knight answered 18/10, 2016 at 10:25 Comment(0)
S
0

Had a similar problem, In my case, I noticed, that cleaning a solution doesn't clear the bin folder in the visual studio. There was old compiled .dll present in the folder that is causing the issue.

Solutions:

  1. Manually delete bin folder and recompile
  2. In case of publish, select delete existing files prior to publish.

This will solve the issue.

Sheerlegs answered 13/5, 2022 at 7:2 Comment(0)
D
0

You should define an alias for one of your references.

In your project file .csproj add the following item:

<ItemGroup>
    <Reference Include="temp1.dll">
      <Aliases>MyAssembly</Aliases>
    </Reference>
</ItemGroup>

After adding the above ItemGroup, MyAssembly will represent a root namespace that will contain all namespaces in the assembly temp1.dll.

Then you can have access to the type foo, which is located in temp1.dll, as follow:

using MyAssembly.foo;
Douse answered 28/11, 2022 at 13:31 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.