СдутыйШарикЕсть Apartment threaded ActiveX Dll.
Instancing корневого объекта – GlobalMultiUse.
Такой объект создается автоматически при вызове клиентом его методов.
Есть ли разумная техника использования методов такого типа объекта в
частных (приватных) классах внутри DLL? Как Global - нельзя. Но никто не мешает сделать экземпляр GlobalMultiUse класса "обычным" способом

Dim object as MyClass
Set object = new MyClass
object.MyMethod

На всякий случай напомню еще, что в библиотеке можно написать Sub Main в модуле и указать ее как Startup Object. А в Sub Main описать переменную типа вашего класса как Public.
Тогда она будет создана при обращении к библиотеке и может быть использована внутри нее.
Не так удобно, как Global, но все таки

СдутыйШарикВопрос – когда клиент обратиться к фабричному методу, определенному в глобал-классе – для него будет создан новый экземпляр, или система сообразит обратиться к закешированному в модуле, содержащем Main ? Будет создан новый :(

По поводу фабрики классов - хороший подход, нормальный. Для того, чтобы и внутри и вне библиотеки был единый (по крайней мере внешне) подход к работе с ф-кой классов могу предложить следующее (возможно это вариация на тему того, что вы обозначили как " «теневой» стандартный модуль, на одноименные функции которого будут полагаться «фабричные» методы GlobalMultiUse – класса.
"):
Пусть есть класс-фабрика классов ClassFactory. Instancing у нее (внимание!) PublicNotCreatable, т.е. ее нельзя создать извне библиотеки (и это хорошо)
В MainModule пишем
Создаем новый класс ClassFactorySupplier. Instancing - GlobalMultyUse. В нем пишем:
Т.о. разработчики и внутри и вне библиотеки привыкнут писать для получения экземпляра какого-либо класса
Только внутри библиотеки это будет доступ к Public переменной из MainModul-я
А вне библиотеки - к свойству GlobalMultyUse класса, хотя экземпляр ClassFactory будет одним и тем же

СдутыйШарикВот еще подумал - Если DLL окажется Retained In Memory, то, наверно,
потребуется писать дополнительный публичный клинап-метод для кешированных в модулях ДЛЛ объектов? А зачем ? Объект освободится из памяти тогда, когда обнулится счетчик ссылок на него.
Просто аккуратно устанавливайте в Nothing все объекты, когда они вам больше не нужны. Как внутри библиотеки, так и вне.

СдутыйШарик авторА зачем ? Объект освободится из памяти тогда, когда обнулится счетчик ссылок на него

Для "нормального" Apartment Threaded DLL, как я понимаю,
кешированный в локальном модуле ДЛЛ объект освободится по завершении клиентского приложения, в момент выгрузки ДЛЛ.

Меняет ли это поведение флаг "Retained In Memory"? Нет Apartment Threaded тут не причем. Они (библиотеки в VB) собственно все Apartment Threaded, только при Single Threaded, это соответствовует одному Apartment :)

Retained In Memory - насколько я помню введен из-за особенностей проектирования компонент под IIS и MTS (?)
MSDNRetained in Memory — This option, available in the Project Properties dialog box for your IIS applications, allows the Visual Basic project to keep its run-time support state permanently loaded on the server's threads, allowing server programs that load Visual Basic projects to run significantly faster. Для *обычного* VB приложения влияния не оказывает, т.к. оно (приложение) не вызывает CoFreeUnusedlibraries

Т.о:
Объект (мы говорим об экземпляре класса) освободится из памяти тогда, когда счетчик ссылок на него станут равным 0. Это легко проверить по поведению Class_Terminate
Однако библиотека из памяти не выгрузится (в случае *обычного* VB приложения), даже если ни один ресурс из нее не используется. Это легко проверить по поведению Sub Main

СдутыйШарик

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

авторPublic Factory As ClassFactory

больше не нужны?
Т.е. как понять, что не нужна больше ф-ка классов ?? Не знаю. Этот вопрос аналогичен такому: "Как понять, что приложение больше не будет создавать объектов ?"
Вы можете:
а) внутри ClassFactory вести свои счетчики созданых объектов. Только придется предположить, что _ссылки_ создаются только через ClassFactory
б) ввести свой метод который будет выставлять ClassFactory в Nothing, когда вы сочтете это необходимым. Т.е. то, что вы предлагали.

Я бы не заморачивался с этим. Создали объект, попользовались, выставили в Nothing. А ClassFactory пускай живет.

Alexey KudinovВы можете:
а) внутри ClassFactory вести свои счетчики созданых объектов. Только придется предположить, что _ссылки_ создаются только через ClassFactory
и конечно набор методов декрементирующих эти счетчики при освобождении ссылок.

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