Distibute an EXE without OCX issues

Hello,
I have been having a serious issue for 2 days now. I have an OCX that works perfectly fine on my project but users are complaining of not been able to use software because of "Active X Registration" issues when the form is launched.
Is there a way to have an OCX in a project, compile the software and yet distribute it to the users without having to register the OCX on each of the users systems ?
I want them to run the EXE and not have to do anything else and yet the component should work as fine as it should.

An ActiveX needs to be registered on a computer before it can be used.
Nowadays SxS is used often.
Read this for a start:
https://www.vbforums.com/showthread....ial-Any-Takers

The obvious course is to use either the legacy Package and Deployment Wizard or else Windows Installer based Visual Studio 6.0 Installer 1.1 which largely replaced the PDW in 1999. There are also 3rd party tools for creating legacy scripted setup packages and Windows Installer databases (MSI packages).


People often use the term "side by side" when they are really referring to using Window Fusion Activation Contexts (ActCtx) to redirect bindings to COM servers and typelibs. This is a different function of Fusion from SxS assemblies. There is a lot of cargo-culting around this because so few studied the documentation released back in the early years of Windows XP. There is no standard tooling for creating Fusion manifests for VB6 programs. This is now a murky topic that has devolved into lore in the twilight years of VB6.

Wikipedia has a lot of hilariously incorrect information about it.

The generic terminology is "isolated applications and private assemblies"

Just tell us which OCX you are bundling and what it does and perhaps there is an alternative route to get what you want.

I don't have a lot of dependencies, but have about 6
I create a project, which includes the controls, and has no code.
I use the P&D Wizard to create an EXE, and get the user to run it once.
If I then create any EXE's (which have source code), I just make the EXE, and give it to the user.
They do not install those, they just place it into say C:\ClipBuddy\ folder, and it just runs.
They can go for 100 years without running any installers.

That's quite an interesting approach.

It also creates a mess and violates the VB6 license agreement.

Quote:

---

..
If I then create any EXE's (which have source code), I just make the EXE, and give it to the user.
They do not install those, they just place it into say C:\ClipBuddy\ folder, and it just runs.
They can go for 100 years without running any installers.

---

I have the same.
I have created a setup package (MSI) for only the OCX and DLLs.
The (updates of the) application is delivered as a ZIP archive and can be placed wherever the customers like.

Quote:

---

Originally Posted by dilettante

It also creates a mess and violates the VB6 license agreement.

---

Huh??
Why is this against the VB6 license???

There is a requirement that a program using any of the supplied controls "add sufficient functionality" to them. This was added to discourage people making thin wrapper OCXs to get around licensing requirements to use MSComm, etc. in VBA.

So you can create a mini-installer with an OK button and some text, perhaps a logo image and something that displays system and version information. You are done!

You could, but that would be piracy.

You may as well be using CPoorServer.

Well, you'd be adding "sufficient functionality"... a slider, a control or two and some tests for OCX versions, you'd have a tool that provided sufficient functionality.

Quote:

---

Originally Posted by dilettante

There is a requirement that a program using any of the supplied controls "add sufficient functionality" to them. This was added to discourage people making thin wrapper OCXs to get around licensing requirements to use MSComm, etc. in VBA.

---

I understand why the "add sufficient functionality" requirement would prevent people distributing wrappers around OCXs that require licensing, but it doesn't make sense that it would apply to distributing the OCXs that your projects use - properly licensed of course - without a wrapper to expose their functionality to unlicensed developers. What's the difference between delivering a single installer with an EXE + OCXs, vs. distributing an installer with just the OCXs (no wrappers, no .lic files, no circumvention of the license to provide access to the OCXs functionality to other developers) and a separate .EXE file that users can save/run from wherever they like? Back in the day you'd see this done fairly often because download times were so long - a large "one-time" prerequisites installer with all of the main app dependencies, and a separate and much smaller application installer that would be periodically updated with new features/bug fixes for re-download/installation.

@All,
Thanks so much.
I had to painstakingly decode all the bugs encountered when i added User Control directly into my code. It worked eventually and i was about to build .EXE and distribute without user having to install anything again.
It was tough but the best way to go about it.

Quote:

---

Originally Posted by Tobyy

....
I want them to run the EXE and not have to do anything else and yet the component should work as fine as it should.

---

...well, I use EnigmaVB (VirtualBox) for this. It's free and just works. And has the additional benefit which of any additional files and whatnot you want to expose to the user.

Super easy! (up to now I don't know of any downsides?)