Results 1 to 10 of 10

Thread: Do the *.ocx file need to be registered while deploying to other system.

  1. #1

    Thread Starter
    Lively Member
    Join Date
    Sep 2017
    Posts
    79

    Do the *.ocx file need to be registered while deploying to other system.

    Hi,
    When a application built using *.ocx file then when its deployed using P&DW, does the system on which the application was installed need to be *.ocx registered ?

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

    Re: Do the *.ocx file need to be registered while deploying to other system.

    Yes, if the ocx is included in the setup.exe, then the setup should register them as needed.
    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}

  3. #3

    Thread Starter
    Lively Member
    Join Date
    Sep 2017
    Posts
    79

    Re: Do the *.ocx file need to be registered while deploying to other system.

    Hi LaVolpe,
    During installation can I change the location of the *.ocx file to application.exe directory while preparing the P&DW.

    or is it mandatory to place the *.ocx file in system32 ?

    Thank you for the helps.

  4. #4
    Fanatic Member
    Join Date
    Jan 2013
    Posts
    894

    Re: Do the *.ocx file need to be registered while deploying to other system.

    Quote Originally Posted by Urgentbody View Post
    Hi LaVolpe,
    During installation can I change the location of the *.ocx file to application.exe directory while preparing the P&DW.

    or is it mandatory to place the *.ocx file in system32 ?

    Thank you for the helps.
    If custom .OCX, EXE directory, and YES register, include if it is ActiveX.EXEs.

    If common VB6 .OCX, hmmmmmmm... I would check if it already exists, then hell, if already exists, prompt the user if he want to reemplace it, try to check if newer version, and just THEN try to overwrite it and re-register, if overwriting fails, let the user to ignore it. A hell.

    Anyway, I don't recommend to place anything to system32 or even touch it, you will gain points in AV systems.

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

    Re: Do the *.ocx file need to be registered while deploying to other system.

    ActiveX libraries are supposed to have a .DEP ("dependencies") file next to them on the developer's machine. This tells packagers like the PDW a lot of things, including where the library should be installed.

    In reality most libraries should not ever be placed into System32 except for those provided by Microsoft. Even many of those go into Program Files\Common Files\microsoft shared.

    3rd Party libraries should go into Program Files\Common Files\xxx

    One place they should never go is in the main program's directory. If a library is truly private to an application it could go into a subdirectory of that, but not the program directory.

    If a library could ever possibly be shared you don't want to put it anywhere except the shared location specified in the .DEP file. Registering such a library is "publishing" it to all programs on the computer. If you uninstall your application later and your uninstaller is dumb it may well delete the file but leave the registration in place. This can be quite a mess for other programs you have pulled the rug out from under. Not only is the library gone now, but even if a user tries to reinstall their other application that installer may see the registration and conclude it doesn't need to copy the file to the computer. This can be a real mess for users.

    If a 3rd Party library has no .DEP file you should complain to the vendor and you should really create one yourself until the vendor steps up. These .DEP files do not need to be deployed, they only have meaning on a developer PC as instructions to packagers.


    There is also a "mega-DEP" file called VB6DEP.INI which belongs to the PDW. This contains .DEP information for a lot of the libraries that shipped with VB6. It also contains an important [Do Not Redistribute] section that developers are supposed to maintain.

    It never gets updated by Service Packs, etc. because its contents vary based on the target OSs of different packages you create. To know what to add to this you have to read 20 years worth of MS KB articles.

    If you fail to do this, then you are responsible for "excluding" libraries that are no longer deployable to your target OSs every time you run the PDW. Many have become system libraries over the years, and trying to deploy them will either fail and be silently repaired by Windows or worse yet cause your installs to fail or your program (and others) to fail because of a library/OS mismatch. Lots of these libraries are now produced as tailored code to match individual versions of Windows instead of the crusty old Win9x generic versions.


    Deployment is not a trivial issue. This was one of the things that drove Microsoft to .Net and its mega-pack of libraries (.Net Framework): too many people screwed machines up through inept deployment.
    Last edited by dilettante; Nov 6th, 2017 at 07:11 AM.

  6. #6

    Thread Starter
    Lively Member
    Join Date
    Sep 2017
    Posts
    79

    Re: Do the *.ocx file need to be registered while deploying to other system.

    Very much informative, Than you.
    Ok that means if i am changing the path of the *.ocx file at the time of P&DW to the application.exe folder then also the ocx file will be registered under HKEY_LOCAL_MACHINE\SOFTWARE\CLASSES\. Correct ?

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

    Re: Do the *.ocx file need to be registered while deploying to other system.

    Yes.

    But never put such an OCX into the application folder, at least use a subfolder under that folder. And only do this for an OCX that you created to be exclusively used by your main program. Do not do it for any Microsoft or 3rd Party OCX.

  8. #8
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    9,855

    Re: Do the *.ocx file need to be registered while deploying to other system.

    One thing that didn't seem to be clearly made here is the following:

    In a certain sense (especially on 32-bit machines), it doesn't matter where the OCX file is. If it's correctly registered (and we're only talking about a compiled executable finding it), it doesn't matter where it is. When it's needed, an executable will go to the registry and find it, and use it.

    Urgentbody, in other words, putting your OCX files in the folder with your program isn't really accomplishing anything. If another application needs those OCX files, it'll reach into your program's folder and use them from there if it needs them, because that's the way you've registered them.

    If you're thinking that moving the file will cause other programs to not use these OCX files, you're wrong. And that's why you should just leave them in C:\Windows\System32.

    If you want your program to have specific/unique OCX files that nobody else touches, that's an entirely different can of worms, and is discussed in great detail in this tutorial. Basically, it teaches you how to use OCX files without registering them.

    Good Luck,
    Elroy
    Last edited by Elroy; Nov 7th, 2017 at 11:34 AM.
    Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.

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

    Re: Do the *.ocx file need to be registered while deploying to other system.

    Moving them to an arbitrary location is very bad.

    The problem is that a registered OCX is "published" to be used by any application. If you dump it into some private location instead of the location the developer of the OCX intended, your uninstaller might delete the OCX file and leave it registered.

    This breaks all other users of the OCX, and also means their installers may not even be able to successfully repair them because they check and see the registration in place. Inno Setup installers/uninstallers are notorious breaking breaking OCXs in this way, because they have no intelligence and rely on carefully hand-crafted scripts - which are often very flawed.

    All of this is less of an issue if you have created your own OCX for use only by your one application. While it is published, other programs won't be trying to use it.

    Dumping a copy into some arbitrary location does not give you a "private copy." The only safe way to have a private copy of an OCX or DLL is to use an isolated assembly activation context manifest, something the PDW cannot do for you.

  10. #10
    Fanatic Member
    Join Date
    Jan 2013
    Posts
    894

    Re: Do the *.ocx file need to be registered while deploying to other system.

    Quote Originally Posted by dilettante View Post
    Moving them to an arbitrary location is very bad.

    The problem is that a registered OCX is "published" to be used by any application. If you dump it into some private location instead of the location the developer of the OCX intended, your uninstaller might delete the OCX file and leave it registered.

    This breaks all other users of the OCX, and also means their installers may not even be able to successfully repair them because they check and see the registration in place. Inno Setup installers/uninstallers are notorious breaking breaking OCXs in this way, because they have no intelligence and rely on carefully hand-crafted scripts - which are often very flawed.

    All of this is less of an issue if you have created your own OCX for use only by your one application. While it is published, other programs won't be trying to use it.

    Dumping a copy into some arbitrary location does not give you a "private copy." The only safe way to have a private copy of an OCX or DLL is to use an isolated assembly activation context manifest, something the PDW cannot do for you.
    I replied as I replied because the Versioning hell.

    Maybe now, that all VB6 programs seems to use SP6's OCX, versioning hell does not matter now. But before, upgrade an OCX, which breaks binary compatibility, and many other VB apps starts to fail. Just because versioning hell. And before also was the war of vb5 vb vb6 versioning of some ocx.

    "publishing", the idea of publishing in VB terms, my personal opinion, was a mistake from Microsoft the whole idea. If was not obligate to publish, just dump the OCXs near the EXE and let it to work. So the procedure, find first next to the EXE, and if not found, THEN check the if "PUBLISHED" and to look some-where else. That would be just great, but not!.

    Personally I had this problem, with the famous Mswinsck, which some old games were using an old version, which didn't match with my software. So fix, the game, break my soft.

    Yes, back in 00's, were multiplayer 2D games in VB5/6.

    Later, when appeared the SP6... seems like everybody installed it. And it merged all the versioning.


    By these reasons, I dump all ocxs in my app folder, don't like to overwriting preexistent. Ofcourse, it is a problem if uninstalled, or other stil using old versions.
    Last edited by flyguille; Nov 8th, 2017 at 06:37 PM.

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