Results 1 to 17 of 17

Thread: Application deployment with vbRichClient dependencies

  1. #1

    Thread Starter
    Fanatic Member
    Join Date
    Sep 2010
    Location
    Italy
    Posts
    678

    Question 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

  2. #2

    Thread Starter
    Fanatic Member
    Join Date
    Sep 2010
    Location
    Italy
    Posts
    678

    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

  3. #3
    PowerPoster
    Join Date
    Feb 2006
    Posts
    24,482

    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.

  4. #4
    Hyperactive Member
    Join Date
    Jul 2013
    Posts
    400

    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

  5. #5
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    19,541

    Re: Application deployment with vbRichClient dependencies

    Quote Originally Posted by Carlos Rocha View Post
    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.
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  6. #6
    PowerPoster
    Join Date
    Feb 2006
    Posts
    24,482

    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.

  7. #7
    Hyperactive Member
    Join Date
    Jul 2013
    Posts
    400

    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.

  8. #8
    PowerPoster
    Join Date
    Feb 2006
    Posts
    24,482

    Re: Application deployment with vbRichClient dependencies

    Quote Originally Posted by Carlos Rocha View Post
    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.

  9. #9
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Location
    Sofia, Bulgaria
    Posts
    5,120

    Re: Application deployment with vbRichClient dependencies

    Quote Originally Posted by LaVolpe View Post
    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>

  10. #10
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    Re: Application deployment with vbRichClient dependencies

    Quote Originally Posted by reexre View Post
    The above (regfree usage) is the recommended way, to do deployments, based on the RC5.

    Quote Originally Posted by reexre View Post
    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

  11. #11
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    Re: Application deployment with vbRichClient dependencies

    Quote Originally Posted by dilettante View Post
    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

  12. #12
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    Re: Application deployment with vbRichClient dependencies

    Quote Originally Posted by Carlos Rocha View Post
    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

  13. #13
    Hyperactive Member
    Join Date
    Jul 2013
    Posts
    400

    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

  14. #14
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    Re: Application deployment with vbRichClient dependencies

    Quote Originally Posted by Carlos Rocha View Post
    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

  15. #15

    Thread Starter
    Fanatic Member
    Join Date
    Sep 2010
    Location
    Italy
    Posts
    678

    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....

  16. #16
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    Re: Application deployment with vbRichClient dependencies

    Quote Originally Posted by reexre View Post
    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).

    Quote Originally Posted by reexre View Post
    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".

    Quote Originally Posted by reexre View Post
    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.

    Quote Originally Posted by reexre View Post
    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

  17. #17

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width