VC.NET MFC Extension DLL

[ChaoticCube]

При создании MFC Extension DLL (не Regular) даже если выставить везде в опциях проекта Use MFC as Static Library - MFC все равно компилиться динамически. Можете проверить (у меня даже пустой (созданный мастером и выставленной опцией) проект такой dll компилит их динамически).
 В принципе для подобных dll везде написано, что ее клиент обязан быть приложением MFC. Я так понимаю что эта фраза и означает вышесформулированную траблу.

 Вопрос: прав ли я?
 И если не прав - то как обойти проблему и закинуть MFC статически в длл эту.

[Джон]

Хм... а как ты определяешь зависимость от MFC?
На 7.1 (.NET 2003) это работает. Regular DLL with MFC statically linked даёт ДЛЛ которая не зависит от MFC.

[ChaoticCube]

Определяю depends.exe - вижу их просто.

 Потом - я не про Regular DLL, я про MFC Extension DLL.

 В Regular - действительно все хорошо.

[Джон]

Аaaa... нет не получится на то оно и расширение, вот что MSDN говорит:

MFC extension DLL
Select this option if you want your program to make calls to the MFC library at run time, and if you want to share MFC objects between your DLL and the calling application. This option reduces the disk and memory requirements of your program, if it is composed of multiple executable files that all use the MFC library. Only MFC programs can call functions in your DLL. You must redistribute the MFC DLL with this type of project.

так что ...  она по определению динамическая

А в чём проблема то? Почему Regular не подходит? Это ведь как раз то что ты хочешь, насколько я понял. Те DLL c MFC классами и ничего в придачу.

[ChaoticCube]

Я хочу класс перегруженный от MFC экспортить.

типа class SListCtrl: CListCtrl

И по необходимости у юзера support делать. Это возможно хоть как-то?

[Джон]

Конечно возможно, библиотеки расширения MFC для этого и предназначены. Простейший пример тому сама MFC.  

Я кажется понял, в чём твоя проблема. Ты думал, наверное, что только MFC extension DLL является MFC библиотекой? По идее они все такие. Разница в след.

Одна (Regular statically linked) использует MFC статически, и поэтому не требует её после компиляции и может быть использована как с MFC так и SDK ЕХЕшниками.

Две другие требуют наличия MFC на целевом компе, но одна (Regular shared MFC ) использует её только для себя, поэтоому тоже может быть использована как с MFC так и SDK ЕХЕшниками , а другая (extension) использует её совместно с ЕХЕ и может быть использована ТОЛЬКО с MFC ЕХЕшниками.

"ЕХЕшники" не совсем корректно, тк это могут быть и другие ДЛЛ, но для упрощения я думаю понятно.

А экспортировать MFC классы из ДЛЛ можно, точно так же как и простые классы:

Например для твоего примера:

   #ifdef _MYMFCCLASSDLL_
      #define MYMFCCLASSDLLEXPORT  _declspec(dllexport)
   #else
      #define MYMFCCLASSDLLEXPORT  _declspec(dllimport)
   #endif

class MYMFCCLASSDLLEXPORT CMyListCltrl : public CListCtrl
{
...
}

[ChaoticCube]

Как экспортить классы мне понятно.

Тока в случае с Regular библиотеками и перегрузкой классов от CObject и ниже по иерархии MFC - выдает варнинг, что типа библиотека для этого не предназначена.

В случае с Ext, динамическая загрузка все равно есть. Вопрос - если у мя все dll MFC загружены в Exe статически, либа Ext, что не будет требовать длл MFC на диске?

Скажи какой проект мне делать, как я понял Ext(или ошибаюсь)?
Если делаю Ext и в Exe компилю статически длл MFC на винте у конечного юзверя нужны будут или нет?

[Джон]

ChaoticCube,  Что ты хочешь в конечном итоге получить?

ЕХЕ + ДЛЛ без MFC на целевом компе (ессно, что она тебе нужна в процессе сборки). Подгружается-ли она динамически?
только ЕХЕ (с или без MFC), но в процессе сборки тебе нужна ДЛЛ с MFC классами
и тд Потому, что от этого зависит, что и как тебе надо выбрать.

Собственно все варианты уже перебраны в описании типов ДЛЛ.

На твой последний вопрос ответ - да, нужна MFC. И Regular shared и ЕХТ требуют MFC.

Может тебе LIB нужен для сборки?

[ChaoticCube]

На компе юзверя мне не нужны MFC ДЛЛ. Понятно что во время сборки они мне нужны.

Пусть мой класс перегруженной кнопки к примеру находиться в 1.dll (MFC Ext With Static MFC)

1.exe - файл с прогой (Static MFC) Собираю через 1.lib файл.

На компе конечного юзверя я хочу что б было файло: 1.exe и 1.dll (для облегчения support).

Так вот 1.dll в любом случае грузит MFC динамически (проверено depends.exe)
Если я загружу в exe весь MFC статически при подобной сборке на целевом компе я добьюсь желаимого или нет, вот в чем вопрос.

[Джон]

Сорри за задержку.

Хм... не думаю чтобы это прокатило. Ведь если ты ехпортируешь классы, то при любом изменении ДЛЛ тебе надо будет перекомпилировать и ЕХЕ тоже. Те тебе придётся полный комплект поставлять, а не просто одну ДЛЛ.

Это "вечная" проблемма ДЛЛ. Это кстати и привело к созданию СОМ объектов (ActiveX, ATL). Те экспортируются тн "интерфейсные" - нейтральные классы. Хотя я уехал от темы.

В общем я думаю что ты не сможешь так сделать, как задумал (если я тебя правильно понял):

Даже не знаю, что посоветовать... Если с ходу, то:

1. Ты можешь для облегчения сборки создать статическая библиотеку (LIB) c поддержкой MFC, тогда ЕХЕ можно сделать MFC независимым

2. Использовать "интерфейсный" класс, который в свою очередь мспользует MFC объекты.

А какя вообще задача? в смысле - зачем надо динамически MFC классы подгружать?

[ChaoticCube]

Понял. Спасибо.

Задача - просто хочется весь GUI интерфейс раскидать по dll. Зачем - понятно.

Так вот - пусть сущ. 10 диалогов каждый в своей длл. В 1-ом, 2 и 3 - используются элементы пускай перегруженной кнопки к примеру. Хотелось сделать так что б кнопка лежала отдельно и эти диалоги ее загружали бы.

Другими словами что б в код 1-ой, 2-ой и 3-ей длл не входила кнопка эта, а лежала бы отдельно.

Понял - нельзя. Буду включать статически.

Еще раз спасибо.