Lỗi CS0433 “Loại 'X' đã tồn tại trong cả A.dll và B.dll” đến từ đâu?

Khi tôi chạy ứng dụng web từ Visual Studio 2008 SP1 bằng máy chủ web nội bộ (không phải IIS), tôi nhận được lỗi đã đề cập ở trên.

Toàn bộ lỗi (tệp nguồn Default.aspx.cs ):

Thông báo lỗi trình biên dịch: CS0433: Loại 'WebApplication3.Site1' tồn tại trong cả 'c: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Temporary ASP.NET Files \ root \ aa563bcf \ 59deedc0 \ App_Web_site1.master.cdcab7d2. muczzy9v.dll 'và' c: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Tệp ASP.NET Tạm thời \ root \ aa563bcf \ 59deedc0 \ assembly \ dl3 \ 44c3a3cf \ 80dd34ed_6968ca01 \ WebApplication3.DLL '

Cảnh báo đầy đủ trước đó:

Cảnh báo: CS0436: Loại 'WebApplication3._Default' trong 'c: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Temporary ASP.NET Files \ root \ aa563bcf \ 59deedc0 \ App_Web_default.aspx.cdcab7d2._tlkwdos.0. cs 'xung đột với loại đã nhập' WebApplication3._Default 'trong' c: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Temporary ASP.NET Files \ root \ aa563bcf \ 59deedc0 \ assembly \ dl3 \ 44c3a3cf \ e096e61c_6568ca01 \ WebApplication3 .DLL '. Sử dụng kiểu được định nghĩa trong 'c: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Tệp ASP.NET Tạm thời \ root \ aa563bcf \ 59deedc0 \ App_Web_default.aspx.cdcab7d2._tlkwdos.0.cs'.

Nguồn cảnh báo trỏ đến tệp trung gian 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;

và câu hỏi của tôi: điều này đến từ đâu?

Ứng dụng web (không phải trang web!) Có một Default.aspx và một Site1.Master , không có phụ thuộc. Chúng gần như trống rỗng, với một asp:Labeltrang trên trang. Trước đây, ứng dụng web này hoạt động tốt. Khi tôi xóa bất kỳ tham chiếu nào trong Default.aspx.cs tới trang cái, mọi thứ đều diễn ra tốt đẹp. Chính chủ có một số mã chỉ.

Nó thực sự là một trong số rất nhiều ứng dụng web thử nghiệm dễ quên, vì vậy tôi không thể quan tâm hơn. Nhưng tôi chưa từng thấy điều này trước đây và bây giờ tôi tò mò không biết phải làm gì, ngoài việc sao chép mã vào một dự án mới (giải pháp làm sạch không giúp ích gì).

Lưu ý: Tôi đã đọc bài đăng này và một số bài khác, chúng không áp dụng.

Học thuyết

Khi sự cố này không phải do lỗi trong ứng dụng (ví dụ: trùng lặp tên lớp):

Vấn đề này xuất hiện sau khi một thay đổi được thực hiện đối với dự án của ứng dụng dẫn đến một bản dựng mới (ví dụ: thay đổi mã / tham chiếu / tài nguyên). Vấn đề dường như nằm trong đầu ra của bản dựng mới này: vì nhiều lý do khác nhau, Visual Studio không thay thế toàn bộ nội dung của các thư mục obj / bin của ứng dụng của bạn. Điều này dẫn đến ít nhất một số nội dung trong thư mục bin của ứng dụng của bạn bị lỗi thời.

Khi sự cố đã nói xảy ra, chỉ xóa thư mục "Tệp ASP.NET Tạm thời" không giải quyết được sự cố. Nó không thể giải quyết sự cố, vì nội dung cũ trong thư mục bin của ứng dụng của bạn được sao chép lại vào thư mục "Tệp ASP.NET Tạm thời" vào lần tiếp theo ứng dụng của bạn được truy cập, khiến sự cố vẫn tiếp diễn. Chìa khóa là xóa tất cả các tệp hiện có và buộc Visual Studio phải xây dựng lại mọi đối tượng, vì vậy, lần tiếp theo ứng dụng của bạn được truy cập, tệp bin mới sẽ được sao chép vào thư mục "Tệp ASP.NET Tạm thời".

Giải pháp

1. Đóng Visual Studio
2. Thực hiện iisreset
3. Xóa tất cả các thư mục và tệp trong thư mục "Tệp ASP.NET Tạm thời" (đường dẫn được tham chiếu trong thông báo lỗi)
4. Xóa thư mục "obj" và "bin" của ứng dụng vi phạm
5. Khởi động lại Visual Studio và mở giải pháp
6. Thực hiện "Giải pháp sạch" sau đó là "Giải pháp xây dựng lại"

Giải trình

• Bước 1-2: xóa khóa tài nguyên khỏi thư mục / tệp chúng ta cần xóa.
• Bước 3-4: Xóa tất cả các tệp bản dựng cũ
• Bước 5-6: Tạo phiên bản mới của tệp bản dựng

Tắt w3svc và xóa mọi thứ khỏi c:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\

thêm

• trên Windows 7

  c:\Users\{username}\AppData\Local\Temp\Temporary ASP.NET Files\root\

• trên máy chủ IIS (64 bit) điều này cũng có thể xảy ra. Tìm kiếm:

  C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root

  (thay thế v4.0.30319 bằng phiên bản khung bạn đang sử dụng nếu mới hơn trên máy chủ của bạn)

Điều này có thể xảy ra nếu bạn đặt tệp .cs trong App_Code và thay đổi hành động xây dựng của chúng để biên dịch trong Dự án ứng dụng web.

Có hành động xây dựng cho các tệp .cs trong App_Code dưới dạng Nội dung hoặc thay đổi tên của App_Code thành tên khác. Tôi đã đổi tên vì intellisense sẽ không sửa các tệp .cs được đánh dấu là nội dung.

Thông tin thêm tại http://vishaljoshi.blogspot.se/2009/07/appcode-folder-doesnt-work-with-web.html

Nhìn vào thẻ Kế thừa của tất cả các trang aspx và trang chính của bạn. Rất có thể có hai lớp từng phần có cùng tên. Thay đổi một và biên dịch lại.

Dưới đây là một số thông tin nhiều hơn nữa:

http://blogs.msdn.com/b/carloc/archive/2007/06/12/compiler-error-message-cs0433-in-asp-net-2-0.aspx

Tôi vẫn gặp vấn đề sau tất cả những đề xuất này. Một số lớp bên trong App_Code đã được biên dịch thành hai DLL. Một cái gì đó như thế này (đơn giản hóa):

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'.

Tôi vừa đổi tên thư mục "App_Code" thành "Code". Đây là một dự án MVC5, vì vậy sẽ không có vấn đề gì với việc cung cấp các tệp .cs bên trong thư mục gốc của dự án web.

Xóa các tệp lớp khỏi App_Codethư mục và đặt chúng trực tiếp dưới trang web, đã giải quyết được vấn đề này cho tôi.

Điều này cũng có thể xảy ra nếu bạn có TagPrefix trùng lặp trong tệp ASPX của mình.

Điều này sẽ gây ra lỗi này ...

<%@ Register Src="Control1.ascx" TagName="Control1" TagPrefix="uc1" %>

<%@ Register Src="Control2.ascx" TagName="Control2" TagPrefix="uc1" %>

Bạn có thể khắc phục điều này bằng cách chỉ cần thay đổi "uc1" thứ 2 thành "uc2"

Đã sửa...

<%@ Register Src="Control1.ascx" TagName="Control1" TagPrefix="uc1" %>

<%@ Register Src="Control2.ascx" TagName="Control2" TagPrefix="uc2" %>

Tham khảo: https://support.microsoft.com/en-in/help/2028526/building-an-asp-net-project-in-visual-studio-results-in-compiler-error

Khi xây dựng một dự án ASP.NET bằng Visual Studio, bạn có thể ngẫu nhiên thấy một thông báo lỗi tương tự như sau:

Thông báo lỗi trình biên dịch: CS0433: Loại 'ASP.summary_common_controls_notes_ascx' tồn tại trong cả 'c: \ Windows \ Microsoft.NET \ Framework64 \ v2.0.50727 \ Tệp ASP.NET Tạm thời \ Book_Details \ abc12345 \ def8910 \ App_Web_msftx123.dll' và ' c: \ Windows \ Microsoft.NET \ Framework64 \ v2.0.50727 \ Tệp ASP.NET Tạm thời \ Book_Details \ abc12345 \ def8910 \ App_Web_msfty456.dll '

Mô tả: Đã xảy ra lỗi trong quá trình biên dịch tài nguyên cần thiết để phục vụ yêu cầu này. Vui lòng xem lại chi tiết lỗi cụ thể sau đây và sửa đổi mã nguồn của bạn một cách thích hợp.

Lỗi nguồn: Dòng 100: Dòng 101:
Ghi chú mới Dòng 102:
Dòng 103:
1450 Dòng 104:

Tóm lược.

Tệp nguồn: d: \ http \ post \ publisher \ default.aspx Dòng: 102

Các tình huống phổ biến mà lỗi này có thể xảy ra được thảo luận bên dưới

cảnh 1

Mô tả: Nguyên nhân phổ biến là khi có hai tập hợp trong cùng một thư mục bin ứng dụng web chứa hai định nghĩa lớp nhưng có cùng tên lớp. Điều này có thể xảy ra nếu nhiều hơn một Default.aspx được biên dịch thành một hội đồng duy nhất. Thông thường, điều này xảy ra khi trang Chính (Default.master) và trang ASPX mặc định (Default.aspx) đều khai báo một lớp _Default. Giải pháp: Thay đổi tên lớp của trang chủ (từ _Default trong hầu hết các trường hợp) và xây dựng lại dự án. Điều quan trọng là phải giải quyết mọi xung đột đặt tên giữa các lớp.

Tình huống 2

Mô tả: Đường dẫn Tham chiếu trong Visual Studio được sử dụng để chỉ định đường dẫn thư mục cho các tham chiếu hợp ngữ được dự án sử dụng. Có thể đường dẫn chứa một hợp ngữ có cùng tên lớp. Có thể có nhiều Tham chiếu được thêm vào cùng một hội đồng (có thể là phiên bản hoặc tên khác nhau) gây ra xung đột đặt tên.
Giải pháp: Xóa tham chiếu phiên bản cũ. Để làm như vậy, trong Visual Studio nhấp chuột phải vào trang web của bạn và kiểm tra "Tham chiếu" trong thuộc tính.

Tình huống 3

Mô tả: Theo mặc định, khi một ứng dụng Web ASP.NET được biên dịch, mã đã biên dịch được đặt trong thư mục Tệp ASP.NET Tạm thời. Theo mặc định, các quyền truy cập được cấp cho tài khoản người dùng cục bộ ASP.NET, tài khoản này có các quyền có độ tin cậy cao cần thiết để truy cập mã đã biên dịch. Có thể có một số thay đổi trong các quyền mặc định gây ra xung đột lập phiên bản. Một khả năng khác là phần mềm chống vi-rút có thể vô tình khóa một tổ hợp. Giải pháp: Xóa tất cả nội dung trong Thư mục tệp ASP.NET Tạm thời.

Tình huống 4

Mô tả: Khi thuộc tính batch trong web.config được đặt thành True, nó sẽ loại bỏ sự chậm trễ do quá trình biên dịch bắt buộc khi bạn truy cập tệp lần đầu tiên. ASP.NET biên dịch trước tất cả các tệp chưa được biên dịch ở chế độ hàng loạt, điều này gây ra sự chậm trễ trong lần đầu tiên các tệp được biên dịch. Việc tắt biên dịch hàng loạt có thể làm lộ ra các lỗi biên dịch được che giấu có thể tồn tại trong ứng dụng nhưng không được báo cáo. Tuy nhiên, quan trọng hơn đối với vấn đề này, nó yêu cầu ASP.NET biên dịch động các tệp .aspx / .ascx riêng lẻ thành các tập hợp riêng biệt thay vì thành một tập hợp duy nhất. Giải pháp: Đặt batch = false trong phần trong web.config. Đây nên được coi là một giải pháp tạm thời vì việc đặt batch = false trong phần biên dịch có tác động đáng kể đến hiệu suất đối với thời gian xây dựng ứng dụng trong Visual Studio.

Tình huống 5

Mô tả: Việc sửa đổi tệp web.config cho ứng dụng ASP.NET hoặc thay đổi tệp trong thư mục bin (chẳng hạn như thêm, xóa hoặc đổi tên) khiến AppDomain khởi động lại. Khi điều này xảy ra, tất cả trạng thái phiên sẽ bị mất và các mục được lưu trong bộ nhớ cache sẽ bị xóa khỏi bộ nhớ cache khi trang web khởi động lại. Có thể sự cố là do trạng thái không nhất quán trong ứng dụng web. Giải pháp: Kích hoạt khởi động lại AppDomain bằng cách chạm vào (chỉnh sửa) tệp web.config.

Tình huống 6

Mô tả: Bạn có thể lưu trữ mã nguồn trong thư mục App_Code và nó sẽ được tự động biên dịch tại thời điểm chạy. Tập hợp kết quả có thể truy cập vào bất kỳ mã nào khác trong ứng dụng Web. Do đó, thư mục App_Code hoạt động giống như thư mục Bin, ngoại trừ việc bạn có thể lưu trữ mã nguồn trong đó thay vì mã đã biên dịch. Lớp sẽ được biên dịch lại khi có sự thay đổi trong tệp nguồn. Nếu có xung đột do lắp ráp lỗi thời thì việc buộc biên dịch lại có thể giải quyết được sự cố. Giải pháp: Chạm vào tệp trong thư mục Bin hoặc App_Code để kích hoạt biên dịch lại đầy đủ.

Điều này đã xảy ra với tôi do lỗi trong Web của tôi.

<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"/>

Đã Sytem.Web.Helpersđược chỉ vào 1.0.0.0 thay vì 3.0.0.0 (MVC 3 đang được sử dụng trong dự án này).

Vì IIS không thể tìm thấy tham chiếu trong thư mục cục bộ nên nó đã tìm trong GAC và tìm thấy hai phiên bản khác nhau. Sau khi trỏ nó vào đúng tham chiếu, IIS đã tìm thấy dll cục bộ và sử dụng nó thay vì tìm kiếm GAC.

Điều này có thể xảy ra khi cùng một tên lớp được chỉ định trong nhiều .aspx.cstệp, tức là khi hai trang được tạo với tên tệp khác nhau nhưng do nhầm lẫn có cùng tên lớp.

// file a.aspx
public partial class Test1: System.Web.UI.Page

// file b.aspx
public partial class Test1: System.Web.UI.Page

Trong khi xây dựng ứng dụng web, điều này đưa ra một cảnh báo, nhưng ứng dụng sẽ chạy, tuy nhiên, sau khi xuất bản ứng dụng không hoạt động nữa và ném ngoại lệ như đã đề cập trong câu hỏi của OP.

Đảm bảo rằng hai tên lớp không trùng lặp sẽ giải quyết được vấn đề.

Tôi đã tìm thấy một lý do khác: các phiên bản khác nhau được sử dụng cho các biểu tượng trong hộp công cụ và các tham chiếu trong dự án. Sau khi chèn các đối tượng trong một số biểu mẫu, lỗi bắt đầu.

"Giải pháp sạch" tiếp theo là "Giải pháp xây dựng lại" dường như cũng sửa được.

Tôi đã thay đổi cách MasterType được tham chiếu trong phần đánh dấu trang.

Tôi đã thay đổi: <%@ MasterType VirtualPath="~/x/y/MyMaster.Master" %> thành<%@ MasterType TypeName="FullyQualifiedNamespace.MyMaster" %>

Xem chi tiết tại đây .

Mong rằng nó giúp ai đó thoát.

Đối với tôi ít nhất, điều này đã xảy ra khi tôi xóa một tham chiếu đến một assembly và thêm một tham chiếu vào phiên bản mới hơn của nó, có tên khác. Trong trường hợp này, có vẻ như lắp ráp cũ vẫn nằm trong thư mục bin và obj và không bị xóa bằng thao tác giải pháp sạch từ Visual Studio (có thể vì nó không còn là một phần của dự án nữa). Trong trường hợp này, chỉ cần xóa nội dung của các thư mục bin và obj của dự án xảy ra lỗi, khỏi Windows Explorer (hoặc một công cụ quản lý tệp) là đủ. Sau đó, từ Visual Studio, làm sạch giải pháp và xây dựng lại.

Trong trường hợp của chúng tôi, lý do là sự khác biệt trong các phiên bản .dll của các trang web trong IIS. Chúng được đặt dưới nhau trong IIS, cho phép bạn truy cập miền kia thông qua miền phụ. Nó kế thừa từ web.config đầu tiên và kết hợp nó với web.config tiếp theo, nó không thành công, có các phiên bản khác nhau của mvc.dll.

Tôi đã gặp vấn đề tương tự. Đây là giải pháp của tôi: Đặt lớp cô lập mà đòi hỏi sở hữu [Build Action]bộ như [Compile]đối với bất kỳ thư mục khác hơn App_Codenhư Application_Codekể từ khi App_Codethư mục sẽ được biên soạn như một hội đồng riêng biệt, có lớp cùng biên soạn trong 2 cụm.

Tôi đã gặp vấn đề tương tự với hai điều khiển ascx có cùng tên lớp:

Control1: <% @ Control Language = "C #" ClassName = " myClassName " AutoEventWireup = "true ...> Control2: <% @ Control Language =" C # "ClassName =" myClassName "AutoEventWireup =" true ...>

Tôi đã sửa nó bằng cách đổi tên lớp:

Control1: <% @ Control Language = "C #" ClassName = " myClassName1 " AutoEventWireup = "true ...> Control2: <% @ Control Language =" C # "ClassName =" myClassName2 "AutoEventWireup =" true ...>

Đóng Giải pháp và mở lại, sau đó kiểm tra các tham chiếu dự án để nhân đôi :

Điều này có thể xảy ra nếu bạn đang sử dụng NuGet và thay đổi vị trí tham chiếu DLL. Để khắc phục, bạn phải chỉnh sửa thủ công tệp proj loại bỏ các mục nhập, ví dụ:

  <Import Project="..\packages\CefSharp.WinForms.53.0.0\build\CefSharp.WinForms.targets" Condition="Exists('..\packages\CefSharp.WinForms.53.0.0\build\CefSharp.WinForms.targets')" />

Hãy chú ý vì những tham chiếu "<Nhập" này có thể xuất hiện ở các vị trí khác nhau trong tệp proj.

Một cách khắc phục siêu nhanh và tiện dụng là lạm dụng intellisense đáng kinh ngạc của Visual Studio bằng cách tạm thời tham chiếu lớp ở đâu đó.

Thí dụ:

System.Runtime.CompilerServices.ExtensionAttribute x = null;

Khi xây dựng hoặc di con trỏ qua dòng, bạn có thể thấy lỗi sau:

'System.Runtime.CompilerServices.ExtensionAttribute' tồn tại trong cả 'C: \ Program Files \ Reference Assemblies \ Microsoft \ Framework \ v3.5 \ System.Core.dll'

Điều này cho bạn biết hai nguồn gây ra xung đột ngay lập tức.

System.Core.dll là tệp .dll mà bạn muốn giữ lại, vì vậy hãy xóa tệp còn lại.

Tôi tìm thấy của tôi đang ngồi trong binthư mục, nhưng nó có thể ở nơi khác trong dự án.

Trên thực tế, điều này đáng lưu ý vì binthư mục có thể không được đưa vào như một phần của tập thay đổi TFS, nó có thể giải thích tại sao việc kiểm tra các thay đổi của bạn không giải quyết được vấn đề cho các thành viên khác trong nhóm của bạn.

Tôi đang chuyển đổi một trang web asp.net (v 1 hoặc 2) cũ để chạy dưới .net 4.5 làm ứng dụng web.

Giải pháp của tôi là di chuyển các đại biểu của trình xử lý sự kiện kiểm soát người dùng đang gây ra sự cố sang một tệp vật lý riêng biệt:

//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)
    {

Có khá nhiều lý do cho điều này. Và hầu hết những điều được đề cập ở trên áp dụng cho các trường hợp khác nhau. Những gì tôi lưu ý là lỗi CHỈ xảy ra khi xác thực được đặt thành thứ khác ngoài 'Không có'. Đối với mục đích thử nghiệm của tôi, tôi sẽ thiết lập điều này và nó hoạt động.

Tôi được chuyển hướng lại tại đây khi nhấp vào lần truy cập Google đầu tiên khi nhấp vào URL lỗi CS0433, cụ thể là

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...'

Thay vì vạch ra tất cả những điều tôi đã làm để sửa chữa nó, hãy để tôi cho bạn biết tôi đã làm gì khiến nó bị hỏng. Tôi đã cập nhật các gói NuGet cho một kho cần cập nhật mã. Các gói đã khá cũ (1 năm hoặc lâu hơn) và tất cả những gì ban đầu tôi cố gắng làm là cập nhật nó cho một dự án C #.

Đôi khi giữa khi bắt đầu quá trình đó và gặp lỗi này, bằng cách nào đó, tôi đã hạ cấp phiên bản của các dự án C ++ trong SLN đó thành mục tiêu 15063. Tôi cũng nhận thấy rằng dự án C # có cả TargetPlatformMinVersionvà TargetPlatformVersionmới được đặt thành10.0.17134.0

Điều duy nhất tôi phải làm để "sửa chữa" nó là thay đổi TargetPlatformMinVersionphiên bản thành phiên bản cao hơn TargetPlatformMinVersioncho dự án C #. Việc sửa đổi dự án C ++ thành một trong hai phiên bản không thay đổi hành vi. Tôi không chắc tại sao điều này đột nhiên ngừng hoạt động nhưng hy vọng ai đó bị chặn tương tự có thể thoát khỏi tình trạng khó khăn bằng cách sử dụng các chiến lược tương tự.

Ngoài việc thử câu trả lời của 2Toad, tôi cũng đã phải đóng Visual Studio và xóa thư mục .vs của mình. Sau đó, mọi thứ được xây dựng chính xác.

Ngẫu nhiên, lỗi tôi gặp phải không chỉ định thư mục Temp của tôi, nhưng đang tham chiếu đến một thứ khác rõ ràng là do hệ thống tạo ra. Tôi đã sơ ý lưu lỗi cụ thể: \

nếu không có giải pháp nào khác hoạt động, thì chỉ cần đổi tên lớp kế thừa của sự cố đó gây ra tệp aspx và tệp aspx.cs thành tên mới, sau đó xây dựng lại giải pháp. thì chắc chắn vấn đề sẽ được giải quyết. điều này chỉ làm việc cho tôi.

ví dụ :

trong tệp aspx, hãy làm như sau thay đổi tên lớp kế thừa thành Defaultnew

<%@ Page Title="" Language="C#"  MasterPageFile="~/Main.master" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="Defaultnew" %>

trong tệp aspx.cs đổi tên lớp giống như được sử dụng trong tệp aspx

using System;
using System.Collections.Generic;
using System.Web;

public partial class Defaultnew : System.Web.UI.Page
{