Блог

Главная - Вопросы по программированию - Перегруженные методы расширения работают локально, но не на сервере сборки

Перегруженные методы расширения работают локально, но не на сервере сборки

#c#

#c#

Вопрос:

В моем проекте есть следующие методы расширения:

 public static void AddToDataTable<T>(this T instance, DataTable table) where T : IDatabaseObject
{
   DataRow row = table.NewRow();
   instance.PopulateRow(row);
   table.Rows.Add(row);
   //return row;
}

public static void AddToDataTable<T>(this ICollection<T> instances, DataTable table) where T : IDatabaseObject
{
   foreach (var instance in instances)
      instance.AddToDataTable(table);
}

Затем я вызываю эти функции в разных местах следующим образом:

 // Article is just a single item
articlePublishingInfo.Article.AddToDataTable(articleTable);

А также вот так:

 List<ArticlePagesDBO> articlePages = BuildAdditionalPageRelations(pagePublishing, articlePageInfo, pageData);
articlePages.AddToDataTable(dt);

Все это отлично работает при локальной компиляции, но сервер сборки выдает ошибку компиляции со словами

Тип ‘System.Коллекции.Generic.ListDataObjects.CM.ArticlePagesDBO>’ не может использоваться в качестве параметра типа ‘T’ в общем типе или методе ‘DatabaseObjectExtensions.AddToDataTable(T, DataTable)’. Нет неявного преобразования ссылок из ‘System.Коллекции.Generic.ListDataObjects.CM.ArticlePagesDBO>’ to ‘Vitec.Core.Web.Utilities.Data.IDatabaseObject’.

И это похоже.. да, это кажется правильным, a List<T> — это не то же самое, что T . Но почему сервер сборки не находит перегруженную версию метода расширения? Есть идеи? Метод расширения определен в двоичном файле, отличном от того, где находятся вызовы, и пространства имен обоих типов в сообщении об ошибке указаны правильно.

Если я переименую второй метод во что-то другое, например AddAllToDataTable , тогда это сработает. Но я как бы хочу знать, почему происходит сбой при перегрузке и что может быть причиной этого. Первоначально сервер сборки создавал проект с использованием VS2015, но изменение его на то же, что и в моей локальной среде, VS2019 не помогло.

Комментарии:

1. Probalby IDatabaseObject определен в другом двоичном файле, и они конфликтуют.

2. Другого интерфейса с таким именем нет ни в одном другом проекте в решении, ни в какой-либо из зависимостей, по крайней мере, в тех, которые мы разрабатываем.

3. Ваш метод определен в другом двоичном коде. Вот и все. Контрольная сумма, которую вы запускаете локально, и удаленный, бьюсь об заклад, вы получите разные хэши.

4. Как мне это сделать во время компиляции, поскольку это ошибка компиляции?

5. Возьмите двоичный файл, физическую * dll и вычислите его контрольную сумму. Тот, который вы получили локально, вероятно, даст хэш, отличный от того, который вы получите в удаленном двоичном файле, который заканчивается исключением.

Ответ №1:

Я вернулся к журналам и понял, что, хотя задание сборки на сервере было настроено на запуск Visual Studio 2019, на самом деле оно не было установлено на сервере, и сборка вернулась к Visual Studio 2015 с предупреждением.

После установки VS2019 на сервере сборка завершается, поэтому я предполагаю, что это была проблема с версией C #, возможно, перегрузка методов расширения в том виде, в котором я это делал, была несовместима с VS2015.