-
May 24th, 2015, 03:58 PM
#1
Thread Starter
Hyperactive Member
[RESOLVED] Plugin framework without DLL registering
Can someone show me an example of a plugin framework which doesn't require registration of an ActiveX DLL? Thanks in advance!
EDIT: Right after posting I've found DirectCOM Demo. I'll try to experiment with that and post here results.
Last edited by MikiSoft; May 25th, 2015 at 02:56 PM.
-
May 24th, 2015, 04:47 PM
#2
Thread Starter
Hyperactive Member
Re: Plugin framework without DLL registering
Okay, here is in attachment what I've done so far - I've combined DirectCOM with an example from this article, but it doesn't work with COM DLL examples created in other languages (C++, Java...). Where I'm wrong?
edit> Attachment removed by mod. Contains compiled dll.
Last edited by FunkyDexter; May 27th, 2015 at 09:39 PM.
-
May 25th, 2015, 11:52 AM
#3
Thread Starter
Hyperactive Member
Re: Plugin framework without DLL registering (DirectCOM)
-
May 25th, 2015, 12:15 PM
#4
Re: Plugin framework without DLL registering (DirectCOM)
Do the C++ and Java plugins work if you go the regular RegSvr32 route? If not, maybe the runtimes are missing?
-
May 25th, 2015, 12:16 PM
#5
Thread Starter
Hyperactive Member
Re: Plugin framework without DLL registering (DirectCOM)
Originally Posted by jpbro
Do the C++ and Java plugins work if you go the regular RegSvr32 route?
The Java DLL doesn't work but C++ should because it works when it's regularly registered.
Last edited by MikiSoft; May 25th, 2015 at 03:07 PM.
-
May 25th, 2015, 12:30 PM
#6
Re: Plugin framework without DLL registering (DirectCOM)
Looks like the error might be occurring in the C++ DLL itself - the GetInstance call is returning an object, but the subsequent SetHost call fails. Perhaps the plugin is expecting itself to be registered, and performing some test that is raising the error?
-
May 25th, 2015, 12:53 PM
#7
Thread Starter
Hyperactive Member
Re: Plugin framework without DLL registering (DirectCOM)
You can check the source of it in "plugins" folder, because I don't know C++/Java I can't tell if that's true or not. But it acts the same as VB6 DLL so I think that it's unlikely that it does such thing.
Last edited by MikiSoft; May 25th, 2015 at 01:32 PM.
-
May 25th, 2015, 02:08 PM
#8
Re: Plugin framework without DLL registering (DirectCOM)
-
May 25th, 2015, 02:20 PM
#9
Thread Starter
Hyperactive Member
Re: Plugin framework without DLL registering (DirectCOM)
Thanks, The trick! But can it be easier like this function (which doesn't work in this case), to not require CLSID or a TLB file to be specified (only DLL and class name)? It is very important for the plugin framework since for the program is much easier to implement a object only by knowing it's DLL location and a class name.
Last edited by MikiSoft; May 25th, 2015 at 02:38 PM.
-
May 25th, 2015, 02:27 PM
#10
Re: Plugin framework without DLL registering (DirectCOM)
Usually the type library is contained in DLL, therefore you can just use like this:
vb Code:
Set iMsg = CreateObjectEx2("AtlSample.dll", "AtlSample.dll", "plugin")
-
May 25th, 2015, 02:30 PM
#11
Thread Starter
Hyperactive Member
Re: Plugin framework without DLL registering (DirectCOM)
Doesn't work - first for "AtlSample" (C++ DLL) it displays me an error that library isn't registered, then for Java DLL it throws an error about ActiveX which can't create object, and after that for VB6 DLL it crashes.
Last edited by MikiSoft; May 25th, 2015 at 02:41 PM.
-
May 25th, 2015, 02:41 PM
#12
Re: Plugin framework without DLL registering (DirectCOM)
What is error? What is DLL? Your DLL's in my computer work correctly.
EDIT:
AtlSample.dll and vbplugin.dll work perfect, but javaSample_2.dll not work. Look, after registration javaSample_2.dll also not worked. If i add javaSample_2.dll in Project->References and write like this:
vb Code:
Dim iMsg As javaSample_2.plugin
Set iMsg = New javaSample_2.plugin
Perhaps it DLL required some DLL which not present in my computer?
Last edited by The trick; May 25th, 2015 at 02:49 PM.
-
May 25th, 2015, 02:48 PM
#13
Thread Starter
Hyperactive Member
Re: Plugin framework without DLL registering (DirectCOM)
Then ignore the Java DLL, it surely requires the outdated J++ runtime so I won't bother with that.
I'm using Windows XP SP3 with VB6 SP6. It should at least work for the VB DLL but it crashes when it tries to load it ("vbsample.dll").
Last edited by MikiSoft; May 25th, 2015 at 03:06 PM.
-
May 25th, 2015, 03:36 PM
#14
Re: Plugin framework without DLL registering
Into AtlSample being called LoadRegTypeLib which return TYPE_E_LIBNOTREGISTERED.
Therefore you must anyway change code:
-
May 25th, 2015, 03:37 PM
#15
Thread Starter
Hyperactive Member
Re: Plugin framework without DLL registering
What about VB6 DLL? Why it causes crash?
-
May 25th, 2015, 03:37 PM
#16
Re: Plugin framework without DLL registering
-
May 25th, 2015, 03:43 PM
#17
Thread Starter
Hyperactive Member
Re: Plugin framework without DLL registering
Also do you have some function that performs registration of a COM DLL? I want to deal with such situations, if your function throws an error that library needs to be registered then to proceed with registering it and creating the object on a traditional way.
-
May 25th, 2015, 03:46 PM
#18
Re: Plugin framework without DLL registering
Yes of course:
vb Code:
Option Explicit Private Declare Function DispCallFunc Lib "oleaut32" (ByVal PPV As Long, ByVal oVft As Long, ByVal cc As Long, ByVal rtTYP As VbVarType, ByVal paCNT As Long, paTypes As Any, paValues As Any, ByRef fuReturn As Variant) As Long Private Declare Function LoadLibrary Lib "kernel32" Alias "LoadLibraryW" (ByVal lpLibFileName As Long) As Long Private Declare Function GetProcAddress Lib "kernel32" (ByVal hModule As Long, ByVal lpProcName As String) As Long Private Declare Function FreeLibrary Lib "kernel32" (ByVal hLibModule As Long) As Long Private Const CC_STDCALL = 4 ' Функция регистрирует ActiveX библиотеку, Unload - выгружать библиотеку из памяти или нет ' В случае успеха возвращает True Private Function RegisterDll(Path As String, Optional ByVal Unload As Boolean = True) As Boolean Dim hLib As Long Dim pAdr As Long Dim rRet As Variant hLib = LoadLibrary(StrPtr(Path)) If hLib = 0 Then Exit Function pAdr = GetProcAddress(hLib, "DllRegisterServer") If pAdr Then If DispCallFunc(0, pAdr, CC_STDCALL, vbLong, 0, 0, 0, rRet) = 0 Then If rRet = 0 Then RegisterDll = True End If End If If Unload Then FreeLibrary hLib End Function ' Функция снимает регистрирацию ActiveX библиотеки ' В случае успеха возвращает True Private Function DeregisterDll(Path As String) As Boolean Dim hLib As Long Dim pAdr As Long Dim rRet As Variant hLib = LoadLibrary(StrPtr(Path)) If hLib = 0 Then Exit Function pAdr = GetProcAddress(hLib, "DllUnregisterServer") If pAdr Then If DispCallFunc(0, pAdr, CC_STDCALL, vbLong, 0, 0, 0, rRet) = 0 Then If rRet = 0 Then DeregisterDll = True End If End If FreeLibrary hLib End Function
-
May 25th, 2015, 03:49 PM
#19
Thread Starter
Hyperactive Member
Re: Plugin framework without DLL registering
Thanks! Waiting for your revision of function which creates object without registration and then I shall combine them into the one.
I have one question about the last function: Is possible to create object right after registration from memory without unloading and loading it again (using Unload = False)?
Last edited by MikiSoft; May 25th, 2015 at 03:55 PM.
-
May 25th, 2015, 04:32 PM
#20
Re: Plugin framework without DLL registering
I found bug. VB6 don't cast to Object (IDispatch) a returned value from CreateObjectEx2.
Solve:
vb Code:
Set plugins(i) = CreateObjectEx2(CStr(tmp(i)), CStr(tmp(i)), "plugin")
Perhaps it's new VB6 bug, if pass elements of array directly vb6 don't call __vbaCastObj because of this all called methods works with the IUnknown virtual table.
My advise: you chose bad approach, most better if you would create single interface and all your plugins implement this interface. Therefore you just add tlb with interface definitions, and all your objects will casted with this interface. It most faster than using IDispatch implementation.
TLB you can create into VB6 without problems as example.
-
May 25th, 2015, 04:37 PM
#21
Thread Starter
Hyperactive Member
Re: Plugin framework without DLL registering
Thanks for the effort! Can you show me example of that approach? All I want is to dynamically load DLLs (without knowing which ones exactly) from some directory where they will be put, so new plugins can be added without pain - just by pasting theirs DLL into that directory.
-
May 25th, 2015, 06:02 PM
#22
Re: Plugin framework without DLL registering
I wrote small example. Before you must develop a interface. For example - interface with 2 methods (call it IPluginInterface):
vb Code:
' // This is main plugin interface.
' // All plugins must implement this interface
' // In order to create the type lybrary need set checkbox in ProjectProperties -> Remote Server Files
Option Explicit
' // This method draw figure on form
Public Function Draw( _
ByVal frmForm As Object, _
ByVal x As Long, _
ByVal y As Long, _
ByVal width As Long, _
ByVal height As Long, _
ByVal color As Long) As Long
End Function
' // This method play a sound contained in dll
Public Sub Play()
End Sub
Ok. Now you should compile it and then VB6 create in output folder type library with your interface.
Next step is plugin. Now you can create in singe dll many of plugins. For example two class with implementation of IPluginInterface:
vb Code:
' // This plugin will be draw a image and play "gun sound"
Option Explicit
Private Declare Function sndPlaySound Lib "WINMM.DLL" _
Alias "sndPlaySoundA" ( _
ByRef lpszSoundName As Any, _
ByVal uFlags As Long) As Long
Private Const SND_ASYNC As Long = &H1
Private Const SND_MEMORY As Long = &H4
' // Implements main interface
Implements IPluginInterface
Dim Data() As Byte
' // Implements Draw method
Private Function IPluginInterface_Draw( _
ByVal frmForm As Object, _
ByVal x As Long, _
ByVal y As Long, _
ByVal width As Long, _
ByVal height As Long, _
ByVal color As Long) As Long
Dim frm As Form
Set frm = frmForm
frm.PaintPicture LoadResPicture(101, vbResBitmap), x, y, width, height
End Function
' // Implements Play method
Private Sub IPluginInterface_Play()
Data = LoadResData("GUN", "CUSTOM")
sndPlaySound ByVal 0, SND_ASYNC
sndPlaySound Data(0), SND_ASYNC Or SND_MEMORY
End Sub
vb Code:
' // This plugin will be draw a rectangle and play "barking dog"
Option Explicit
Private Declare Function sndPlaySound Lib "WINMM.DLL" _
Alias "sndPlaySoundA" ( _
ByRef lpszSoundName As Any, _
ByVal uFlags As Long) As Long
Private Const SND_ASYNC As Long = &H1
Private Const SND_MEMORY As Long = &H4
' // Implements main interface
Implements IPluginInterface
Dim Data() As Byte
' // Implements Draw method
Private Function IPluginInterface_Draw( _
ByVal frmForm As Object, _
ByVal x As Long, _
ByVal y As Long, _
ByVal width As Long, _
ByVal height As Long, _
ByVal color As Long) As Long
Dim frm As Form
Set frm = frmForm
frm.Line (x, y)-Step(width, height), color, B
End Function
' // Implements Play method
Private Sub IPluginInterface_Play()
Data = LoadResData("BARK", "CUSTOM")
sndPlaySound ByVal 0, SND_ASYNC
sndPlaySound Data(0), SND_ASYNC Or SND_MEMORY
End Sub
Ok and create other dll with single class (just that check working of host):
vb Code:
' // This plugin will be draw a circle and play "meow"
Option Explicit
Private Declare Function sndPlaySound Lib "WINMM.DLL" _
Alias "sndPlaySoundA" ( _
ByRef lpszSoundName As Any, _
ByVal uFlags As Long) As Long
Private Const SND_ASYNC As Long = &H1
Private Const SND_MEMORY As Long = &H4
' // Implements main interface
Implements IPluginInterface
Dim Data() As Byte
' // Implements Draw method
Private Function IPluginInterface_Draw( _
ByVal frmForm As Object, _
ByVal x As Long, _
ByVal y As Long, _
ByVal width As Long, _
ByVal height As Long, _
ByVal color As Long) As Long
Dim frm As Form
Dim max As Long
Set frm = frmForm
If width > height Then max = width Else max = height
frm.Circle (x + width / 2, y + height / 2), max / 2, color, , , height / width
End Function
' // Implements Play method
Private Sub IPluginInterface_Play()
Data = LoadResData("MEOW", "CUSTOM")
sndPlaySound ByVal 0, SND_ASYNC
sndPlaySound Data(0), SND_ASYNC Or SND_MEMORY
End Sub
Ok. Now you have two dll with three plugins. Now you must write host-application (i use my module for work with unregister DLL):
vb Code:
Option Explicit
' // List of interfaces
Dim paths() As String
Dim plugins() As IPluginInterface
Dim plugCount As Long
' // Load all plugins
Private Sub LoadPlugins()
Dim fso As FileSystemObject
Dim fld As Folder
Set fso = New FileSystemObject
lstPlugins.Clear
' Scan plugins
Scan_ fso.GetFolder(App.path)
End Sub
' // Scan folder (also scan sub-folders) and loading plugins
Private Sub Scan_(fld As Folder)
Dim subFld As Folder
Dim fle As File
Dim index As Long
' Check all files in folder
For Each fle In fld.Files()
' Get extension pos in name
index = InStrRev(fle.Name, ".")
If index Then
' If extension is "dll"
If StrComp(Mid$(fle.Name, index + 1), "dll", vbTextCompare) = 0 Then
' Try load plugins
Dim tmpObj As IPluginInterface
Dim clsid() As GUID
Dim names() As String
Dim count As Long
On Error GoTo ERROR_LOADING
count = 0
' Get all co-classes in dll (this support several plugins in one dll)
If GetAllCoclasses(fle.path, clsid(), names(), count) Then
' New error handler
On Error Resume Next
Do While count
Set tmpObj = CreateObjectEx(fle.path, clsid(count - 1))
' Object created and support IPluginInterface
If Not tmpObj Is Nothing Then
' Add it to list
ReDim Preserve plugins(plugCount)
Set plugins(plugCount) = tmpObj
' Add path
ReDim Preserve paths(plugCount)
paths(plugCount) = fle.path
' Increment counter
plugCount = plugCount + 1
' Add to list
lstPlugins.AddItem names(count - 1)
End If
count = count - 1
Loop
On Error GoTo -1
End If
ERROR_LOADING:
Set tmpObj = Nothing
End If
End If
Next
' Check sub-folders
For Each subFld In fld.SubFolders()
Scan_ subFld
Next
End Sub
' // Draw in canvas figure which dependent from plugin
Private Sub cmdDraw_Click()
' If not selected plugin exit
If lstPlugins.ListIndex = -1 Then Exit Sub
frmCanvas.Show
frmCanvas.Cls
' Call method
plugins(lstPlugins.ListIndex).Draw frmCanvas, 0, 0, frmCanvas.ScaleWidth, frmCanvas.ScaleHeight, frmCanvas.ForeColor
End Sub
' // Play sound which depended from plugin
Private Sub cmdPlay_Click()
' If not selected plugin exit
If lstPlugins.ListIndex = -1 Then Exit Sub
' Call method
plugins(lstPlugins.ListIndex).Play
End Sub
Private Sub Form_Load()
LoadPlugins
End Sub
Private Sub Form_Unload(Cancel As Integer)
Dim index As Long
' Unload all libraries
For index = 0 To plugCount - 1
Set plugins(index) = Nothing
UnloadLibrary paths(index)
Next
End Sub
I also add unloading libraries, this allow re-comple any dll without closing the host-project.
Source code.
-
May 25th, 2015, 06:12 PM
#23
Thread Starter
Hyperactive Member
Re: Plugin framework without DLL registering
Thank you very much! I'll play with it tomorrow.
-
May 25th, 2015, 06:36 PM
#24
Re: Plugin framework without DLL registering
Originally Posted by MikiSoft
I have one question about the last function: Is possible to create object right after registration from memory without unloading and loading it again (using Unload = False)?
LoadLibrary once load library, others calls don't loading library it only increment counter of using. If you call FreeLibrary then it decrement counter, and if counter equals zero then library unloading.
-
May 25th, 2015, 10:19 PM
#25
Re: Plugin framework without DLL registering
Originally Posted by MikiSoft
I've combined DirectCOM with an example from this article, but it doesn't work with COM DLL examples created in other languages (C++, Java...). Where I'm wrong?
First, DirectCOM.dll can only create instances from those COM-Dlls regfree,
which have the TypeLib "already compiled in".
This is true for all VB6-created ActiveX-Dlls - and in most cases true for any
MS-COM-Dlls (which are available also e.g. in the VBA and VBScript-World,
as e.g. the Scripting.FSO, or the XML, or HTTP-HelperTools from MS...).
The concrete C++-Dll in question (as Trick already pointed out), has an *internal*
dependency to certain registry-entries - DirectCOM.dll cannot resolve those.
Also (in case of other languages, which can produce "non-COM-dlls" much more
easy than COM-Dlls) - I'd perhaps simply define a different Plugin-Interface which
relies on Flat-Calls - and describes itself in a *.h-File.
Anyways, for VB6 the COM-based interfaces work quite nicely - and since the
VB6-native-Compiler produces code which is still competitive in many areas,
I'd guess that plugin-contributions out of the VB6-corner are more likely.
Just uploaded a small Demo into the CodeBank (the other example you linked to,
is quite an "over-engineered-mess", really).
http://www.vbforums.com/showthread.p...-per-DirectCOM
Olaf
-
May 25th, 2015, 11:10 PM
#26
Re: Plugin framework without DLL registering
There is also an officially sanctioned way to do this based on reg-free assembly isolation manifests by using the Microsoft.Windows.ActCtx object.
This has several issues though. For one thing VB6 did not come with the tooling to support this and Microsoft neglected to update VB6 for this even though the feature was specifically designed for VB6 DLLs! For another the necessary library did not ship until Windows Server 2003 even though it could be redistributed to Windows XP 3 (and probably SP2)... but with XP dead the redist downloads are no longer available.
So it is really a Vista-and-later feature (tested on Vista SP2, Windows 7 SP1, Windows Home Server 2011 SP1) and you need a manifest generating utility. You can use Microsoft's MT.EXE tool (from Vista and later Windows SDKs and recent versions of Visual Studio) but it is a little "dense" about ActiveX DLLs and leaves things such as the ThreadingModel and ProgId out of the manifest, so you have to hand-edit those in after generating it. Third party manifest makers might be a better bet, but I won't recommend one since there is no clear winner here.
But within those limitations you can use VB6 ActiveX DLLs as "plugins" with nothing registered for runtime use. No funky 3rd party DLLs required at all.
The bonus is that you can create completely portable VB6 applications that use "plugin" DLLs - ones that never require the end user to have admin rights at all and never touch the registry. These can be "XCopy installed" or run from USB flash drives, etc.
But as I said, the user must be on a supported OS, not Windows XP or anything older.
-
May 26th, 2015, 04:05 AM
#27
Re: Plugin framework without DLL registering
Originally Posted by dilettante
The bonus is that you can create completely portable VB6 applications that use "plugin" DLLs - ones that never require the end user to have admin rights at all and never touch the registry. These can be "XCopy installed" or run from USB flash drives, etc.
Well, the same holds true also for Applications which avoid any prior manifest-fiddling -
and just use DirectCOM.dll.
The Demo I've posted into the Codebank, will run without touching the registry -
and would be XCopy-deployable (including the Plugins-Folder) from Win98 onwards.
Originally Posted by dilettante
But as I said, the user must be on a supported OS, not Windows XP or anything older.
As said, DirectCOM.dll will work from Win98 onwards - and one can avoid special
Manifest-creation, at the "cost" of "copying the Declaration of a simple API-call"
(GetInstance or GetInstanceEx).
I also don't see at the moment, how a Manifest-based solution would solve the
"recognition and loading of a new Plugin.dll" at runtime, which is absolutely no
problem with DirectCOM.
Next thing is VBA-based Solutions or -Addins (which run in the context of an Office-
Application) - Manifest-based regfree loading is not possible here - again no problem
for DirectCOM.dll.
Really can't understand your stance with regards to "proven tools, developed and
maintained by fellow community-members" (waving around the "big bad 3rd-party-
dependency"-baton) - and then recommending a 3rd-party dependency from MS
(a vendor you seem to trust more) as an alternative which is not usable on all platforms,
and less flexible.
Olaf
-
May 26th, 2015, 04:47 AM
#28
Thread Starter
Hyperactive Member
Re: Plugin framework without DLL registering
Thank you, Olaf! I can finally mark this thread as resolved.
Last edited by MikiSoft; May 26th, 2015 at 04:51 AM.
-
May 26th, 2015, 09:56 AM
#29
Re: [RESOLVED] Plugin framework without DLL registering
MikiSoft, my module is not working? You seen my example?
-
May 26th, 2015, 10:04 AM
#30
Thread Starter
Hyperactive Member
Re: [RESOLVED] Plugin framework without DLL registering
Originally Posted by The trick
MikiSoft, my module is not working? You seen my example?
Of course that it works, and I forgot to say that I've chosen your approach since it doesn't require additional DLL. But I've waited for the Olaf's response because I've mentioned him and his DirectCOM in the first posts here.
-
May 26th, 2015, 04:58 PM
#31
Re: Plugin framework without DLL registering
Originally Posted by Schmidt
I also don't see at the moment, how a Manifest-based solution would solve the "recognition and loading of a new Plugin.dll" at runtime, which is absolutely no problem with DirectCOM.
Normally you have something like a "plugins" folder and your application would look there for DLLs. You can certainly do this with assembly manifests as well.
Originally Posted by Schmidt
Next thing is VBA-based Solutions or -Addins (which run in the context of an Office-Application) - Manifest-based regfree loading is not possible here - again no problem for DirectCOM.dll.
I'm not sure how we got onto Office VBA here, or why anyone here would care. But once again this is perfectly possible using assembly manifests.
Originally Posted by Schmidt
Really can't understand your stance with regards to "proven tools, developed and maintained by fellow community-members" (waving around the "big bad 3rd-party-dependency"-baton) - and then recommending a 3rd-party dependency from MS (a vendor you seem to trust more) as an alternative which is not usable on all platforms, and less flexible.
I'm not a fan of undocumented binary libraries with convoluted pseudo-open source or no source at all. Doesn't mean I won't use them when no alternatives exist though.
Microsoft is not a "3rd party" so I guess this must be a language barrier issue. I was suggesting use of a tool that ships as part of Windows on all supported releases. I clearly stated that for unsupported and unsafe OSs like Windows XP there are issues, and earlier than that it isn't an option at all.
What I don't understand is your rejection of documented and fully supported proven alternatives that ship with Windows. Aren't alternatives and choice good things?
-
May 27th, 2015, 03:04 AM
#32
Re: Plugin framework without DLL registering
Originally Posted by dilettante
Normally you have something like a "plugins" folder and your application would look there for DLLs.
You can certainly do this with assembly manifests as well.
A link to a working example would've been fine - and what I meant with "at Runtime" was,
when you start with Plugin1.dll and Plugin2.dll and then Download Plugin3.dll at runtime
into your Plugins-Folder - how would that work out with a Manifest-based solution?
Also for that latter case (dynamic loading of any COM-Dll in the FileSystem)
a link to a working example would be fine.
Originally Posted by dilettante
I'm not a fan of undocumented binary libraries with convoluted pseudo-open source or no source at all.
Doesn't mean I won't use them when no alternatives exist though.
As for "undocumented" ... the GetInstance (or GetInstanceEx) is just a single call
(quite similar to CreateObject - only working regfree) - not much to "document" there -
especially not, since I gave a fully working App-example, which can load Plugins dynamically at
runtime, already in the CodeBank:
http://www.vbforums.com/showthread.p...-per-DirectCOM
Now I'd really like to see the Manifest-based equivalent to that, which will not
choke on further Plugin-Dlls, as they might come in from different Authors.
Originally Posted by dilettante
Microsoft is not a "3rd party" so I guess this must be a language barrier issue.
I guess that's true, because the first party is always *you* as the vendor of a product,
the second party is *your* customer - and 3rd-party is "everyone else" (in this case MS).
http://en.wikipedia.org/wiki/Third-party_source
Originally Posted by dilettante
I was suggesting use of a tool that ships as part of Windows on all supported releases.
What I don't understand is your rejection of documented and fully supported proven alternatives that ship with Windows. Aren't alternatives and choice good things?
I'm not a "militant rejecter" of what comes on a given Win-Installation, but what you offered so far
is only hot air (solution-wise) - incorporating a manifest-based approach for *dynamic* loading
of COM-based Plugin-Dlls would involve the creation of manifests for those (yet unknown) Dlls -
and that can get (opposed to simply specifying a Dll-Filename and ClassName) quite "convoluted"
(in the context of a portable App), as I see it - but as said, feel free to prove me wrong.
Olaf
-
May 27th, 2015, 08:09 AM
#33
Re: [RESOLVED] Plugin framework without DLL registering
Ok, take a look at the quicky I put together and posted as Reg-Free COM at runtime via Microsoft.Windows.ActCtx. Seems to work well enough here, tested on several Vista and later machines just fine.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|