Полазил я в форумах, почитал и однозначного ответа на сабж не нашел. Задача: разработка in-proc com server, который будет испольщоваться в плагине для офиса (плагин написан на с++), на чем писать? Поскольку с С# я знаком не очень хорошо, то могу иметь лишь приблизительное представление о возможных проблемах.
С++
----------------
+ меньше размер
+ нет привязки к фреймворку
+ работает быстрей (маршалинг)
— сложней контролировать утечки памяти
— возможно сложнее процесс разработки (для кого-то)
C# ----------------
+ проще процесс разработки
+ контроль за утечками выполняется автоматически
Лично я голосую за с++, но начальство склоняется (настаивает) на С#, нужны конструктивные контраргументы Кто что думает по этому вопросу?
При написании плагинов на .Net для unmanaged приложений стоит помнить, что в один процесс может быть загружен только один runtime. Так чтое сть выпишете плагин на .Net 2.0, а кто-то другой на .Net 4.0, то кому-то из вас не повезёт.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, michae1, Вы писали:
A>При написании плагинов на .Net для unmanaged приложений стоит помнить, что в один процесс может быть загружен только один runtime. Так чтое сть выпишете плагин на .Net 2.0, а кто-то другой на .Net 4.0, то кому-то из вас не повезёт.
Что значит "не повезет"?
То есть если в офисе есть плагин написаный с другой версией .Net к примеру более старой и он загружен, то что поизойдет при подгрузке моего плагина, использующего более новую версию?
1. Плагин не загрузиться
2. Броситься ексепшн
3. При использовании нового апи, произойдет креш
4. Что-то еще?
Здравствуйте, michae1, Вы писали:
A>>При написании плагинов на .Net для unmanaged приложений стоит помнить, что в один процесс может быть загружен только один runtime. Так чтое сть выпишете плагин на .Net 2.0, а кто-то другой на .Net 4.0, то кому-то из вас не повезёт. M>Что значит "не повезет"? M>То есть если в офисе есть плагин написаный с другой версией .Net к примеру более старой и он загружен, то что поизойдет при подгрузке моего плагина, использующего более новую версию? M>1. Плагин не загрузиться M>2. Броситься ексепшн M>3. При использовании нового апи, произойдет креш M>4. Что-то еще?
1, 2 или 3 смотря от конкретных версий двух фреймворков. Причём, что особенно гадко, поведение зависит от порядка загрудки плагинов. То есть у вас плагин на .Net 4.0, а у кого-то на 3.5. Если чужой плагин загрузится раньше, то ваш не сможет загрузится (ошибка при ппоытке загрузки). А если ваш загрузится раньше, то, с некоторыми оговорками, всё будет хорошо.
Здравствуйте, michae1, Вы писали:
M>Всем привет,
M>Полазил я в форумах, почитал и однозначного ответа на сабж не нашел. Задача: разработка in-proc com server, который будет испольщоваться в плагине для офиса (плагин написан на с++), на чем писать? Поскольку с С# я знаком не очень хорошо, то могу иметь лишь приблизительное представление о возможных проблемах.
M>С++ M>---------------- M>+ меньше размер M>+ нет привязки к фреймворку M>+ работает быстрей (маршалинг) M>- сложней контролировать утечки памяти M>- возможно сложнее процесс разработки (для кого-то)
M>C# ---------------- M>+ проще процесс разработки M>+ контроль за утечками выполняется автоматически
M>Лично я голосую за с++, но начальство склоняется (настаивает) на С#, нужны конструктивные контраргументы Кто что думает по этому вопросу?
M>З.Ы. возможно c# действительно предпочтительней
Писать inproc-серверы можно и нужно на C++.
Проблема утечек в настоящем C++ уже давно не стоит, а для программирования COM есть
очень неплохая штука — ATL, представленная набором визардов, шаблонов и оберток.
Единственная сложность — сесть да поразбираться что там к чему.
Для не очень заумных архитектур это время обычно занимает от нескольких часов до дней, не больше.
Если в задачи COM-сервера не будет входить что-то, ну слишком уж специфичное для .NET, то C++ однозначно.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, michae1, Вы писали:
A>При написании плагинов на .Net для unmanaged приложений стоит помнить, что в один процесс может быть загружен только один runtime. Так чтое сть выпишете плагин на .Net 2.0, а кто-то другой на .Net 4.0, то кому-то из вас не повезёт.
Еще вопросик: офис — это не unmanaged приложение, то есть теоретически с подгрузкой нескольких плагинов использующих разные версии фреймворка порблем быть не должно?
А вот если в .Net плагине использовать com-объект, написаный на c# и использующий другую версию .Net, тогда и будут траблы?
Здравствуйте, michae1, Вы писали:
M>Еще вопросик: офис — это не unmanaged приложение, то есть теоретически с подгрузкой нескольких плагинов использующих разные версии фреймворка порблем быть не должно?
Офис самое что ни на есть unmanaged приложение.
M>А вот если в .Net плагине использовать com-объект, написаный на c# и использующий другую версию .Net, тогда и будут траблы?
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, michae1, Вы писали:
M>>Еще вопросик: офис — это не unmanaged приложение, то есть теоретически с подгрузкой нескольких плагинов использующих разные версии фреймворка порблем быть не должно?
A>Офис самое что ни на есть unmanaged приложение.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, michae1, Вы писали:
A>При написании плагинов на .Net для unmanaged приложений стоит помнить, что в один процесс может быть загружен только один runtime. Так чтое сть выпишете плагин на .Net 2.0, а кто-то другой на .Net 4.0, то кому-то из вас не повезёт.
Здравствуйте, anton_t, Вы писали:
_>Здравствуйте, adontz, Вы писали:
A>>Здравствуйте, michae1, Вы писали:
A>>При написании плагинов на .Net для unmanaged приложений стоит помнить, что в один процесс может быть загружен только один runtime. Так чтое сть выпишете плагин на .Net 2.0, а кто-то другой на .Net 4.0, то кому-то из вас не повезёт.
_>В MSDN-е написано по-другому (правда сам не пробовал): http://msdn.microsoft.com/en-us/library/ee518876.aspx
А если я использую .Net 3.5 ?
вот выдержка из статьи, которую вы привели:
The .NET Framework has always provided side-by-side hosting for managed code applications, but before the .NET Framework 4, it did not provide that functionality for managed COM components. In the past, managed COM components that were loaded into a process ran either with the version of the runtime that was already loaded or with the latest installed version of the .NET Framework. If this version was not compatible with the COM component, the component would fail.
M>Полазил я в форумах, почитал и однозначного ответа на сабж не нашел. Задача: разработка in-proc com server, который будет испольщоваться в плагине для офиса (плагин написан на с++), на чем писать? Поскольку с С# я знаком не очень хорошо, то могу иметь лишь приблизительное представление о возможных проблемах.
кома на шарпе лучше не писать. Там гемор с деплойментом и весьма серьезный
-регасм _очень_ иногда глючит, и регистрация либы не проходит с 1го раза. И это не глюк самой либы, т.к. вообще-то ее не нужно загружать для генерации CCW, нужно только метаданные прочитать.
-там идет биндинг к версии сборки, т.е. если ты зарегаешь сначала v1.1.1.2, а потом v1.1.1.1 — то это ахтунг — туши свет. Дотнет всегда будет пытаться найти 1.1.1.2 и _только_ ее. Сначала нужно разрегать 1.1.1.2, а потом регать 1.1.1.1 — иначе ничего не работает. А с учетом того что регасм иногда подглючивает получается феерический гемор.
PS: был еще какой-то геморрой с передачей массивов
Здравствуйте, michae1, Вы писали:
M>Лично я голосую за с++, но начальство склоняется (настаивает) на С#, нужны конструктивные контраргументы Кто что думает по этому вопросу?
M>З.Ы. возможно c# действительно предпочтительней
Все зависит от задачи. Просто КОМ-компонент довольно по фигу на чем делать. На плюсах будет по больше гибкости. С точки зрения поддержки КОМ-а объем работ примерно одинаков, если в С++ использовать ATL.
Если задача КОМ-объекта просто вызвать некий С++-АПИ, то шарп тут не нужен. Если нужно писать много логики, то можно подумать о шарпе. Если же ты знаешь С++ и не знаешь Шарп и при этом объем работ не велик, то опять же С++ лучше подойдет. Шарп же упростит работу только при наличии достаточного объема кода который нужно написать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
On 05.05.2011 16:47, michae1 wrote:
> Полазил я в форумах, почитал и однозначного ответа на сабж не нашел. Задача: > разработка in-proc com server, который будет испольщоваться в плагине для офиса > (плагин написан на с++), на чем писать? Поскольку с С# я знаком не очень хорошо, > то могу иметь лишь приблизительное представление о возможных проблемах.
> — сложней контролировать утечки памяти
Это не проблема вообще, если ты не дурак и не склеротик.
Если плагин написан на С++, то наверное легче будет взаимодействовать
с ним на С++, нет ?
Здравствуйте, michae1, Вы писали:
M>А если я использую .Net 3.5 ?
M>вот выдержка из статьи, которую вы привели: M>
M>The .NET Framework has always provided side-by-side hosting for managed code applications, but before the .NET Framework 4, it did not provide that functionality for managed COM components. In the past, managed COM components that were loaded into a process ran either with the version of the runtime that was already loaded or with the latest installed version of the .NET Framework. If this version was not compatible with the COM component, the component would fail.
Вопрос в том, нужна поддержка юзеров, у которых есть 1.1 или нет. Если не нужна, то пиши на 3.5, если нужна — переходи на 4.0 или c++.
Здравствуйте, adontz, Вы писали:
A>1, 2 или 3 смотря от конкретных версий двух фреймворков. Причём, что особенно гадко, поведение зависит от порядка загрудки плагинов. То есть у вас плагин на .Net 4.0, а у кого-то на 3.5. Если чужой плагин загрузится раньше, то ваш не сможет загрузится (ошибка при ппоытке загрузки). А если ваш загрузится раньше, то, с некоторыми оговорками, всё будет хорошо.
А если вручную CLR-хосты инициализировать? Разве нельзя их сколько угодно из разных DLL проинициализировать?
Здравствуйте, MasterZiv, Вы писали:
MZ>On 05.05.2011 16:47, michae1 wrote:
MZ>Если плагин написан на С++, то наверное легче будет взаимодействовать MZ>с ним на С++, нет ?
Да нет, это ж обычный com объект, нет разницы на чем он сделан.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, michae1, Вы писали:
A>При написании плагинов на .Net для unmanaged приложений стоит помнить, что в один процесс может быть загружен только один runtime. Так чтое сть выпишете плагин на .Net 2.0, а кто-то другой на .Net 4.0, то кому-то из вас не повезёт.
Здравствуйте, michae1, Вы писали:
M>Здравствуйте, adontz, Вы писали:
A>>Здравствуйте, michae1, Вы писали:
A>>При написании плагинов на .Net для unmanaged приложений стоит помнить, что в один процесс может быть загружен только один runtime. Так чтое сть выпишете плагин на .Net 2.0, а кто-то другой на .Net 4.0, то кому-то из вас не повезёт.
M>Еще вопросик: офис — это не unmanaged приложение, то есть теоретически с подгрузкой нескольких плагинов использующих разные версии фреймворка порблем быть не должно?
M>А вот если в .Net плагине использовать com-объект, написаный на c# и использующий другую версию .Net, тогда и будут траблы?
Не будут, не слушай его.
Проблема актуальна для старых версий .NET, если ты сейчас писать будешь, то вряд ли столкнешься с ними.
Здравствуйте, MasterZiv, Вы писали:
MZ>On 05.05.2011 16:47, michae1 wrote:
>> Полазил я в форумах, почитал и однозначного ответа на сабж не нашел. Задача: >> разработка in-proc com server, который будет испольщоваться в плагине для офиса >> (плагин написан на с++), на чем писать? Поскольку с С# я знаком не очень хорошо, >> то могу иметь лишь приблизительное представление о возможных проблемах.
>> — сложней контролировать утечки памяти
MZ>Это не проблема вообще, если ты не дурак и не склеротик.
Мсье много писал COM?
MZ>Если плагин написан на С++, то наверное легче будет взаимодействовать MZ>с ним на С++, нет ?
COM и нужен для того чтобы отвязать компонентность от языка.
Кто что думает по этому вопросу?
