Руслан

Я провел эксперимент: в решении два проекта, первый проект (.net standard 2.0) ссылается на nuget пакет, второй проект (.net framework 4.7.2) ссылается на первый. Построение решения происходит успешно, но при запуске второго проекта возникает ошибка: не удалось загрузить сборку из nuget пакета. от сюда вывод - при построении зависимости из nuget пакетов, которые непосредственно не содержатся в проекте не копируются в выходную папку.

Еще я нашел статью: https://terryaney.wordpress.com/2018/05/06/msbuild... в которой это подтверждается и решение заключается в использовании MSBuild со своей конфигурацией. А вот подключать nuget пакеты ко всем проектам - подход не самый лучший (хотя самый простой).

Я продолжил экспериментировать:
Создал нулевой проект (.net standard 2.0) на который ссылается только первый проект. При построении и запуске второго проекта все зависимости были разрешены, приложение запустилось без проблем.

И еще один эксперимент:
Я создал четвертое приложение, но уже .net core 2.1, которое ссылается только на проект 1, и к моему удивление при его сборке и запуске все зависимости, включая nuget пакет были разрешены, запуск произошел успешно.

Видимо, .net standard и .net core проекты строятся не так, как это делают .net framework проекты.

Спасибо Толстый Лорри, за подсказку.
Действительно, без указания ссылки на коллекцию записей в дочерней таблице в виде вот такого свойства:

public virtual ICollection Messages { get; set; }

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

в результате структура классов стала вот такой:

public class ForumTopic
{
        [Key, DatabaseGenerated(System.ComponentModel.DataAnnotations.Schema.DatabaseGeneratedOption.Identity)]
        public int TopicId { get; set; }
        public int LastMessageId { get; set; }
        [ForeignKey("LastMessageId")]
        public virtual ForumMessage LastMessage { get; set; }
        [InverseProperty("Topic")]
        public virtual ICollection<ForumMessage> Messages { get; set; }
}

public class ForumMessage
{
        [Key, DatabaseGenerated(System.ComponentModel.DataAnnotations.Schema.DatabaseGeneratedOption.Identity)]
        public int MessageID { get; set; }
        public int TopicID { get; set; }
        [ForeignKey("TopicID")]
        public virtual ForumTopic Topic { get; set; }
}

Нашел решение на которое меня натолкнул DENIS
в файле кода в самом верху ставим такой код:
extern alias myassembly;

при обращении к классу используем такой синтаксис:
myassembly::namespace.classname.staticmethod1();

и еще в свойствах ссылки на сборку (Solution Explorer -> Project -> References -> myassembly.dll -> Properties), находим параметр "псевдоним" (alias), в котором по умолчанию написано "global", и через запятую добавляем ему "myassembly", т.е. тот идентификатор, который мы в самом начале указывали в extern alias.
После этого все компилируется и работает.
Спасибо DENIS!

Спасибо.
Оказывается, в DB контексте есть специальные настройки, которые могут напрочь отрезать сущности от контекста:
вот кусочек кода, который настраивает контекст:

CFDB rocontext = new CFDB();
rocontext.Configuration.ProxyCreationEnabled = false;//запрещает использовать прокси классы - на выходе у нас те самые типы, которые мы определяли в моделях
rocontext.Configuration.LazyLoadingEnabled = false;//здесь запрещается использовать отложенную подгрузку данных, и если мы не указали в Include сущности, которые нам понадобятся, то получим исключение
rocontext.Configuration.ValidateOnSaveEnabled = false;//отключает проверку при сохранении, а сохранение вообще не подразумевается
rocontext.Configuration.AutoDetectChangesEnabled = false;//отключает проверку на наличие изменений при сохранении, а сохранение вообще не подразумевается

вроде бы такой вариант меня устраивает - ничего кроме нужных мне сущностей не остается и их можно безопасно кэшировать.