То, почему делает сообщение BC30560 'mymodule_ascx', неоднозначно в пространстве имен 'ASP', подходивший, иногда тогда уходят?

Вместо того чтобы полагаться на права доступа к файлам операционной системы, используйте PowerMock для насмешки над FileUtils.getFile (...) и заставьте его возвращать экземпляр File (например, анонимный подкласс), который возвращает конкретное значение для canWrite () / canRead ().

Пересмешивание статических методов с помощью Mockito

11
задан alexmac 8 October 2008 в 07:55
поделиться

5 ответов

Другая возможность:

http://channel9.msdn.com/forums/TechOff/157050-BC30560-mycontrolascx-is-ambiguous-in-the-namespace-ASP/

Казалось, имел некоторый успех с изменением

src="mycontrol.ascx.cs"

кому:

CodeBehind="mycontrol.ascx.cs"
2
ответ дан 3 December 2019 в 01:16
поделиться

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

<%@ Page Inherits="_Default" %>

или возможно

<%@ Page ClassName="_Default" %>

Или что-то как этот. Я не на 100% уверен, которые приписывают его, был (это было некоторое время).

Но взгляд ищет что-то как _Default в Вашей директиве Page и заменяет их фактическими именами классов во всех Ваших файлах. По некоторым причинам ASP.NET не всегда интерпретирует _Default правильно, приводя к временным противоречивым ссылкам.

1
ответ дан 3 December 2019 в 01:16
поделиться

Подобный двум предыдущим ответам, у Вас по всей вероятности будут "копия и вставляемая" копия существующей страницы в том же сайте, и это будет затем содержать те же @Page директивы, которые приведут к столкновению функций (особенно, потому что все в значениях по умолчанию .NET к Частичным Классам.) Этот небольшой драгоценный камень укусил меня слишком часто.

Просто обновите "Наследовать" для указания на что-то характерное для страницы (т.е.: Ваше название страницы, снабженное префиксом подчеркиванием - поскольку это, как как правило, гарантируют, будет уникально), и гарантировал, чтобы у Вас не было двух Общедоступных Частичных Классов, названных тем же в другом коде - позади файлов (иначе Page_Load в _Default [default.aspx], столкнется с Page_Load в _Default [копия default.aspx]),

1
ответ дан 3 December 2019 в 01:16
поделиться

Я решил эту проблему с помощью следующей ссылки: http://www.netomatix.com/development/usercontrols2.aspx

В двух словах, ваш класс называется MyModule. Однако, если вы не укажете свойство ClassName в директиве @Control, компилятор может добавить _ascx к классу элемента управления, что приведет к MyModule_ascx. Поскольку страница не может найти MyModule_ascx, она взрывается вам прямо в лицо. Вам нужно явно указать ему ClassName ...

<%@ Control Language="vb" AutoEventWireup="false" CodeBehind="MyModule.ascx.vb" ClassName="MyModule" %>
14
ответ дан 3 December 2019 в 01:16
поделиться

Я только что пережил это. То, что работало нормально и оставалось нетронутым в течение нескольких месяцев, начало случайным образом выходить из строя после некоторых несвязанных обновлений. Я бы перекомпилировал, и проблема исчезла бы только для того, чтобы снова появиться в другом месте.

Кажется, я решил это, очистив временную папку ASP.NET, например C: \ Windows \ Microsoft.NET \ Framework \ v2.0.xxxxx \ Temporary ASP.NET Files. Это потребовало перезапуска IIS, чтобы действительно очистить его.

Обновление: Я попытался добавить tempDirectory = "e: \ someotherfolder" в элемент компиляции сети. config и, похоже, добился некоторого успеха. Также добавлено batch = "false" , но не уверен, подействовало ли это.

1
ответ дан 3 December 2019 в 01:16
поделиться
Другие вопросы по тегам:

Похожие вопросы: