RegAsm: метод «LoadContent» типа «MyAlgorithms.MyAlgorithm» из сборки «A» не имеет реализации - PullRequest
0 голосов
/ 05 января 2011

У меня есть следующие типы (см. Часть кода ниже). Он компилируется, но RegAsm выдает следующую ошибку: «Метод LoadContent типа MyAlgorithms.MyAlgorithm из сборки« A »не имеет реализации.»

Есть идеи почему? Если бы я не реализовал метод LoadContent (), он не был бы скомпилирован.

Я видел почти такой же вопрос, здесь: TypeLoadException говорит "нет реализации", но оно реализовано но это не помогло, потому что:

Проекты A, B и C находятся в одном решении, а порядок сборки - C, B и A.

«Командная строка события после сборки» всех проектов содержит следующие строки:

"C: \ WINDOWS \ Microsoft.NET \ Framework \ v2.0.50727 \ RegAsm.exe" / u $ (TargetPath)
"C: \ WINDOWS \ Microsoft.NET \ Framework \ v2.0.50727 \ RegAsm.exe" $ (TargetPath)
"c: \ Program Files \ Microsoft SDKs \ Windows \ v6.0A \ bin \ gacutil.exe" / u $ (TargetName)
"c: \ Program Files \ Microsoft SDKs \ Windows \ v6.0A \ bin \ gacutil.exe" / if $ (TargetPath)

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

И почему решается проблема, если я добавил в класс MyAlgorithmBase следующее:

защищенное переопределение void LoadContent (средство чтения PersistenceReader) {}

Спасибо!

KATE

// C.dll from project C
namespace Microsoft.SqlServer.DataMining.PluginAlgorithms
{
 public abstract class AlgorithmBase : IDisposable
 {
  //....
  protected abstract void LoadContent(PersistenceReader reader);
 }
}

//in B.dll from project B, refers C.dll
namespace AlgorithmCommons
{
 public abstract class MyAlgorithmBase : AlgorithmBase
 {
  //....
  // Why solves the problem if the next line is commented out?
  // protected override void LoadContent(PersistenceReader reader) { }
 }
}

//in A.dll from project A, refers B.dll and C.dll

namespace MyAlgorithms
{
 public class MyAlgorithm : MyAlgorithmBase
 {
  protected override void LoadContent(PersistenceReader reader)
  {
  //....
  }
 }
}

1 Ответ

0 голосов
/ 05 января 2011

Компилятор проверяет это. Это почти наверняка означает, что во время выполнения, когда Regasm.exe загружает сборку, он не загружает сборку, как вы думаете. Для этого есть много возможностей, так как вы используете GAC. Который может создать старую версию зависимой сборки на основе номера [AssemblyVersion] в ссылочной сборке.

Устраните неисправность с помощью Fuslogvw.exe, запишите все привязки. Он показывает вам, откуда пришла каждая сборка.

Держитесь подальше от подобных проблем, не помещая ваши сборки в GAC. Это подробности развертывания, которые не подходят для вашего компьютера разработчика, где версии сборок могут быстро меняться, особенно если вы позволяете системе сборки автоматически увеличивать их. Это можно сделать с помощью параметра / codebase для Regasm.exe

...