Подключение dll к проекту

[SlipDez]

Пробую в проекте добавить ссылки на библиотеки для netframework 4.6.2 все добавляется кроме одной которая по видимому написана не на c#. Почитал и как понял нативные библиотеки добавлять в проект не нужно (ну да логично) кидаю ее в папку ..Progs\ExternalAssemblies чтобы библиотека сама использовала нативный код. Но судя по ошибке она не может его найти.

Итого:
1) Net библиотека.dll ( не видит нативный код NativeCode.dll)
2) Net библиотека2.dll
3) NativeCode.dll который использует библиотека 1

Все 3 файла лежат в 1 папке, что делать?

 

[Zedx]

Ещё есть опция, что зенка тупо не хочет подключать библиотеки для net framework, выдавая рандомные ошибки при попытке их подключения. У меня несколько таких проектов, незаконченных именно из-за этого. Тут только ждать обещанную 8ую версию, в которой обещали обновить c# до новых версий. Но судя по всему обещанной версии всё-таки не будет, а значит и возможности нормально работать со сторонними dll

 

[SlipDez]

Ещё есть опция, что зенка тупо не хочет подключать библиотеки для net framework, выдавая рандомные ошибки при попытке их подключения. У меня несколько таких проектов, незаконченных именно из-за этого. Тут только ждать обещанную 8ую версию, в которой обещали обновить c# до новых версий. Но судя по всему обещанной версии всё-таки не будет, а значит и возможности нормально работать со сторонними dll

Не подскажешь, мб есть какой-то костыль? Gpt подсказывал перебрал множество вариантов пишет что библиотека импортирована все ок, а по факту когда начинаешь работать говорит что такой нет

 

[Zedx]

Не подскажешь, мб есть какой-то костыль? Gpt подсказывал перебрал множество вариантов пишет что библиотека импортирована все ок, а по факту когда начинаешь работать говорит что такой нет

Я в качестве костыля собираю ехе файл с нужной логикой и уже его запускаю из зенки

 

[Yuriy Zymlex]

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

Ещё есть опция, что зенка тупо не хочет подключать библиотеки для net framework, выдавая рандомные ошибки при попытке их подключения. У меня несколько таких проектов, незаконченных именно из-за этого.

Это обычные конфликты зависимостей, лишь часть из которых м.б. в теории нерешаема, с какими-то древними, ограниченными библиотеками.

собираю ехе файл с нужной логикой и уже его запускаю из зенки

Это лучшее решение и не ограничивает даже в языке программирования.

Я в качестве костыля

Открою вам секрет, сейчас всё больше программ так делает (например, браузеры), надеюсь это дойдёт и до потоков постера, так как это решит и вашу проблему.

 

[Alex91]

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

Это обычные конфликты зависимостей, лишь часть из которых м.б. в теории нерешаема, с какими-то древними, ограниченными библиотеками.

Это лучшее решение и не ограничивает даже в языке программирования.

Открою вам секрет, сейчас всё больше программ так делает (например, браузеры), надеюсь это дойдёт и до потоков постера, так как это решит и вашу проблему.

Это хорошо если для себя делаешь...
А если на продажу, то считай даришь весь код.

Ведь ценность зеннопостера это защита проектов при продаже... А не вот эти ваши все баги

 

[Zedx]

Открою вам секрет, сейчас всё больше программ так делает (например, браузеры), надеюсь это дойдёт и до потоков постера, так как это решит и вашу проблему.

У меня есть задачи, требующие большой скорости выполнения. Запуск ехе занимает очень много времени, что не позволяет использовать проект по своему назначению. Так что хотелось бы конечно иметь возможность нормальной работы с актуальной версией c#

 

[Yuriy Zymlex]

У меня есть задачи, требующие большой скорости выполнения. Запуск ехе занимает очень много времени, что не позволяет использовать проект по своему назначению. Так что хотелось бы конечно иметь возможность нормальной работы с актуальной версией c#

Тут только вы решаете, как будет работать ваш exe, вам необязательно его завершать, когда можно переиспользовать.
Учитывайте, что .net и всё что с ним связано, само по себе требует долгого запуска.

 

[Zedx]

Тут только вы решаете, как будет работать ваш exe, вам необязательно его завершать, когда можно переиспользовать.
Учитывайте, что .net и всё что с ним связано, само по себе требует долгого запуска.

Логично всё это сделать полностью на C# - будет запускаться 1 раз и работать быстро как надо, тогда зеннопостер в этой цепочке вообще без надобности. Но клиентам нужен именно зеннопостер, т.к. им удобно работатьс ним. Вот тут и возникает проблема, что зеннопостер не позволяет достичь нужного функционала из-за старой версии с#, приходится городить костыли из запуска ехе, теряется скорость, результат не достигнут.

 

[SlipDez]

Я в качестве костыля собираю ехе файл с нужной логикой и уже его запускаю из зенки

Тоже так делал с некоторыми библиотеками, через компиляцию в единый exe проекта .net загоняю его в base64 и в момент когда надо использовать
- перевожу base64 в байты
- записываю байты в файл
- запускаю файл и получаю std out но это костыль костыль

 

[SlipDez]

Это хорошо если для себя делаешь...
А если на продажу, то считай даришь весь код.

Ведь ценность зеннопостера это защита проектов при продаже... А не вот эти ваши все баги

Выше показал, как можно делать чтобы не дарить код и не тащить данные. Файл хранишь в переменной base64 на лету переводишь в байты записываешь в рандомную директорию (например папка Temp) с рандомным названием запускаешь без окна консоли получаешь вывод, удаляешь файл. Единственный минус что если очень большая логика либо много зависимостей размер файла будет не маленьким

 

[SlipDez]

Тут только вы решаете, как будет работать ваш exe, вам необязательно его завершать, когда можно переиспользовать.
Учитывайте, что .net и всё что с ним связано, само по себе требует долгого запуска.

Библиотеки же априори работают быстрее чем запуск *.exe К тому же получать std out без отлова ошибок конкретных мест это действительно костыль

 

[SlipDez]

Решение нашлось случайно, это установка самых первых версий библиотек. Библиотека OpenCvSharp. Никакие другие методы не помогли, даже импорт dll import через c#

 

[Zedx]

Решение нашлось случайно, это установка самых первых версий библиотек.

Ну это повезло, что были такие старые версии. Во многих случаях библиотек под .net framework уже не найти. Недавно декомпилировал нужную библиотеку и пересобирал её вручную именно под .net framework, но в итоге всё равно не удалось подключить из-за какой-то очередной несовместимости с зенкой. Короче постоянный геморой, если хочешь поработать с какой-нибудь сторонней библиотекой

 

[SlipDez]

Понимаю)