Создайте DLL C#, Который Может быть Импортирован в Приложении Delphi Используя stdcall - Возможный?
Это не совсем так, поскольку файловая система NTFS поддерживает пути длиной до 32 тыс. Символов. Вы можете использовать API-интерфейс win32 и префикс пути «\\?\», чтобы использовать более 260 символов.
Подробное объяснение длинного пути из блога .Net BCL team .
Небольшая выдержка подчеркивает проблему с длинными путями
Еще одной проблемой является непоследовательное поведение, которое может возникнуть в результате предоставления поддержки длинных путей. Длинные пути с префиксом
\\?\могут использоваться в большинстве файловых API Windows, но не во всех Windows API. Например, LoadLibrary, который отображает модуль на адрес вызывающего процесса, завершается ошибкой, если имя файла длиннее, чем MAX_PATH. Таким образом, это означает, что MoveFile позволит вам переместить библиотеку DLL в такое место, где ее путь будет длиннее 260 символов, но при попытке загрузить библиотеку DLL произойдет сбой. Есть аналогичные примеры в Windows API; Существуют некоторые обходные пути, но они применяются в каждом конкретном случае.
9 ответов
Это невозможно в чистом C #, но это статья , в которой показано, как добавить неуправляемую таблицу экспорта в вашу библиотеку C #, которую затем можно использовать на любом другом языке. Обратите внимание, что множество ссылок на Blitz не должно вас отпугнуть - они относятся к собственному контексту автора и не имеют ничего общего с основной концепцией и принципами ее работы.
Также есть раздел в Брайана Лонга. доклад конференции . По иронии судьбы, Delphi.Net фактически поддерживает неуправляемый экспорт напрямую, несмотря на то, что C # этого не делает. Я понятия не имею, верно ли это и для Delphi Prism.
Обратите внимание, что множество ссылок на Blitz не должно вас отпугнуть - они относятся к собственному контексту автора и не имеют ничего общего с основной концепцией и принципами ее работы.Также есть раздел в Брайана Лонга. доклад конференции . По иронии судьбы, Delphi.Net фактически поддерживает неуправляемый экспорт напрямую, несмотря на то, что C # этого не делает. Я понятия не имею, верно ли это и для Delphi Prism.
Обратите внимание, что множество ссылок на Blitz не должно вас отпугнуть - они относятся к собственному контексту автора и не имеют ничего общего с основной концепцией и тем, как она работает.Также есть раздел в Брайана Лонга. доклад конференции . По иронии судьбы, Delphi.Net фактически поддерживает неуправляемый экспорт напрямую, несмотря на то, что C # этого не делает. Я понятия не имею, верно ли это и для Delphi Prism.
Я уже был на этом пути раньше. Решение, которое я выбрал, заключалось в создании НОВОЙ сборки C # (позже я перенес ее в Prism), которая через com-взаимодействие предоставляла функциональные возможности, необходимые мне. Я нашел, превратив вызовы API в черный ящик во что-то более простое, я смог уменьшить количество классов, с которыми мне приходилось иметь дело через барьер взаимодействия.
Я действительно смотрел на Гидру, но это было излишним для того, что я пытался чтобы сделать ... это был доступ к стороннему SDK, который был представлен в сборках .net для обработки данных. Если вы хотите встраивать в свое приложение функциональные возможности (объекты gui и т. Д.), Вам следует уделить внимание Hydra.
Я действительно использовал Managed.VCL для очень ранней версии системы, но позже отказался от него для Prism / C # com подход к взаимодействию, который было проще развернуть,
Из любопытства, почему вы надеетесь написать .dll, предназначенную для использования из собственного приложения на C #?
Управляемый C ++, Delphi для .Net, а теперь и Delphi Prism - все поддерживайте это прямо из коробки, используя неуправляемый экспорт. По дизайну C # и VB.net этого не делают. Не знаю почему. Но, как упомянул Кобус, вы можете обойти это стороной. Делайте это на свой страх и риск.
Помимо Hydra от RemObjects, AToZed представляет CrossTalk .
Вам необходимо сделать сборку (= C # DLL) доступной для COM, что называется Interop.
См. Статьи MSDN Преобразование сборки в библиотеку типов и ] Упаковка сборки для COM , которая описывает технические основы и утилиты для выполнения требуемых операций.
Здесь я предполагаю, что приложение Delphi не является приложением на основе .NET, и поэтому вам необходимо разместить среду выполнения .NET в процессе Win32.
- Размещение среды выполнения .NET в программа Delphi
- .Net - использование сборки C # из Delphi Win32
- CorBindToRuntimeEx
CorBindToRuntimeEx - это функция внутри MSCorEE.dll, которая содержит среду выполнения .NET. С его помощью вы можете размещать среду выполнения, а затем создавать внутри нее объекты и взаимодействовать с ними.
Я нашел сообщение Роберта Гизеке в группах новостей Delphi Prism. В нем он объявляет о проекте, который вы можете добавить к решению, которое позволяет вам экспортировать произвольные функции из .Net DLL, просто добавив к ним атрибут DllExport . Он поддерживает маршалинг так же, как DllImport . Он демонстрирует это с помощью проекта Prism, но я полагаю, что он будет работать и с классами C #. Сообщение было сделано в марте, поэтому я не уверен, будет ли вложение по-прежнему доступно. В майском выпуске Prism нет такого инструмента, поскольку он сам по себе поддерживает неуправляемый экспорт.
Я совершенно уверен, что это невозможно сделать напрямую. Вам нужно будет либо написать слой на C ++ / CLI, либо предоставить код C # как интерфейс ActiveX. Но этот второй вариант может не соответствовать вашему интерфейсу.
Это невозможно. C # - это управляемый код. Это означает, что для его работы требуется очень специфическая среда выполнения, среда, которую Delphi не может предоставить ему напрямую. Это не похоже на язык C, где вы просто находите адрес и соглашение о вызовах функции и вызываете ее.
Однако можно разместить Common Language Runtime внутри приложения Delphi (или любого другого приложения Windows). Понятия не имею, как это сделать. Я просто знаю, что это возможно. (Вполне вероятно, что именно этим и будет заниматься эта «Гидра», о которой говорил Стив.)