sql

[Александр Пекшев aka Modis]

строка подключения в код и вбита при создании контекста БД (так как конфиг плагина игнорируется ) - это работает при запуске плагина.
проблема начинается тогда , когда этот плагин с работой БД добавляется ссылкой (как библиотека) в другой плагин - и тут при запуске этой БД из этой ссылки вылетает ошибка

Звучит как какая-то ерунда )) Какая ошибка вылетает? Покажите хоть код како-то

[enot]

Ошибка: No connection string named "Model" could be found in the application config file

Код - C# [Выбрать]

1. public partial class Model: DbContext  
2.     {  
3.         public Model() : base()  
4.         {  
5.             ConnectionString ="тут задаю"  
6.         }  
7.  
8.     }  

1.) Собираю dll_db - запускаю как плагин -> создаю экземпляр Model - ок, работает

2.)Далее собираю этот dll_db и подгружаю как ссылку в другой dll (плагин). Запускаю в dll метод dll _db. -> создаю экземпляр Model - ошибка 

[Александр Пекшев aka Modis]

No connection string named "Model" could be found in the application config file

https://stackoverflow.com/a/19189647/4944499

[Дмитрий Загорулькин]

Немного оффтопика в тему:
Пока я работал в большой конторе, то часто видел практику использования файлов конфигов для такого рода значений - строка подключения к БД, какие-то URL и т.п. Причем, не задолго до моего увольнения, там начали прям обширно это использовать. Задумка ясна как день - поменять какие-то значения не пересобирая плагин... НО! Но это все в теории. На практике никто из пользователей во-первых не знает об этих конфигах, а во-вторых не будет в них ничего менять (ибо нафиг им это не надо). Поэтому новые значения в этих же конфигах доставляются до пользователей с новыми версиями плагинов. Смешно ))
Так что, ИМХО - вбивайте путь подключения к БД прям в код и ничего в вашей жизни

Не, конфиги точно не для пользователей. Но это довольно логичное и привычное для всех место хранения информации-настроек. Например, изменилась строка подключения. Прилетела задача разработчику - изменить в плагине. Он открывает плагин, идёт в конфиг и меняет. Даже если это не его плагин, даже если он его открыл в первый раз в жизни, он знает: строка подключения - это настройка и она в конфиге. Вот такая унификация и есть тот самый основной профит.

[Александр Пекшев aka Modis]

Не, конфиги точно не для пользователей. Но это довольно логичное и привычное для всех место хранения информации-настроек. Например, изменилась строка подключения. Прилетела задача разработчику - изменить в плагине. Он открывает плагин, идёт в конфиг и меняет. Даже если это не его плагин, даже если он его открыл в первый раз в жизни, он знает: строка подключения - это настройка и она в конфиге. Вот такая унификация и есть тот самый основной профит.

Да, пожалуй в таком ключе (при коллективной работе) ты прав - есть профит. Но все-равно сомнительный: если я первый раз вижу этот проект, то мне все равно придется найти место, где используется значение из конфига, чтобы убедиться, что это оно мне нужно. Исключение - это если есть прям подробная справка к проекту, актуальности которой я могу верить. Если я не в первый раз вижу проект, то для меня практически одинаково трудозатратно будет поменять нужное значение что в конфиге, что в коде

[trir]

ConnectionString надо добавить в аргументы конструктора модели