Откуда возникает ошибка CS0433 «Тип« X »уже существует как в A.dll, так и в B.dll»?

81

Когда я запускаю веб-приложение из Visual Studio 2008 SP1 с использованием внутреннего веб-сервера (не IIS), я получаю вышеупомянутую ошибку.

Полная ошибка (исходный файл Default.aspx.cs ):

Сообщение об ошибке компилятора: CS0433: тип «WebApplication3.Site1» существует в обоих «c: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Temporary ASP.NET Files \ root \ aa563bcf \ 59deedc0 \ App_Web_site1.master.cdcab7d2. muczzy9v.dll 'и' c: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Temporary ASP.NET Files \ root \ aa563bcf \ 59deedc0 \ assembly \ dl3 \ 44c3a3cf \ 80dd34ed_6968ca01 \ WebApplication3.DLL '

Предыдущее полное предупреждение:

Предупреждение: CS0436: тип 'WebApplication3._Default' в 'c: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Temporary ASP.NET Files \ root \ aa563bcf \ 59deedc0 \ App_Web_default.aspx.cdcab7d2._tlkwdos.0. cs 'конфликтует с импортированным типом' WebApplication3._Default 'в' c: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Temporary ASP.NET Files \ root \ aa563bcf \ 59deedc0 \ assembly \ dl3 \ 44c3a3cf \ e096e61c_6568ca01 \ WebApplication3 .DLL '. Используя тип, определенный в 'c: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Temporary ASP.NET Files \ root \ aa563bcf \ 59deedc0 \ App_Web_default.aspx.cdcab7d2._tlkwdos.0.cs'.

Источник предупреждения указывает на промежуточный файл 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;

и мой вопрос: откуда это взялось?

Веб-приложение (не веб-сайт!) Имеет один Default.aspx и один Site1.Master , никаких зависимостей. Они почти пустые, asp:Labelна странице есть. Раньше это веб-приложение работало нормально. Когда я удаляю любые ссылки в Default.aspx.cs на мастер, все идет хорошо. У мастера есть только код.

На самом деле это одно из многих небольших тестовых веб-приложений, которые можно запустить и забыть, так что мне все равно. Но я этого раньше не видел, и теперь мне интересно, что делать, кроме копирования кода в новый проект (чистящее средство не помогает).

Примечание: я прочитал этот пост и некоторые другие, они не применяются.

Авель
источник
PS: моя основная мысль: что-то испортило временный каталог, и мой главный выход здесь - просто удалить временный каталог вручную и восстановить. Еще не пробовал (удалил бы «доказательства»), на случай, если кто-то имеет более глубокое понимание здесь.
Abel

Ответы:

120

Теория

Если эта проблема не вызвана ошибкой в ​​приложении (например, повторяющимся именем класса):

Эта проблема возникает после того, как в проект приложения внесены изменения, которые приводят к новой сборке (например, изменение кода / ссылки / ресурса). Проблема, по-видимому, связана с выходными данными этой новой сборки: по разным причинам Visual Studio не заменяет все содержимое папок obj / bin вашего приложения. Это приводит к тому, что по крайней мере часть содержимого папки bin вашего приложения устаревает.

При возникновении указанной проблемы очистка папки «Временные файлы ASP.NET» сама по себе не решает проблему. Это не может решить проблему, потому что устаревшее содержимое папки bin вашего приложения копируется обратно в папку «Temporary ASP.NET Files» при следующем доступе к вашему приложению, в результате чего проблема сохраняется. Ключ состоит в том, чтобы удалить все существующие файлы и заставить Visual Studio перестроить каждый объект, чтобы при следующем доступе к вашему приложению новые файлы bin будут скопированы в папку «Временные файлы ASP.NET».

Решение

  1. Закройте Visual Studio
  2. Выполните iisreset
  3. Удалите все папки и файлы в папке «Временные файлы ASP.NET» (путь указан в сообщении об ошибке)
  4. Удалите папки "obj" и "bin" проблемного приложения.
  5. Перезапустите Visual Studio и откройте решение.
  6. Выполните «Чистое решение», а затем «Восстановите решение»

Объяснение

  • Шаги 1-2: снимите блокировку ресурсов с папок / файлов, которые нам нужно удалить.
  • Шаги 3-4: удалите все старые файлы сборки
  • Шаги 5-6: создайте новые версии файлов сборки
2Жаба
источник
3
Этот пост явно дополняет исходный принятый ответ. Хорошее объяснение и четкие шаги, спасибо!
Abel
1
@Abel, пожалуйста, подумайте над этим. Потому что только очистка временной папки ASP.NET не поможет!
Arin Ghazarian
2
Это случилось со мной с не веб-проектом. Это исправило простое удаление папок bin и obj.
Мэтт Х
1
@ArinGhazarian, именно так! Я должен был удалить objи binпапки , а также , чтобы очистить эту ошибку.
Сантош
Отличный ответ с отличным объяснением. Спасибо!
Карлос Родригес,
39

Выключите w3svc и удалите все из c:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\

добавлено

  • в Windows 7

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

  • на серверах IIS (64 бит) это также может произойти. Искать:

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

    (замените v4.0.30319 версией фреймворка, которую вы используете, если она новее на вашем сервере)

Алексей Полховский
источник
2
Да, это, вероятно, сработает (см. Мой собственный комментарий выше), но я надеялся получить немного больше информации о том, откуда это произошло и что делать, чтобы предотвратить это (или даже сделать его воспроизводимым). Я не против решения брутфорса, но перед этим мне нравится понимать, что происходит.
Abel
Такое случалось со мной в прошлом. Я считаю, что это проблема с VS, когда он не очищается после сеанса отладки или перед запуском нового. Последний раз это случилось со мной с VS2005 пару лет назад.
Alex Polkhovsky
3
Принял это как ответ, потому что это решение. Однако это не объясняет «почему». Если я найду лучшее решение или реальную причину, я обновлю ответ Лаймана или добавлю свой собственный.
Abel
На самом деле этот ответ мне не подходит. Мой проект работал хорошо пару недель назад, но я попробовал сегодня и показал вышеупомянутую проблему. Я удалил временные файлы, как указано выше (для Windows 7), и проблема не исчезла. Мне все еще интересно, почему ...
Venugopal M
@VenugopalM нашли ли вы какое-либо другое решение, решение выше не сработало для меня
Vbp
11

Это может произойти, если вы поместите файлы .cs в App_Code и измените их действие сборки на компиляцию в проекте веб-приложения.

Либо укажите действие сборки для файлов .cs в App_Code как Content, либо измените имя App_Code на другое. Я изменил имя, поскольку intellisense не исправляет файлы .cs, помеченные как содержимое.

Дополнительная информация на http://vishaljoshi.blogspot.se/2009/07/appcode-folder-doesnt-work-with-web.html

Лиля
источник
Ссылка, которую вы предоставили, была для меня решением. Я переместил все свои классы из папки App_Code и поместил их в новую папку с именем Classes. Затем переименовал пространства имен классов (конец namespace = .Classes вместо .App_Code). И, конечно же, обновите все операторы using и ссылки на папку App_Code.
krlzlx
Большое спасибо. Это
сводило
Это тоже исправило это для меня. Благодарю.
JonH
9

Посмотрите на тег Inherits всех ваших aspx-страниц и главных страниц. Скорее всего, есть два частичных класса с одинаковыми именами. Измените один и перекомпилируйте.

Вот еще немного информации:

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

NitroxDM
источник
Хорошая точка зрения. Код того дня был переписан, поэтому я не могу проверить, что это помогло бы, но для всех, у кого есть эта ошибка, это определенно может быть отличным указателем, спасибо за то, что поделился.
Авель
5

После всех этих предложений у меня все еще была проблема. Какой-то класс внутри App_Code компилировался в две библиотеки DLL. Примерно так (упрощенно):

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

Я просто переименовал папку «App_Code» в «Code». Это проект MVC5, поэтому проблем с обслуживанием файлов .cs внутри корня веб-проекта быть не должно.

tggm
источник
4

Удаление файлов классов из App_Codeпапки и размещение их непосредственно под веб-сайтом решило эту проблему для меня.

Naveen Q
источник
3
Боюсь, это не вариант. Размещение библиотек DLL непосредственно в корневом каталоге рассматривается многими как угроза безопасности (App_Code или bin являются специальными и недоступными через IIS / ASP.NET, в то время как любую DLL в корневом каталоге можно просто загрузить, а сборки .NET легко разобрать).
Abel
Я поместил класс в папку моделей в проекте ASP.NET MVC4, чтобы исправить это.
DShook
4

Это также может произойти, если у вас есть дубликат TagPrefix в вашем файле ASPX.

Это вызовет эту ошибку ...

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

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

Вы можете исправить это, просто изменив второй «uc1» на «uc2».

Исправлена...

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

<%@ Register Src="Control2.ascx" TagName="Control2" TagPrefix="uc2" %>
Джейсон Гейгер
источник
1
На самом деле это не проблема, префикс тега может быть одинаковым для всех элементов управления
Спайрос
@Spyros Я не согласен, потому что он решил проблему для меня. Прошло больше года, и я не могу вспомнить все по этому поводу, но было бы неплохо оставить это здесь, чтобы другие могли прочитать.
Джейсон Гейгер
Этот ответ решил мою проблему. Это было странно, потому что ошибка возникала не всегда, только после некоторых развертываний. Как и Спайрос, я не верил, что это решит проблему, я не видел связи. Спасибо Джейсону Гейгеру за публикацию.
VFein
Для чего это стоит. Все элементы управления, вызывающие это, находились в одной папке, на которую ссылались несколько виртуальных приложений как на виртуальный каталог.
VFein
Поцарапайте мой комментарий. Ошибка просто снова показала свою уродливую голову. Вернуться к доске для рисования.
VFein
4

Справка : https://support.microsoft.com/en-in/help/2028526/building-an-asp-net-project-in-visual-studio-results-in-compiler-error

При создании проекта ASP.NET с помощью Visual Studio вы можете случайно увидеть сообщение об ошибке, подобное приведенному ниже:

Сообщение об ошибке компилятора: CS0433: тип 'ASP.summary_common_controls_notes_ascx' существует как в 'c: \ Windows \ Microsoft.NET \ Framework64 \ v2.0.50727 \ Temporary ASP.NET Files \ Book_Details \ abc12345 \ def8910 \ App_Web_msftx123.dll' и ' c: \ Windows \ Microsoft.NET \ Framework64 \ v2.0.50727 \ Temporary ASP.NET Files \ Book_Details \ abc12345 \ def8910 \ App_Web_msfty456.dll '

Описание: произошла ошибка во время компиляции ресурса, необходимого для обслуживания этого запроса. Просмотрите следующие сведения об ошибках и соответствующим образом измените исходный код.

Ошибка источника: Строка 100: Строка 101:
Новые заметки Строка 102:
Строка 103:
1450 Строка 104:

Резюме.

Исходный файл: d: \ http \ post \ publisher \ default.aspx Строка: 102

Ниже описаны распространенные сценарии, в которых может возникнуть эта ошибка.

Сценарий 1

Описание. Распространенная причина - наличие двух сборок в одной и той же папке bin веб-приложения, содержащих два определения классов, но имеющих одно и то же имя класса. Это может произойти, если в одну сборку скомпилировано несколько файлов Default.aspx. Обычно это происходит, когда главная страница (Default.master) и страница ASPX по умолчанию (Default.aspx) объявляют класс _Default. Решение: измените имя класса главной страницы (в большинстве случаев с _Default) и перестройте проект. Важно разрешить любой конфликт имен между классами.

Сценарий 2

Описание: Пути ссылок в Visual Studio используются для указания пути к папке для ссылок на сборки, используемых в проекте. Возможно, путь содержит сборку, содержащую то же имя класса. Может случиться так, что в одну сборку добавлено несколько ссылок (возможно, с другой версией или именем), что вызывает конфликт имен.
Решение: удалите ссылку на старую версию. Для этого в Visual Studio щелкните правой кнопкой мыши свой веб-сайт и установите флажок «Ссылки» в свойствах.

Сценарий 3

Описание: по умолчанию, когда веб-приложение ASP.NET компилируется, скомпилированный код помещается в папку временных файлов ASP.NET. По умолчанию разрешения на доступ предоставляются локальной учетной записи пользователя ASP.NET, которая имеет разрешения с высоким уровнем доверия, необходимые для доступа к скомпилированному коду. Возможно, что в разрешениях по умолчанию были внесены некоторые изменения, вызывающие конфликты управления версиями. Другая возможность заключается в том, что антивирусное программное обеспечение может случайно заблокировать сборку. Решение: очистите временную папку файлов ASP.NET от всего содержимого.

Сценарий 4

Описание: Когда для атрибута пакета в web.config установлено значение True, это устраняет задержку, вызванную компиляцией, необходимой при первом доступе к файлу. ASP.NET предварительно компилирует все нескомпилированные файлы в пакетном режиме, что вызывает задержки при первой компиляции файлов. Отключение пакетной компиляции может выявить замаскированные ошибки компиляции, которые могут существовать в приложении, но не сообщаются. Однако, что более важно для этой проблемы, он сообщает ASP.NET динамически компилировать отдельные файлы .aspx / .ascx в отдельные сборки, а не в одну. Решение: Установите batch = false в разделе web.config. Это следует рассматривать как временное решение, так как установка batch = false в разделе компиляции оказывает значительное влияние на производительность на время сборки приложения в Visual Studio.

Сценарий 5

Описание. Изменение файла web.config для приложения ASP.NET или изменение файла в папке bin (например, добавление, удаление или переименование) вызывает перезапуск домена AppDomain. Когда это происходит, все состояние сеанса теряется, а кэшированные элементы удаляются из кеша при перезапуске веб-сайта. Возможно, проблема вызвана несогласованным состоянием веб-приложения. Решение. Запустите перезапуск домена приложения, коснувшись (отредактировав) файла web.config.

Сценарий 6

Описание: вы можете хранить исходный код в папке App_Code, и он будет автоматически компилироваться во время выполнения. Полученная сборка доступна любому другому коду в веб-приложении. Таким образом, папка App_Code работает так же, как папка Bin, за исключением того, что вы можете хранить в ней исходный код вместо скомпилированного кода. Класс будет перекомпилирован при изменении исходного файла. Если возникает конфликт из-за устаревшей сборки, принудительная перекомпиляция может решить проблему. Решение: коснитесь файла в папках Bin или App_Code, чтобы запустить полную перекомпиляцию.

Сандип Кумар Нарваре
источник
Как правило, я начинаю с попытки найти самые простые из предлагаемых решений. Следующее из приведенного выше сценария 6 решило проблему для меня: «Решение: коснитесь файла в папках Bin или App_Code, чтобы запустить полную перекомпиляцию».
cjo30080
2

Это случилось со мной из-за ошибки в моем 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"/>

Sytem.Web.HelpersБыл направлен на 1.0.0.0 вместо 3.0.0.0 (MVC 3 используется в этом проекте).

Поскольку IIS не смог найти ссылку в локальной папке, он посмотрел в GAC и нашел две разные версии. Указав правильную ссылку, IIS нашел локальную dll и использовал ее вместо поиска в GAC.

млапалия
источник
2

Это может произойти, когда одно и то же имя класса указано в нескольких .aspx.csфайлах, т.е. когда две страницы создаются с разными именами файлов, но по ошибке имеют одно и то же имя класса.

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

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

При создании веб-приложения это дает предупреждение, но приложение запускается, однако после публикации приложение больше не работает и выдает исключение, как указано в вопросе OP.

Убедившись, что два имени класса не пересекаются, решает проблему.

Дипак
источник
Tx за изучение этого. Но в случае вашего примера вы используете partial class, что на самом деле является обычным способом (единственным способом) разделить один класс на несколько файлов, и в этом случае вы должны использовать то же имя.
Abel
В конечном итоге это было близко к моей проблеме на веб-сайте (не в приложении). Очистка папок Temp, перемещение вещей из App_Code и другие предложения не сработали. Только когда я взглянул на файл .cs кода программной части для моей мастер-страницы, я заметил, что имя файла не соответствует имени класса, которое все еще оставалось по умолчанию MasterPage. Как только я переименовал класс в контекстном меню (чтобы все ссылки также обновились), ошибка наконец исчезла. Я могу только догадываться, что моя главная страница противоречила System.Web.UI.MasterPageклассу.
Andrew S
2

Я нашел другую причину: разные версии, используемые для значков в панели инструментов и ссылок в проекте. После вставки объектов в какую-то форму началась ошибка.

Рожерио Сильва
источник
1

«Чистое решение», за которым следует «Восстановить решение», похоже, тоже исправляет.

Роман
источник
Как я объяснил в вопросе, по крайней мере, в моей ситуации очистка раствора не помогла. Причина, по которой это не помогает, заключается в том, что ошибка вызвана временными файлами ASP.NET (как описано в 1-м и 2-м ответах), которые не очищаются при выполнении «чистого решения».
Abel
0

Я закончил тем, что изменил способ ссылки на MasterType в разметке страницы.

Я изменил: <%@ MasterType VirtualPath="~/x/y/MyMaster.Master" %> на<%@ MasterType TypeName="FullyQualifiedNamespace.MyMaster" %>

Смотрите здесь .

Надеюсь, это кому-то поможет.

Крис
источник
0

По крайней мере, для меня это произошло, когда я удалил ссылку на сборку и добавил ссылку на ее более новую версию, у которой было другое имя. В этом случае кажется, что старая сборка осталась в папке bin и obj и не была удалена с помощью операции чистого решения из Visual Studio (возможно, потому, что она больше не является частью проекта). В этом случае достаточно было удалить содержимое папок bin и obj проекта, в котором произошла ошибка, из проводника Windows (или инструмента управления файлами). Затем из Visual Studio очистите решение и перестройте его.

Гильермо Гутьеррес
источник
0

В нашем случае причина заключалась в различии между версиями .dll и сайтами в IIS. Они размещаются друг под другом в IIS, что позволяет вам получить доступ к другому через поддомен. Он унаследован от первого web.config, и, объединив его со следующим web.config, он потерпел неудачу, имея разные версии mvc.dll.

Кристиан Хааланд
источник
0

У меня была аналогичная проблема. Это мое решение: поместите изолированные классы, для которых требуется [Build Action]набор свойств, как [Compile]для любой папки, кроме App_Codeкак, Application_Codeпоскольку App_Codeпапка будет скомпилирована как отдельная сборка, имеющая один и тот же класс, скомпилированный в 2 сборки.

Али Махмуди
источник
0

У меня была такая же проблема с двумя элементами управления ascx с одинаковым именем класса:

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

Я исправил это, просто переименовав имя класса:

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

куналбабре
источник
0

Закройте Решение и снова откройте его, затем проверьте ссылки на проекты на предмет дублирования :

введите описание изображения здесь

Это может произойти, если вы использовали NuGet и изменили расположение ссылок на библиотеки DLL. Чтобы исправить это, вам нужно вручную отредактировать файл proj, удалив записи, например:

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

Обратите внимание, эти ссылки «<Импорт» могут появляться в разных местах файла proj.

Джереми Томпсон
источник
0

Очень быстрое и удобное решение - злоупотребить невероятным intellisense Visual Studio, временно сославшись на какой-нибудь класс.

Пример:

System.Runtime.CompilerServices.ExtensionAttribute x = null;

При построении или наведении курсора на строку вы можете увидеть следующую ошибку:

'System.Runtime.CompilerServices.ExtensionAttribute' существует как в 'C: \ Program Files \ Reference Assemblies \ Microsoft \ Framework \ v3.5 \ System.Core.dll'

Это сразу скажет вам о двух источниках, вызывающих конфликт.

System.Core.dll - это файл .dll, который вы хотите сохранить, поэтому удалите другой.

Я нашел свой в binкаталоге, но он может быть где-то еще в проекте.

На самом деле об этом стоит помнить, потому что, поскольку binкаталог может не входить в состав набора изменений TFS, это может объяснить, почему проверка ваших изменений не решает проблему для других членов вашей команды.

WonderWorker
источник
0

Я конвертирую старый веб-сайт asp.net (v 1 или 2) для работы под .net 4.5 в качестве веб-приложения.

Мое решение состояло в том, чтобы переместить делегатов обработчика событий пользовательского элемента управления, которые вызывали проблему, в отдельный физический файл:

//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)
    {
marcel_g
источник
0

Для этого есть множество причин. И большинство из упомянутых выше применимы к разным сценариям. Я заметил, что ошибка возникает ТОЛЬКО, когда для аутентификации установлено иное значение, кроме «Нет». Для целей тестирования я отключу это, и он работает.

Chagbert
источник
0

Меня перенаправили сюда при нажатии на первое обращение Google при нажатии на URL-адрес ошибки CS0433, в частности,

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

Вместо того, чтобы описывать все, что я сделал, чтобы исправить это, позвольте мне рассказать вам, что я сделал, что сломало его. Я пошел обновить пакеты NuGet для репозитория, который нуждался в обновлении кода. Пакеты были довольно старыми (1 год или около того), и все, что я изначально пытался сделать, это обновить их для проекта C #.

В какой-то момент между запуском этого процесса и появлением этой ошибки я каким-то образом понизил версию проектов C ++ в этом SLN до целевой 15063. Я также заметил, что в проекте C # оба параметра TargetPlatformMinVersionи TargetPlatformVersionнедавно были установлены на10.0.17134.0

Единственное, что мне нужно было сделать, чтобы «исправить» это, - это изменить TargetPlatformMinVersionверсию на более высокую, чем TargetPlatformMinVersionдля проекта C #. Изменение проекта C ++ на любую версию не изменило поведения. Я не уверен, почему это внезапно перестало работать, но, надеюсь, кто-то так же заблокированный может выйти из рассола, используя аналогичные стратегии.

kayleeFrye_onDeck
источник
0

Помимо попытки ответить 2Toad, мне также пришлось закрыть Visual Studio и удалить мою папку .vs. После этого все построилось правильно.

Между прочим, ошибка, с которой я столкнулся, вообще не указывала мою папку Temp, а ссылалась на что-то еще, что явно было сгенерировано системой. Я не позаботился о сохранении конкретной ошибки: \

Нейт
источник
0

если никакое другое решение не помогло, просто переименуйте наследующий класс этой проблемы, вызывая файл aspx и файл aspx.cs, на новое имя, а затем перестройте решение. тогда вопрос обязательно будет решен. это сработало только для меня.

например:

в файле aspx сделайте следующее: измените имя наследуемого класса на Defaultnew

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

в файле aspx.cs переименуйте класс в тот же, что и в файле aspx

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

public partial class Defaultnew : System.Web.UI.Page
{
anandd360
источник