новичковій вопрос , но искал и найти немогу и все:    

вообщем назрело - насобирал кучу методов которые мона пихать в отдельные бибилиотеки и использовать в разных программах (Даёш открытие исходники!!!!!    ), но дело в том что пишу исключительно кодом - тойсь Студией пользуюся лиш как компилятором и варинты типа АДД РЕФЕРАНС а потом накарлякать юзинг МайДЛЛ непропрёт вот и вопрос

Как используя только код подключить другую сброрку, чтобы мона было использовать ее методы?????

пока нашол самое похожое Assembly.Load() - но это походу не то

плиз хочу ЛИСТ ор ПРИМЕРЧИК      

Добавлено через 1 минуту и 52 секунды
в DllImport пишешь  путь к своей dll-ке, затем метод который хочешь импортировать из dll

респект RWander примерчик ничего, но начал разбираться чуть нето       - более используеться для сборок на С, к тому же не все так просто там еще кучу атрибутов нана правильно прописать, но всё равно спасибо и в том тож разобрался - ну сильно уж сложно  

зато подтолкнул к другой идее (где-то рядом было  )
через Assembly.Load("DLLname");    плюс чучуть позднего связывания  

using System.IO;
using System.Reflection;




я открыт для предложений - мож это вообще не эффективно и поздное связывание не в тему
подкинте еще вариантики плиз      

Azzdorf,  не буду врать, по поводу как подключается через AddReference... но что-то разницы в быстродействии я не заметил.

Да и иногда удобно использовать Reflection, облегчает жизнь очень.

Azzdorf, что-то непонятна твоя цель.

Есть раннее (статическое) связывание - через references и компиляцию
Есть позднее (динамическое) связывание - через AppDomain, Assembly, Type.

Можно конечно и код на лету генерировать, и сборки, и компилировать программно, но зачем?
Ты, как я понял, пишешь dll-ки? Ну и пиши.  Нужно использовать? Используй 

А подключать библиотеки к другим проектам подключать статически или динамически - это уже будет зависеть от каждого конкретного проекта (клиента, их использующего). Если проект постоянно требует одну и ту же dll - то лучше подключить статически (производительность выше будет). Если же при запуске проекта неизвестно какая нужна будет dll - то тогда динамическое связывание используй.

Azzdorf, по поводу такой загрузки - у тебя может возникнуть проблема с безопасностью
я делал через лоад фром, где указывал евиденс текущей сборки
по поводу вызова метода - добавь в основном теле или в ссылки интерфейс или базовый тип, 
просто через инвокмембер или как ты делаешь - не совсем удобно и наглядно получается 

2 tol05 тут как раз дело в том что DLL никогда не писал, ранее был один файл сборки и поэтому в плане подключения и использования вообще ноль - поэтому над этим сейчас работаю и  , также не приходилось никогда и работать не с ранним не с поздним связыванием, не с статическими сслками, если есть возможность подскажы как это нимимумом кода сделать, а выше лишь пока самое оптимальное решение, которое я нашол


2 izekia ну с интерфесами я еще не работал - просто небыло потребности (пишу программы лишь в свое удовольствие, правда есть уже один комерческий проект), а вот по поводу безопасности сейчас разбираюсь в осбусификаторах, и как до этого времени почитал внутрености метода уже не можна будет прочитать, думал этого будет хватит для безопасности


2 all если кто знает самый оптимальный вариант по скорости и еффективности использования ресурсов - всегда открыт для предложений (к теме библиотека - что то типа LOG-системы, неспрашивайте даже зачем писал если есть стандартная просто было инстересно было это сделать, когда закончу - выложу полный исходник ДЛЛ - что-то очень простое, но удобное для меня лично, но мож кому-то пригодится, там есть интересные решения)
  

Azzdorf, интерфейс это фактически описание контракта класса
под безопасностью я имел в виду внутренний механизм платформы дот нет для обеспечения безопасности 

Azzdorf


создаешь проект "Class Library", туда - твои классы с методами. Скомпилировал - и вот уже dll есть. Пишешь ее на CD-ROM и ставишь на полку. Библиотека классов создана!   

Но ты же код пишешь для повторного использования (в других проектах)? Ну так создаешь проект и если он должен использовать код библиотеки - используешь статической связывание сборки библиотеки со сборкой проекта (приложения или еще одной бибдиотеки). Add reference используй. В коде - через using... Одним словом - все так же, как и со стандартными библиотеками .Net (System.Data.dll например)

При статическом связывании компилятор может поверить защищенность типов, правильность и допустимость ссылок, оптимизировать код. За счет этого быстродействие твоего приложения в целом будет выше, чем при динамическом связывании (через рефлексию). Потому что при динамическом связывании тебе прийдется в твоем проекте-клиенте оперировать не типами, описанными в твоей dll, а типом object. И в runtime будут снижать производительность приведения типов, многочисленные проверки (а их нужно писать самому - значит объем кода приложения клиента выростет) ... Компилятор не будет оптимизировать код.

Ну и т.д.
Мне кажется, вполне очевидно какой вариант является оптимальным (и с точки зрения быстродействия, и с точки зрения ресурсов, той же памяти). Просто динамическое связывание применяют в редких случаях. Например, когда ты запускает приложение-клиент, а dll - из сети подгружаешь... Или когда плагин новый к старому приложению выпускаешь...


Это сообщение отредактировал(а) tol05 - 13.12.2007, 12:00

библиотеки то писать умею - просто до этого момента не чувствовал острой потребности. А про то что пользуюсь только кодом (см. сообщение 1) и АДДреферанс (см. сообщение 1) не совем для меня так мне нравиться смотреть так сказать в глубь проблемы + специфика программа, которые ставяться с очень урезаным доступоми, вообщем за советы спосибо, но тут тогда вопрос:

Есть ли альтернатива статической подгрузки, через использование (Add Referance...  and using DLLL) ?????  

Нет. Потому что компилятор должен знать, что он компилирует. И если в коде не указаны референсы и using-и, то это (как считает компилятор) - не код, а набор безсмысленных символов. 
Можно конечно перед вызовом компилятора (csc.exe) самому открывать файлы солюшена и проекта, вручную (или через свою утилиту) прописывать настройки (то, что делает студия при Add reference), потом вручную прописать using-и в файле кода... 
Можно вообще открыть файл кода потоком и replace любые имена и типы... Но я такого не делал (и в обозримом будущем не планирую).

P.S. можно запускать компилятор с командной строки и там указывать /reference  но в коде все равно нужно прописывать имена типов. Иначе с ними работать можно только через рефлексию.

Это сообщение отредактировал(а) tol05 - 13.12.2007, 17:32

ввобщем с "подводными течениеми" в моей голове (мол только кодом) - поздное связывание - найлучший вариант???????  

Это универсальный вариант, но и самый медленный. За все нужно платить 

огромное спасибо всем проблема решена

спасибо izekia за просвет в безопасности (это отдельная тема для разговора)

и 

ОГРОМНОЕ пасибки tol05, будем дерзать знания

tol05, а что мешает объявить интерфейс в основной программе?
есть куча вариантов использовать динамическую загрузку и не пользоваться рефлексией + удобно очень то что не надо пересобирать все с кучей зависимостей, а просто компилишь одну библиотеку и подгружаешь ее не перегружая весь проект