TypeLoadException не заявляет 'реализации', но он реализован
Действительно, самый простой метод - это сочетание двух других ответов, опубликованных здесь. Использование фильтра в фильтре для получения конверсии и отображения названия месяца в текущем языковом наборе:
app.filter('monthname',['$filter',function($filter){
return function(month) {
return $filter("date")(new Date(0,month),'MMMM');
}
}]);
Теперь вы можете использовать этот способ {{ 3 | monthname }}
Обратите внимание, что без этого исходный фильтр {{ 3 | date:'MMMM' }} не будет работать, так как в качестве аргумента ожидается тип Date, а не число.
8 ответов
Я бы порекомендовал эту книгу: .NET: Архитектура приложений для предприятий
Не книга по .net, а классическая книга. Метод SetShort недавно был добавлен как в интерфейс, так и в DummyItem, но сборка, содержащая DummyItem, была перестроена со ссылкой на предыдущую версию сборки интерфейса. Таким образом, метод SetShort фактически присутствует, но без волшебного соуса, связывающего его с эквивалентным методом в интерфейсе.
Длинный ответ
Если вы хотите попробовать воспроизвести это, попробуйте следующее:
Создайте библиотеку классов project: InterfaceDef, добавьте только один класс и создайте:
открытый интерфейс IInterface { строка GetString (строковый ключ); // короткий GetShort (строковый ключ); }Создайте проект библиотеки второго класса: реализация (с отдельным решением), скопируйте InterfaceDef.dll в каталог проекта и добавьте в качестве ссылки на файл, добавьте только один класс и создайте:
открытый класс ImplementingClass: IInterface { #region IInterface Members публичная строка GetString (строковый ключ) { вернуть «привет, мир»; } // общедоступный короткий GetShort (строковый ключ) // { // возврат 1; //} #endregion }Создайте третий консольный проект: ClientCode, скопируйте две библиотеки DLL в каталог проекта, добавьте ссылки на файлы и добавьте следующий код в метод Main:
IInterface test = new ImplementingClass (); строка s = test.GetString ("dummykey"); Console.WriteLine (s); Console.ReadKey ();Выполните код один раз, консоль выдаст «привет, мир!»
Раскомментируйте код в двух проектах DLL и перестройте - скопируйте две библиотеки DLL обратно в проект ClientCode, перестройте и попробуйте запустить снова. TypeLoadException возникает при попытке создать экземпляр класса ImplementingClass.
В дополнение к тому, что уже было сказано в собственном ответе спрашивающего, возможно, стоит отметить следующее. Причина этого в том, что класс может иметь метод с той же сигнатурой, что и метод интерфейса, без реализации этого метода. Следующий код иллюстрирует это:
public interface IFoo
{
void DoFoo();
}
public class Foo : IFoo
{
public void DoFoo() { Console.WriteLine("This is _not_ the interface method."); }
void IFoo.DoFoo() { Console.WriteLine("This _is_ the interface method."); }
}
Foo foo = new Foo();
foo.DoFoo(); // This calls the non-interface method
IFoo foo2 = foo;
foo2.DoFoo(); // This calls the interface method
Я получил это в службе WCF из-за того, что был выбран тип сборки x86, в результате чего корзины располагались в bin \ x86 вместо bin. Выбор «Любой процессор» привел к тому, что перекомпилированные библиотеки DLL переместились в правильные места (я не буду вдаваться в подробности того, как это вообще произошло).
Я получил это, когда в моем приложении не было ссылки на другую сборку, определяющую класс, который использовал метод в сообщении об ошибке. Запуск PEVerify дал более полезную ошибку: «Система не может найти указанный файл».
Другой раз, когда вы можете получить эту ошибку, если у вас неправильная версия подписанной сборки. Это не обычный симптом для этой причины, но вот сценарий, в котором я его получил
проект asp.net содержит сборку A и сборку B, B имеет строгое имя
сборка A использует Activator.CreateInstance для загрузки сборки C. (т.е. нет ссылки на C, который создается отдельно)
C был построен со ссылкой на более старую версию сборки B, чем сейчас
надеюсь, что это поможет кому-то - мне потребовалось время, чтобы понять это.
FWIW, я получил это, когда был файл конфигурации, который перенаправлял на несуществующую версию указанной сборки. Журналы Fusion для победы!
Я столкнулся с тем же сообщением, и вот что мы нашли: Мы используем в нашем проекте сторонние dll. После выхода нового релиза мы изменили наш проект, чтобы он указывал на новый набор dll, и компиляция прошла успешно.
Исключение возникло, когда я попытался установить один из их взаимосвязанных классов во время выполнения. Мы убедились, что все остальные ссылки были обновлены, но все равно ничего не получилось. Нам потребовалось некоторое время, чтобы обнаружить (с помощью Object Browser), что возвращаемый тип метода в сообщении об ошибке был совершенно новым типом из новой сборки без ссылок.
Мы добавили ссылку на сборку, и ошибка исчезла.
- Сообщение об ошибке было довольно вводящим в заблуждение, но указывало более или менее правильное направление (правильный метод, неправильное сообщение).
- Исключение возникло, даже если мы не использовали метод, о котором идет речь.
- Что приводит меня к вопросу: Если это исключение возникает в любом случае, почему компилятор его не подхватывает?
У меня тоже была такая ошибка, она была вызвана тем, что программа Any CPU exe ссылалась на сборки Any CPU, которые в свою очередь ссылались на сборки x86.
Исключение жаловалось на метод класса в MyApp.Implementations (Any CPU), который является производным MyApp.Interfaces (Any CPU), но в fuslogvw.exe я нашел скрытое исключение 'attempt to load program with an incorrect format' из MyApp.CommonTypes (x86), которое используется обоими.