-
Feb 25th, 2015, 05:35 PM
#1
Application deployment with vbRichClient dependencies
hi
I'm asking help about deployment of application which uses vbRichClient Dll.
I'm quite ignorant about that.
I used Inno-installer
[1]
To include vbRichClient the following Inno script lines are used:
Code:
Source: "..\vbRC5BaseDlls\*"; DestDir: "{app}\vbRC5BaseDlls"; Flags: ignoreversion recursesubdirs
; Register DLL
Source: "..\vbRC5BaseDlls\vbRichClient5.dll"; DestDir: "{app}\vbRC5BaseDlls\"; Flags: restartreplace ignoreversion regserver
First line copy all files needed in the vbRC5BaseDlls Folder to application\vbRC5BaseDlls Folder
Second line (copy and ) Register vbRichClient5.dll
OK this works.
But if I have 2 or more applications that uses vbRichClient,
after I uninstall one of them
Runtime Error 429
ActiveX Component Can't Create Object
occurs when I run another App that uses vbRichClient.
Supposedly the uninstallation of one App, unregister vbRichClient5.Dll, and so the other one launch the Error.
So How can I solve this problem ?
--------------------------------------------------------------
[2]
I thought about using
VB6 Regfree-Usage of your own VB- and other COM-Dlls per DirectCOM
and I succeeded.
but it's more complicated to write the vbRichClient VB6 code...
and it seems impossible to me to use constants such as (EG)
Code:
CC.SetLineCap CAIRO_LINE_CAP_ROUND
CC.Antialias = CAIRO_ANTIALIAS_SUBPIXEL
These are almost 2 separable questions
Sorry for my english
Thanks
-
Feb 26th, 2015, 01:52 PM
#2
Re: Application deployment with vbRichClient dependencies
I resolved (question 1)
changing the InnoSetup Lines so:
Source: "..\vbRC5BaseDlls\*"; DestDir: "{app}\..\SUPPORT\vbRC5BaseDlls"; Flags: ignoreversion uninsneveruninstall recursesubdirs
Source: "..\vbRC5BaseDlls\vbRichClient5.dll"; DestDir: "{app}\..\SUPPORT\vbRC5BaseDlls\"; Flags: restartreplace uninsneveruninstall ignoreversion regserver
So for each Application there's only one vbRichClient.dll placed in ..\SUPPORT\vbRC5BaseDlls\
and when uninistall one App, vbRichClient will not be uninstalled
-
Feb 26th, 2015, 02:32 PM
#3
Re: Application deployment with vbRichClient dependencies
Your main problem is using No-no-setup, a notoriously easy way to wreak DLL Hell on your applications as well as others. It just isn't smart enough to use proper deployment rules such as managing usage counts.
Your second problem is this whole "vbRichClient" thing itself. It does not come with a proper developer install package, lacks .DEP files, offers no Installer merge module, or much of anything else one would expect from a suite of component libraries. And I hesitate to imagine the versioning problems it may have with itself as it mutates over time.
Both of these require extreme care and can lead to fragile applications - when they don't break totally unrelated applications. Inno itself should be trapped by antimalware tools, but sadly we probably can't expect that any time soon.
-
Feb 26th, 2015, 03:36 PM
#4
Hyperactive Member
Re: Application deployment with vbRichClient dependencies
@Dilettante, sometimes you sound reasonable, warned, skilled, helpful, nice, and sometimes...
@reexre, Side by Side is the way to go, and not only in this case. There's a member of this forum who made a tool (cool, free, and M$ independent, like inno setup), named UMMM (Unnatended Make My Manifest). I'm just starting to use it, but it seems to work very well. My advice is to use this approach from now on.
https://github.com/wqweto/UMMM
-
Feb 26th, 2015, 04:11 PM
#5
Re: Application deployment with vbRichClient dependencies
Originally Posted by Carlos Rocha
I'm just starting to use it, but it seems to work very well. My advice is to use this approach from now on.
Appears to be a nice wrapper for mt.exe while adding other options. Will be worth playing with and VB source is a plus.
-
Feb 26th, 2015, 04:34 PM
#6
Re: Application deployment with vbRichClient dependencies
To be fair to Schmidt, he probably has advice for dealing with all of the concerns I raised regarding vbRichClient deployment and versioning. I just haven't seen anything besides some minimalist hints at Downloads that don't seem detailed enough. My concerns have to do with target PCs that may over time encounter more than one application that uses these libraries, and possibly multiple versions of them.
-
Feb 26th, 2015, 04:55 PM
#7
Hyperactive Member
Re: Application deployment with vbRichClient dependencies
Well, the "package" includes a way to use it registerless. My doubts are about the way is uses reg-free instantiation (LoadLibrary). A long time ago, in DOS time, I learned that a library could only be loaded once, and any attempt to use it after that would use the loaded one. Don't know if it's still true - maybe someone can enlighten me.
-
Feb 26th, 2015, 05:02 PM
#8
Re: Application deployment with vbRichClient dependencies
Originally Posted by Carlos Rocha
Well, the "package" includes a way to use it registerless.
Then perhaps that's the safe way to go, with every application having its own copies of the libraries with no registry entries and thus no collisions to worry about.
-
Feb 27th, 2015, 04:01 PM
#9
Re: Application deployment with vbRichClient dependencies
Originally Posted by LaVolpe
Appears to be a nice wrapper for mt.exe while adding other options. Will be worth playing with and VB source is a plus.
And I'm accepting PRs if you find bugs/impl new features :-))
cheers,
</wqw>
-
Mar 1st, 2015, 06:12 PM
#10
Re: Application deployment with vbRichClient dependencies
Originally Posted by reexre
The above (regfree usage) is the recommended way, to do deployments, based on the RC5.
Originally Posted by reexre
but it's more complicated to write the vbRichClient VB6 code...
and it seems impossible to me to use constants such as (EG)
Code:
CC.SetLineCap CAIRO_LINE_CAP_ROUND
CC.Antialias = CAIRO_ANTIALIAS_SUBPIXEL
Regfree-instantiation per DirectCOM.dll (e.g. using the little generic module: modRegfreeDlls.bas
from the above Link) does not require you to work LateBound in your Project.
E.g. on your Developer-machine you can include a Project-reference to vbRichClient5 within your
own VB-Project(s) (the ones, you later plan to ship "regfree") - then develop using intellisense and
everything - then just compile your Application - and test out your XCopy-deployment-package
in a "virginal VM" (which doesn't have any registered RC5-libraries) - and it will work.
The VB-Compiler will compile the (needed for early-binding) RC5-Typelib-Infos directly into your
own VB6-binary as well... so there's absolutely no need to punish yourself and work LateBound.
The only thing you need to take care of is, that the \MyApp\Bin\-folder of your XCopy-package
does contain the *same* 3 RC5-Dlls, which you had registered in a single place on your Dev-Machine
(e.g. in C:\RC5\...) - at the time of compilation of your project.
Minimum-Bootstrapping-Code for full earlybound RC5-usage in a regfree deployed project:
(assuming modRegfreeDlls.bas is contained in the Project, and a "\Bin\-folder is in place):
Code:
Option Explicit
Public New_c As cConstructor, Cairo As cCairo '<- global defs of the two Main-"EntryPoints" into the RC5
Sub Main()
'with the modRegfreeDlls.bas in place, we can do regfree instancing conveniently per:
Set New_c = GetInstanceFromBinFolder("vbRichClient5", "cConstructor", "Bin")
'the second Construction-Helper for all the graphics-objects is then already conveniently createable per:
Set Cairo = New_c.Cairo
'... add resources and perform your other inits, before firing up your first Form
End Sub
The above two global Vars (New_c and Cairo) are the ones, which any RC5-based examples in the
code-bank build-upon - and when they are created per regfree instantiation as above - then
any RC5-demo can be made XCopy-deployable (without any manifest-fiddling) quite easily.
Also take note, that the Controls which are available in the vbWidgets-Project (vbWidgets.dll)
can be easily created regfree as well (e.g. per: GetInstanceFromBinFolder("vbWidgets", "cwTextBox", "Bin") -
just ensure that your own, latest compile of vbWidgets.dll is included in your Bin-Folder as well
(alongside the other 3 RC5-Dlls).
Just ask, when something is still unclear.
Olaf
-
Mar 1st, 2015, 07:10 PM
#11
Re: Application deployment with vbRichClient dependencies
Originally Posted by dilettante
Your second problem is this whole "vbRichClient" thing itself. It does not come with a proper developer install package, lacks .DEP files, offers no Installer merge module, or much of anything else one would expect from a suite of component libraries.
vbRichClient is not a "suite of component libraries" - it's a Class-Framework in a single COMponent-library
(having only 2 "non-COM"-StdDll-dependencies, vb_cairo_sqlite.dll and DirectCOM.dll).
Registering a single COM-lib on ones own Developer-machine should not be that hard for a VB6-dev. -
and deployment is meant to be in regfree mode, which worked (and works) reliable from Win98 to Win10.
Olaf
-
Mar 1st, 2015, 07:19 PM
#12
Re: Application deployment with vbRichClient dependencies
Originally Posted by Carlos Rocha
Well, the "package" includes a way to use it registerless. My doubts are about the way is uses reg-free instantiation (LoadLibrary). A long time ago, in DOS time, I learned that a library could only be loaded once, and any attempt to use it after that would use the loaded one. Don't know if it's still true - maybe someone can enlighten me.
LoadLibrary, when used with an explicit (full) path to your own Binary, will load exactly this Binary into the Process
(and when the same full path is specified again, then of course the already loaded module will be used "from memory").
That means, that the DirectCOM-based Regfree-mechanism could also be used, to load slightly different
versions of the same COM-binary, e.g. when placed in appropriate version-folders as:
\MyApp\
......\Bin\
............\V1\
..................MyCOM.dll
............\V2\
..................MyCOM.dll
That way one can e.g. realize Auto-Updates of a certain Application at Runtime -
without the need for a shutdown/reload of the hosting Application-Process.
Olaf
-
Mar 1st, 2015, 07:52 PM
#13
Hyperactive Member
Re: Application deployment with vbRichClient dependencies
Interesting, thanks.
As I need manifests for OCXs, is there any advantage to start using DirectCOM (apart from the pointed versioning facility)?
Carlos
-
Mar 2nd, 2015, 05:06 AM
#14
Re: Application deployment with vbRichClient dependencies
Originally Posted by Carlos Rocha
Interesting, thanks.
As I need manifests for OCXs, is there any advantage to start using DirectCOM (apart from the pointed versioning facility)?
No. Tough in case these somewhat greater degrees of freedom are needed -
DirectCOM-based instancing also works in combination with a "manifested" solution
(there's no "either ... or"-restriction).
Olaf
-
Mar 3rd, 2015, 02:33 PM
#15
Re: Application deployment with vbRichClient dependencies
@ Schmidt
Just ask, when something is still unclear.
Thank you!
So, in few words, I can write code and create the EXE without removing reference to vbRichClient5 DLL (whereever it is located on my machine)
Just have to put this code:
Code:
Option Explicit
Public New_c As cConstructor, Cairo As cCairo '<- global defs of the two Main-"EntryPoints" into the RC5
Sub Main()
'with the modRegfreeDlls.bas in place, we can do regfree instancing conveniently per:
Set New_c = GetInstanceFromBinFolder("vbRichClient5", "cConstructor", "Bin")
'the second Construction-Helper for all the graphics-objects is then already conveniently createable per:
Set Cairo = New_c.Cairo
'... add resources and perform your other inits, before firing up your first Form
End Sub
and
assuming modRegfreeDlls.bas is contained in the Project, and a "\Bin\-folder is in place
and at Launching the program, "it will automatically locate the vbRichClicent DLL in BIN folder, and use it"
so no need to regsrv32 registration...
Right ?
So when I create the Deployment package I can simply Put things so
...MyAPP ---> the EXE
...MyAPP\BIN ---> the main 3 vbrichclient DLLs
without any registration.
I hope I have understand....
-
Mar 4th, 2015, 06:08 AM
#16
Re: Application deployment with vbRichClient dependencies
Originally Posted by reexre
So, in few words, I can write code and create the EXE without removing reference to vbRichClient5 DLL (whereever it is located on my machine)
Yes - the project-reference will simply ensure, that the needed RC5-interfaces are compiled
into your own Executable (provided from the RC5-Binary, which the registry-entry points to).
Just ensure, that later on (when you assign an instantiated Object to a certain ClassType),
that there's no mismatch...
...and as said, usually that is the case, when the Binary these compiled-in Interfaces came from
(at compile-time, this is from the registered version of the RC5 on your Dev-machine)...
are matching with the interfaces from the other Binary, you later create your instance(s) from
(that's the Binaries you ship within your MyApp\Bin-Folder).
Originally Posted by reexre
and at Launching the program, "it will automatically locate the vbRichClicent DLL in BIN folder, and use it"
Well, "automatically" is a bit too strong - to be precise, it is the function GetInstanceFromBinFolder(),
which ensures the regfree loading/instancing of the global Variable New_c As cConstructor:
Code:
Set New_c = GetInstanceFromBinFolder("vbRichClient5", "cConstructor", "Bin")
I'd recommend, to step through this point-of-code per F8, to understand, how
the Path-resolution works - and how the New_c-Variable is finally "filled".
Originally Posted by reexre
so no need to regsrv32 registration...
Right ?
Yes, provided that the only COM-dependency in your project is the one to the RC5,
you are usually done, as soon as you created the New_c constructor-variable regfree.
(if you have more - e.g. your own COM-Dlls in your Bin-Folder, you will need appropr. calls
to GetInstanceFromBinFolder of course, to draw instances from those other Dlls as well).
The New_c constructor is just a convenient entry-object you can derive any other RC5-ClassInstance from.
Other COM-Dlls usually don't offer such a constructor-HelperObject - meaning that for other COM-Dlls
you'd have to use GetInstanceFromBinFolder() more often, to draw class-instances from them regfree.
But yes - basically the only thing you need to take care of is, that New_c is created regfree -
and that's it then - as long as you ensure, that any other RC5-ClassInstance is created per New_c.
Originally Posted by reexre
So when I create the Deployment package I can simply Put things so
...MyAPP ---> the EXE
...MyAPP\BIN ---> the main 3 vbrichclient DLLs
without any registration.
Yes - as long as those Exes have internally in addition:
- Sub Main as their entry-point
- Within Sub Main ensured, that a global Instance of New_c (and Cairo) is created regfree
- within your whole App new RC5-instances are created only over New_c (or Cairo).
Olaf
-
Mar 4th, 2015, 03:35 PM
#17
Re: Application deployment with vbRichClient dependencies
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
|