Проект веб-сайта строится в VS2008 SP1, но не в MSBUILD через CruiseControl.net

У меня есть проект веб-сайта, который я хочу создать с помощью CruiseControl.net.

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

  ASP.usercontrols_stars_ascx stars = (ASP.usercontrols_stars_ascx)e.Row.FindControl("stars");
  stars.StarCount = Convert.ToInt32(drv["rating"]);

Это нормально работает в VS2008, но ломается в MSBUILD со следующей ошибкой:

w:\CCNet\InflatableBoats\Working\IBWeb\UserControls\DisplayReviews.ascx.cs (49,):

errorCS0234: тип или имя пространства имен usercontrols_stars_ascx не существует в пространстве имен ASP (вам не хватает ссылки на сборку?)

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


asp.net msbuild namespaces controls
person John Hoge    schedule 03.09.2009    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Вы должны ссылаться на класс codebehind вместо сгенерированного ascx класса. Класс ascx наследует ваш класс программной части. Итак, определите свое свойство StarCount в коде программной части, укажите на него ссылку, и все будет в порядке.

person jrummell    schedule 03.09.2009

arrow_upward
0
arrow_downward

Очевидно, если вы ссылаетесь на сборку на вкладке «Обзор», которая указана на вкладке .NET диалогового окна «Добавить ссылку» (что не то же самое как GAC), который находится в том же месте установки, Visual Studio предполагает, что вы хотите использовать реестр для поиска файла. Я думаю, что он устанавливает для конкретной версии значение True, и это единственный способ заметить это в среде IDE. Это не позволяет кому-либо другому компилировать его, даже если у них одинаковые библиотеки DLL в одном месте, если только они не запустили установщик для этого пакета.

Однажды это укусило меня с помощью CruiseControl, когда я установил блок приложения Unity прямо в папку TFS, а затем добавил двоичные файлы в TFS. В файле .csproj не было записи HintPath для ссылки, поэтому сервер сборки не смог найти DLL.

В итоге я удалил блок с помощью «Установка и удаление программ», а затем снова получил двоичные файлы из TFS. Удаление и повторное добавление ссылок устранило проблему.

Это может не иметь отношения к вашей ситуации (сначала я бы попробовал предложение jrummell), но подумал, что упомянул бы об этом.

Visual Studio имеет тенденцию предполагать, что знает лучше, чем разработчик. Обычно это не так.

person TrueWill    schedule 03.09.2009