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.
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
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
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.
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.
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.
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.
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.
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).
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.
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).
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
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.
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.
I had a partial class with the same name in two different projects.
I solved it by only leaving it in one project.
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.
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.
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.
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.
If the DLL's are showing in a temporary folder, you should try cleaning your solution.
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.
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
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.
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.
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
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:
Manually delete bin folder and recompile
In case of publish, select delete existing files prior to publish.
This will solve the issue.
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;
Related
When I run a webapp from Visual Studio 2008 SP1 using the internal web server (not IIS) I receive the above mentioned error.
The full error (source file Default.aspx.cs):
Compiler Error Message: CS0433: The
type 'WebApplication3.Site1' exists in
both
'c:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary
ASP.NET
Files\root\aa563bcf\59deedc0\App_Web_site1.master.cdcab7d2.muczzy9v.dll'
and
'c:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary
ASP.NET
Files\root\aa563bcf\59deedc0\assembly\dl3\44c3a3cf\80dd34ed_6968ca01\WebApplication3.DLL'
The preceding full warning:
Warning: CS0436: The type
'WebApplication3._Default' in
'c:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary
ASP.NET
Files\root\aa563bcf\59deedc0\App_Web_default.aspx.cdcab7d2._tlkwdos.0.cs'
conflicts with the imported type
'WebApplication3._Default' in
'c:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary
ASP.NET
Files\root\aa563bcf\59deedc0\assembly\dl3\44c3a3cf\e096e61c_6568ca01\WebApplication3.DLL'.
Using the type defined in
'c:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary
ASP.NET
Files\root\aa563bcf\59deedc0\App_Web_default.aspx.cdcab7d2._tlkwdos.0.cs'.
Source of warning points to an intermediate file App_Web_default.aspx.cdcab7d2._tlkwdos.0.cs:
Line 162:
Line 163: [System.Runtime.CompilerServices.CompilerGlobalScopeAttribute()]
Line 164: public class default_aspx : global::WebApplication3._Default, System.Web.IHttpHandler {
Line 165:
Line 166: private static bool #__initialized;
and my question: where does this come from?
The webapp (not website!) has one Default.aspx and one Site1.Master, no dependencies. They're almost empty, with an asp:Label on the page. Previously, this webapp worked fine. When I remove any references in Default.aspx.cs to the master, all goes well. The master has some code only.
It's actually one of many little fire-and-forget test webapps, so I couldn't care less. But I hadn't seen this before and now I'm curious of what to do, other then copying code into a new project (cleaning solution doesn't help).
Note: I've read this post and some others, they don't apply.
Theory
When this issue is not caused by a bug in the application (e.g., duplicate class name):
This issue appears to present after a change is made to the application's project that results in a new build (e.g., code/reference/resource change). The issue appears to lie within the output of this new build: for various reasons Visual Studio is not replacing the entire contents of your application's obj/bin folders. This results in at least some of the contents of your application's bin folder being out of date.
When said issue occurs, clearing out the "Temporary ASP.NET Files" folder, alone, does not solve the problem. It cannot solve the problem, because the stale contents of your application's bin folder are copied back into the "Temporary ASP.NET Files" folder the next time your application is accessed, causing the issue to persist. The key is to remove all existing files and force Visual Studio to rebuild every object, so the next time your application is accessed the new bin files will be copied into the "Temporary ASP.NET Files" folder.
Solution
Close Visual Studio
Perform an iisreset
Delete all the folders and files within the "Temporary ASP.NET Files" folder (the path is referenced in the error message)
Delete the offending application's "obj" and "bin" folders
Restart Visual Studio and open the solution
Perform a "Clean Solution" followed by a "Rebuild Solution"
Explanation
Steps 1-2: remove resource locks from the folders/files we need to delete.
Steps 3-4: remove all of the old build files
Steps 5-6: create new versions of the build files
Shut down w3svc and delete everything from c:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\
added
on Windows 7
c:\Users\{username}\AppData\Local\Temp\Temporary ASP.NET Files\root\
on IIS servers (64 bit) this can also occur. Look for:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root
(replace v4.0.30319 by the framework version you're using if newer on your server)
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
Look at the Inherits tag of all your aspx pages and master pages. Chances are there are two partial classes that have the same name. Change one and recompile.
Here is some more info:
http://blogs.msdn.com/b/carloc/archive/2007/06/12/compiler-error-message-cs0433-in-asp-net-2-0.aspx
I still had the problem after all these suggestions. Some class inside App_Code was being compiled to two DLL's. Something like this (simplified):
warning CS0436: The type 'HcmDbGeographyModelBinder' in
'<user_profile_dir>\AppData\Local\Temp\Temporary ASP.NET Files\temp\3b1ed8ee\11405e8e\App_Code.oqr0kusq.0.cs'
conflicts with the imported type 'HcmDbGeographyModelBinder' in
'<user_profile_dir>\AppData\Local\Temp\Temporary ASP.NET Files\temp\3b1ed8ee\11405e8e\assembly\dl3\ea0aa3ee\6022e6d5_2cc8cf01\HCM.Web.Backoffice.DLL'.
I just renamed the "App_Code" folder to "Code". This is a MVC5 project, so there shouldn't be a problem with serving .cs files inside the web project's root.
Reference : https://support.microsoft.com/en-in/help/2028526/building-an-asp-net-project-in-visual-studio-results-in-compiler-error
When building an ASP.NET project using Visual Studio, you may randomly see an error message similar to the following:
Compiler Error Message: CS0433: The type 'ASP.summary_common_controls_notes_ascx' exists in both 'c:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files\Book_Details\abc12345\def8910\App_Web_msftx123.dll' and 'c:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files\Book_Details\abc12345\def8910\App_Web_msfty456.dll'
Description: An error occurred during the compilation of a resource required to service this request. Please review the following specific error details and modify your source code appropriately.
Source Error: Line 100: Line 101:
New Notes Line 102:
Line 103:
1450 Line 104:
Summary.
Source File: d:\http\post\publisher\default.aspx Line: 102
Common scenarios where this error can occur are discussed below
Scenario 1
Description: A common cause is when there are two assemblies in the same web application bin folder containing two class definitions but that have the same class name. This can happen if more than one Default.aspx was compiled into a single assembly. Commonly, this occurs when the Master page (Default.master) and the Default ASPX page (Default.aspx) both declare a _Default class.
Solution: Change the class name of the master page (from _Default in most cases) and rebuild the project. It is important to resolve any naming conflict between classes.
Scenario 2
Description: The Reference Paths in Visual Studio is used to specify the folder path for assembly references used by the project. It is possible that the path contains an assembly that contains the same class name. It may be that there are multiple References added to the same assembly (possibly different version or name) causing a naming conflict.
Solution: Remove the old version reference. To do so, in Visual Studio right-click your web site and check the "References" in the properties.
Scenario 3
Description: By default, when an ASP.NET Web application is compiled the compiled code is placed in the Temporary ASP.NET Files folder. By default the access permissions are given to the ASP.NET local user account, which has the high-trust permissions needed to access compiled code. It is possible that there were some changes in the default permissions causing versioning conflicts. Another possibility would be that anti-virus software could be locking an assembly inadvertently.
Solution: Clear the Temporary ASP.NET Files Folder of all contents.
Scenario 4
Description: When the batch attribute in the web.config is set to True it eliminates the delay caused by the compilation required when you access a file for the first time. ASP.NET precompiles all the un-compiled files in a batch mode, which causes delays the first time the files are compiled. Turning off batch compilation may expose masked compilation errors that may exist in the application but are not reported. However more importantly for this issue it tells ASP.NET to dynamically compile individual .aspx/.ascx files into separate assemblies instead of into a single assembly.
Solution: Set batch=false in the section in web.config. This should be considered a temporary solution as setting batch=false in the compilation section has a significant performance impact on build times for the application in Visual Studio.
Scenario 5
Description: Modifying the web.config file for an ASP.NET application or changing a file in the bin folder (such as adding, deleting, or renaming) causes the AppDomain to restart. When this occurs all session state is lost and cached items are removed from the cache as the website restarts. It is possible that the problem is caused by an inconsistent state in the web application.
Solution: Trigger an AppDomain restart by touching (editing) the web.config file.
Scenario 6
Description: You can store source code in the App_Code folder, and it will be automatically compiled at run time. The resulting assembly is accessible to any other code in the Web application. The App_Code folder therefore works much like the Bin folder, except that you can store source code in it instead of compiled code. The class will be recompiled when there is a change in the source file. If there is conflict due to an outdated assembly then forcing a recompile may resolve the problem.
Solution: Touch a file in the Bin or App_Code folders to trigger a full recompilation.
Removing the class files from the App_Code folder, and placing them directly under the website, solved this issue for me.
This may also happen if you have duplicate TagPrefix in your ASPX file.
This would cause this error...
<%# Register Src="Control1.ascx" TagName="Control1" TagPrefix="uc1" %>
<%# Register Src="Control2.ascx" TagName="Control2" TagPrefix="uc1" %>
You can fix this by simply changing the 2nd "uc1" to "uc2"
Fixed...
<%# Register Src="Control1.ascx" TagName="Control1" TagPrefix="uc1" %>
<%# Register Src="Control2.ascx" TagName="Control2" TagPrefix="uc2" %>
This happened to me because of an error in my Web.Config
<add assembly="System.Web.Abstractions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
<add assembly="System.Web.Helpers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
<add assembly="System.Web.Routing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
<add assembly="System.Web.Mvc, Version=5.1.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
<add assembly="System.Web.WebPages, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
The Sytem.Web.Helpers was pointed at 1.0.0.0 instead of 3.0.0.0 (MVC 3 is being used on this project).
Because IIS couldn't find the reference in the local folder it looked in the GAC and found two different versions. After pointing it at the correct reference IIS found the local dll and used that instead of searching the GAC.
This may happen when the same classname is specified in multiple .aspx.cs files, i.e.
when two pages are created with different file name but by mistake have the same classname.
// file a.aspx
public partial class Test1: System.Web.UI.Page
// file b.aspx
public partial class Test1: System.Web.UI.Page
While building the webapplication this gives a warning, but the application runs, however, after publishing the application doesn't work anymore and throws the exception as mentioned in the OP's question.
Making sure that two classnames do no overlap solves the issue.
I have found another reason: different versions used for icons in toolbox and references in the project. After inserting the objects in some form, the error started.
"Clean Solution" followed by "Rebuild Solution" seems to fix it as well.
To solve the ambiguity, you can define an alias for one of the reference elements.
In your target project file .csproj add the following item:
<ItemGroup>
<Reference Include="WebApplication3.Site1">
<Aliases>MyAssembly</Aliases>
</Reference>
</ItemGroup>
Then, you can use WebApplication3.Site1 as follow:
using MyAssembly;
I ended up changing how the MasterType is referenced in the page mark up.
I changed: <%# MasterType VirtualPath="~/x/y/MyMaster.Master" %>
to <%# MasterType TypeName="FullyQualifiedNamespace.MyMaster" %>
See here for details.
Hope this helps someone out.
For me at least, this happened when I removed a reference to an assembly and added a reference to a newer version of it, which had a different name. In this case, it seems that the old assembly remained in the bin and obj folder, and was not removed with the clean solution operation from Visual Studio (maybe because it is not part of the project anymore). In this case, it was enough to delete the contents of the bin and obj folders of the project where he error happens, from Windows Explorer (or a file management tool). Then, from Visual Studio, clean the solution and rebuild.
In our case, the reason was a difference in the .dll versions of to sites in IIS. They are placed under each other in IIS, letting you access the other thru a subdomain. It inherits from the first web.config, and combining that with the next web.config, it failed, having different versions of mvc.dll.
I had the similar problem.
This is my solution :
Put isolated classes which require property [Build Action] set as [Compile] to any folder other than App_Code like Application_Code since the App_Code folder will be compiled as a separate assembly, having the same Class compiled in 2 assemblies.
I had same issue with two ascx controls having same class name:
Control1: <%# Control Language="C#" ClassName="myClassName" AutoEventWireup="true ...>
Control2: <%# Control Language="C#" ClassName="myClassName" AutoEventWireup="true ...>
I fixed it by simply renaming the class name:
Control1: <%# Control Language="C#" ClassName="myClassName1" AutoEventWireup="true ...>
Control2: <%# Control Language="C#" ClassName="myClassName2" AutoEventWireup="true ...>
Close the Solution and re-open it, then check the projects references for doubling up:
This can happen if you were using NuGet and changed the DLLs reference location. To fix it you have to manually edit the proj file removing the entries, eg:
<Import Project="..\packages\CefSharp.WinForms.53.0.0\build\CefSharp.WinForms.targets" Condition="Exists('..\packages\CefSharp.WinForms.53.0.0\build\CefSharp.WinForms.targets')" />
Watch out as these "<Import" references can appear at different spots in the proj file.
A super quick and handy fix is to abuse Visual Studio's incredible intellisense by temporarily referencing the class somewhere.
Example:
System.Runtime.CompilerServices.ExtensionAttribute x = null;
When building or hovering the cursor over the line you can view the following error:
'System.Runtime.CompilerServices.ExtensionAttribute' exists in both
'C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.5\System.Core.dll'
This tells you the two sources causing the conflict immediately.
System.Core.dll is the .dll file that you want to keep, so delete the other one.
I found mine sitting in the bin directory, but it may be elsewhere in the project.
As a matter of fact this is worth bearing in mind, because since the bin directory might not be included as part of the TFS change-set, it can explain why checking in your changes doesn't resolve the issue for other members of your team.
I'm converting an old asp.net (v 1 or 2) web site to run under .net 4.5 as a web application.
My solution was to move the user control event handler delegates that were causing the problem to a separate physical file:
//move this line to a new physical file:
public delegate void LocationSearchedEventHandler( object sender );
public partial class controls_Drives_LocationAddPanel : UserControl
{
public event LocationAddedEventHandler LocationAdded;
protected virtual void OnLocationAdded(LocationAddEventArg e)
{
There are quite a multiple of reasons for this. And most of the ones mentioned above apply to different scenarios. What I noted is that the error occurs ONLY when authentication is set to something else other than 'None'. For my testing purposes I will set this off and it works.
I got re-directed here when clicking on the first Google hit when clicking on the error URL for CS0433, specifically,
The type 'Package' exists in both 'Windows... Version=N.N.N.N, Culture=neutral, PublicKeyToken=null, ContentType=Windows...' and 'Windows..., Version=255.255.255.255, Culture=neutral, PublicKeyToken=null, ContentType=Windows...'
Instead of outlining all the things I did to fix it, let me tell you what I did that broke it. I went to update the NuGet packages for a repo that needed a code update. The packages were pretty old (1 year or so) and all I initially tried to do was update it for a C# project.
Sometime between starting that process and encountering this error, I somehow downgraded the version of the C++ projects in that SLN to target 15063. I also noticed that the C# project had both the TargetPlatformMinVersion and TargetPlatformVersion newly set to 10.0.17134.0
The only thing I had to do to "fix" it was change the TargetPlatformMinVersion to a higher version than the TargetPlatformMinVersion for the C# project. Modifying the C++ project to either version didn't change behavior. I'm not sure why this suddenly stopped working but hopefully someone similarly blocked might get out of a pickle using similar strategies.
In addition to trying 2Toad's answer, I also ended up having to close Visual Studio and delete my .vs folder. After that, everything built correctly.
Incidentally, the error I was encountering didn't specify my Temp folder at all, but was referencing something else that was obviously system-generated. I neglected to save the specific error :\
if no other solution worked, then just rename the inherits class of that problem causing aspx file and aspx.cs file to a new name, then rebuild the solution. then the issue will be solved for sure. this only worked for me.
eg :
in the aspx file do the following change the inherits class name to Defaultnew
<%# Page Title="" Language="C#" MasterPageFile="~/Main.master" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="Defaultnew" %>
in the aspx.cs file rename the class to the same as used in aspx file
using System;
using System.Collections.Generic;
using System.Web;
public partial class Defaultnew : System.Web.UI.Page
{
Close Visual Studio and clear bin and obj folders in your project directory
After finishing the web application and publishing it online no matter I try I keep getting the following error, keep in mind that it runs locally as it should...
Parser Error Message: Could not load type 'webmarketing'.
I ran through that solution though supposedly I'm doing the same as the solution, yet I'm still facing the same issue...
ASP.NET Parser Error Cannot load code behind
Here is the code behind:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
namespace webmarketing
{
public partial class Masterpage : System.Web.UI.MasterPage
{
protected void Page_Load(object sender, EventArgs e)
{
string admin = (string)Session["Admin"];
if (string.IsNullOrEmpty(admin))
{
logout.Visible = false;
}
else
{
}
}
}
}
I had same problem before i just change CodeBehind to CodeFile and it worked.I remember it works in local but i had this problem after uploading.
This is normally happening when you copy files from a Web application projects to Website Project.
When you create a Web Application the Page directive is CodeBehind for the web pages.
If you create your application as Website then the Page directive is CodeFile
So if you copy from a Web application to Website the Namespace as well as the page directive will not change automatically, you should do this manually to rectify this error.
I had this error message. The problem was my .cs and aspx files were not added to the project. They were in the folder, but were not added. I solved it by adding them to the project (right click, Add). And then after I built the project, it was compiled into a dll in the bin folder. There was no need to change the text from CodeBehind to CodeFile.
what i did to solve my problem giving the same message was to go to IIS and check if it is configured as an Application or simply as a virtual directory. The App icon was just a folder icon. So i right clicked it and Manage Virtual directory > Advanced Settings > convert to Application changed the icon of virtual directory to a green earth icon. Of course the app was targeting framework 4.5, so changed App pool to 4.0 from default app pool, which was there earlier. This solved the issue for me.
But some things i did not say, 1. I am running it locally on IIS 6.1. 2. I am accessing with domain credential and not with 'pass through' authentication. Hope this helps
regarding the Inherits is should reflect the full name space with class name such as x.y.webmarketing, not the class name or the file name. to wrap it up it should look like below
<%# Master Language="C#" AutoEventWireup="true" CodeBehind="MasterPage.Master.cs" Inherits="Lync_Billing.ui.MasterPage" %>
If your application works in your local but fails when deployed to the server, then this issue is most likely related to your IIS settings.
To resolve this, Make sure the “Enable 32-Bit application” property of the target Application pool in IIS is set to “TRUE”.
It WORKS!
I think you find the problem is you need to update the files in the BIN folder.
When you run the app it recompiles the files in the BIN folder too. Copy those up to the WEB site and that should fix the problem, it did for me. This is especially true if you create a new page that was not already there which was my case.
In case you encounter this during debugging on your Visual Studio running on a 64-bit operating system, and your application is a 32-bit, set your configuration manager to x86 (32 bit). This agrees to the previous answer to the set IIS to enable 32-bit application on 64-bit.
If you are facing this error after Hosting your Website on server make sure that you create the directory And/Or go to Hosting server -> Site Manager -> Application Starting Point ,select the proper path or folder of your uploaded Published Folder.
It resolve my same problem , I hope it will help you also.
Using VS2015, I checked "Delete all existing files prior to publish" under File Publish Options within the "Publish Web" right-click menu option and this problem went away.
For me, I rebuild the individual projects and then rebuild the entire solution.
That worked for me somehow.
Simply building the solution may not work.
I think when you "Clean" the solutions that will fix the issue.
I'm using "Microsoft.CodeDom.Providers.DotNetCompilerPlatform" version 1.0.8. When rebuilding there was a warning about not being able to copy files into bin\roslyn. So I stopped IISExpress, deleted the bin folder and rebuild the project. There were no build warnings and the application worked fine.
Non of the mentioned answers worked for me.
My error was the same but I made the mistake and published the Debug version and not release, so make sure before Publishing your project, switch to Release, Clean and Rebuild the solution and the build!
Note: I was compiling my WebForms pages at build time.
I had aspx files not referenced in the project but were on disk and that was causing the build errors.
I am experiencing an error that I am unable to resolve for some time now. I was wondering if someone can help identify the cause of this error? I am completely new to asp / asax. After some research, I think that the error I am getting is due to the web application trying to use outdated code. I was thinking to rebuild the c# file using Visual Studio and/or the entire project. However, I am completely new to C# and asp, and was wondering can give me some suggestions if this may fix the problem and/or if there is an possible alternate solution.
Error message
Parser Error Message: Could not load type 'Inventory1.Global'.
Source Error: <%# Application Codebehind="Global.asax.cs" Inherits="Inventory1.Global" %>
Entire Global.asax contents:
<%# Application Codebehind="Global.asax.cs" Inherits="Inventory1.Global" %>
Try replacing CodeBehind with CodeFile
Could not load type
means that a type could not be loaded. (In this case, "type" refers to Inventory1.Global). Types are located in compiled DLLs. So, either the DLL isn't available, is out of date, or doesn't contain a public type with the given name.
Some possible causes are:
You have no type declared with the given name. For your example, you should have the following:
namespace Inventory1 {
public class Global {
...
}
}
Note: avoid names like Inventory1. They imply that there is an Inventory2, Inventory3, etc., which is bad practice as they're abmiguous and not very descriptive. Also, Global is pretty vague, and may introduce confusion with the global namespace.
Make sure your cases match (Inventory1, not INVENTORY1.)
You haven't compiled the project. In VS, rebuild the solution.
The assembly that declares the class has a compilation error, so the relevant DLL is either missing or out of date. Make sure you've resolved all errors.
The class is not marked as public.
If I had to guess, I'd put my money on a compilation error. Unlike PHP and other interpreted languages, C# have to be successfully compiled before they can be used.
I had this error , just needed to rebuild the project
I faced this issue and i got the solution from here and i would like to share it.
SOLUTION
Empty the bin folder. Build all the dependent class libraries and refer them in the main project and build the complete solution.
I did this and it worked like a charm for me !!
After scouring around for what could have caused this I found a few things that I needed to do to get my project running...
(Note: You may not need to do all of these - it is a case-by-case thing)
If you did any changes from IIS Express to Local IIS you may need to change the build configuration from bin/debug to bin. (Right click on solution >> Properties >> Build >> Output)
If you have a URL rewrite then you will need to install URL rewrite on your Local IIS.
Navigate to your applicationhosts.config file (usually it's some place like C:\Users\username\Documents\IISExpress\config) and rename the file to applicationhostsOLD.config.
Clean and rebuild your project. You may need to go manually empty out the bin.
Now you should be good to go.
Since it was only happening with IISexpress, changing output from bin\Debug\ to bin\ solved it for me. Changing tag CodeBehind to CodeFile only created even more problems.
This happened with me on my local machine. The issue was incorrect IISExpres config.
If you are getting this issue on your local environment (Visual Studio debug runs), check the IIS Express config file. Make sure your local site/application path is pointing to the correct location.
The configuration file is called applicationhost.config. It's stored here:
My Documents > IIS Express > config . Usually (not always) one of these paths will work:
%userprofile%\documents\iisexpress\config\applicationhost.config
%userprofile%\my documents\iisexpress\config\applicationhost.config
It can't find the necessary file in dll assembly.
Rebuild the project, Rebuild the solution and then try it again.
I added a new build profile and that defaulted to output of
/bin/[new profile name] and when i was running debugger it was trying to look to just /bin
It's likely that you renamed something. Check the Global.asax.cs file for the class declaration and make sure that the namespace and class name match exactly what's in the asax file. This includes case! Can you copy/paste the namespace and class declaration of the .cs file into a post here so that we can compare?
Parser Error Message: Could not load type __
After doing everything suggested in the comments above, with no luck, refreshing (uploading) the contents of /bin to the server worked. The files uploaded to bin are the: dll, pdb and xml. Don't know which one did it.
The problem I had here was induced by renaming a file (_.aspx) in Solution Explorer.
Rebuilding/re-publishing my project/solution to the server did nothing to help me, and I doubt that will help that many out of this predicament. For me, I did a few things to troubleshoot this that eventually got me out of this "hole".
I had been trying to use a binding on the web site, but this wasn't working. I tried calling the site with http://localhost/Report.aspx (this was my homepage, which I opted to not call Default.aspx - I was going to update the "Default Documents" section with the name later) when I got the Parser Error the OP saw. So I tried some things:
I stopped the old project's website and built another, simple web project, that had "hello" and a label on the page and nothing else. I had a line in the Page_Load to populate the label's Text property with "world!", just to make sure that part was working. I created a new website on port 80 and transferred the published contents of my site to the server. So even though I had .NET 4.5 installed on the server (and had ran the aspnet_regiis -i command from the 4.0 directory) and the App Pool in IIS that I was using for this new project was set to 4.0, the browser complained about the web.config having a targetFramework=4.5.2 in it, which is Visual Studio 2015's default framework. So I installed .NET 4.6 (NDP46-KB3045557-x86-x64-AllOS-ENU.exe), restarted the server, and then my simple site worked. So then I deleted this site - all I wanted to do was prove my installation steps were accurate and the server could run a site.
So then I went back to my original project/site - I deleted and re-created the web site. I put the Application Pool to the one I had originally created for this, which I ensured was running .NET 4.0. Once I did this, I navigated to my site and everything worked when using http://localhost/Report.aspx. So it seems to me what causes this is what version of the .NET Framework you are using.
I tried all the solutions listed above and none of them worked. I finally created a new web page (webform) and copy blocked all the code (cs and aspx files) into it from the old one, deleted the old cs and aspx file, recompiled, and now I'm back in business. I know it makes no sense. It should not have mattered, but it worked.
Please try to open your project as Project/Solution, most probably it will resolve the error. This type of error Could not load type.... occurs when we try to open project as website.
I have tried to open my project as solution and it resolved my problem.
Please check namespace and class name at all places, In one case, One team member changed namespace and I was using old namespace in .aspx file. It was causing issue. I updated namespace and it got working.
I was fixing my namespaces in our Base Project, and I started seeing this error on another project that references it after that. I had to remove the reference to the Base Project and re-add it and then it started working again.
I just got this error today. It turns out that it was because I reverted by mistake the project file to an older version that didn't include the page anymore.
I had the same issue after renaming an aspx page Visual studio renamed it but dropped the namespace. Make sure the Inherits property contains the fully Qualified name including the namespace.
If you just added the new aspx File, rebuild the project it is located in. The problem comes from your Code Behind file that isn't compiled at the moment, therefore you want to access a newer page that doesn't exist in your current compiled project dll
I had this problem on the remote server, but not on my local server. After trying everything and nothing working, I finally resolved it. My domain name was pointing to a directory under another domain. I had originally built the website independently in Visual Studio as its own project. No matter what I did, it wasn't working anymore. So I moved it to a folder inside of the project for the main domain name and uploaded it as part of the main project.
For example, I have say domain name AAA.com with a website of its own. And then I also have BBB.com that points to a directory under AAA.com's main directory. Originally I had separate VS projects for AAA.com and BBB.com, but that wasn't working anymore. So I had to move all of BBB.com's files to the AAA.com project and set it up exactly like it appears on the remote server. For some reason, that worked.
Try This It will Definitely work :-
Parse Error:
May be you Class name is not matched with the webform name
Several years before I started working at this job another developer who is no longer here wrote an application in classic ASP using HTML, vbscript and javascript. This is fine but the problem is that 2 pages were written in C# with an HTML file and a code behind file. There was no solution files for these two pages. They may have been originally created in Visual Studio but they don't exist in it now.
That is important because there is a lot of things that Visual Studio just does for you without even thinking.
My problem is that in these two C# pages I need to get them to reference a DLL. This is a simple task when using Visual Studio. You just add a reference to the project and life is good. But outside of VS nothing seems to work.
I tried putting the dll in the same folder as the pages and then I tried the following:
Using myDLL;
myDLL dll = new myDLL();
myDLL dll = myDLL();
I found some code online that said to create an internal static class and use [DLLImport()] but that didn't work either. It couldn't find the dll or the Entry Point for the dll. I am currently researching how to create an entry point, just in case this is the method to make everything work.
Outside of having to rewrite these pages in vbscript (which I don't have the time to do) I am at a loss.
Has anyone ran into this problem before? Is there something that I can put in the web.Config? Or is this just impossible and I am hosed.
BTW this is all running under the 2.0 .net framework.
If you drop the DLL you want the code to reference into the bin folder of the website, then open the web.config and locate the following section configuration -> system.web -> compilation -> assemblies.
You need to add the display name of the assembly to that list - so that the compiler will reference that assembly during it's late-bound build process.
Now you should be able to use the stuff that's in it on those pages.
If you don't the know the display name of the assembly (typically yourassembly, version=*.*.*.*, Culture=neutral, PublicKeyToken=null for culture-invariant, non-strong-named assemblies) you can open it in a tool like ILSpy (there are others, it's just become my favourite) and it tells you when you select it in it's UI:
sorry for the poor highlighting - jerky hand following far too much coffee
If all the code in that assembly is in a single namespace, also, you can also add a default using to all the .cs or .aspx code in the project by adding that namespace to configuration -> system.web -> pages -> namespaces - making it simpler to use that code in the pages.
I created a VS Solution/Project for my app. I compiled and published it to the web server. When I published it I had it copy all project files.
I ran it and it crashed because it could not find my dll.
I tried adding the lines that Andras mentioned above and it seemed like it was getting me closer but it only changed the errors I was getting.
Then I went into IIS on the web server. I expanded the folder listing under Web Site. I right clicked on the folder that contained my app and made that folder into an application folder.
After I did that everything just worked. So then I thought I would see what happened if I backed out all of the additional code I added to my C# app and the Web.Config file. It still worked. All I needed to do was to make the folder an application folder in IIS and put a Using statement in my C# app and life is wonderful again.
Thanks for all the comments and suggestion. Andras thanks for the link to ILSpy. That is a cool little tool.
Take care,
Robert
I agree with Jon, it sounds like you should try creating a new project for these files. It's always better to leave code better off than you found it. If a new project is not an option for some reason, you should indicate this in your question.
When I re/build my ASP.NET website I do not receive any errors.
However when I PUBLISH the site, it gives me a 'Circular file references are not allowed.' error.
I read a little on the web about this, and it provided a batch='false' option, which I tried and does nothing.
The page, has a master page, which may call on the same control twice; however, this control does not refer back to anything
TY - Theo
Theo, I also received this error quite a few times which is very annoying, even though I searched for ages for circular file references I couldn't find any. In the end I decided that although there are no definite circular file references, the compiler did not like it when I referenced a control in a parent folder e.g. I have a control in the folder /UserControls/Panels/ManagerPanels/ which references a control in the folder /UserControls/Panels/. This works ok when coding but trying to publish or debug brought about the Circular file reference problem. Sorry to say the only solution I found was to move the referencing control back a folder into the same folder as the control it was referencing, this fixed the problem (although it is extremely frustrating as I like a nice folder structure for my controls, of which there are many). Hope this helps
The reason that batch=false won't fix anything is publishing a website precompiles it so the batch attribute is irrelevant.
You can get more details on the error by using the aspnet_compiler command. I think this only works if you've hosted your website locally in IIS.
aspnet_compiler -v /
The above command would precompile your website locally if it's running on port 80 and show you where the problems are.
If you have Project A and Project B in the same solution, and you add a reference from Project A to Project B and also a reference from Project B to Project A then you’ll get this error. References work like a parent\child relationship so a project cannot be both the parent and the child of another project.
You’ll need to work out where the circular reference is and maybe move some code around, or even create a new project in order to resolve it.
if you add multiple project, one project depend another one project means check your reference. if u gave circular form means that error will come
There actually was a circular refernce in my case. As correctly highlighted by Doug Domeny, and Starjumper. My folder structures were:
UI > Templates > Header.ascx
Login.ascx
About.aspx
Inside Header.ascx we were using Login.ascx, the Header.ascx was then being used inside About.aspx and since for each folder there is a DLL, it became circular. I feel the error message could have been more elaborate.
To resolve, I created a copy of Login.ascx inside UI > Template folder and renamed it to Login1.ascx, and started using Login1.ascx inside Header.ascx