Paths in the output

[DaveInCaz]

Our build environment starts with binaries located in numerous locations. We combine various third party & custom DLLs, etc. into our installer. Once installed however, the main EXE and all DLLs live in the same directory.

UMMM will happily include DLLs from various locations using relative paths in the INI file. However it also writes out a relative path into the resulting manifest. So at least in my case that doesn't work; as noted above my app would need all the DLLs to have no relative path specified in the manifest at all.

It looks like this path is being included intentionally, on this line:

UMMM/Src/mdUmmm.bas

Line 344 in ce74cf3

cOutput.Add Printf(" <file name=""%1"">", pvPathDifference(m_sBasePath, sFile))

and changing this could break existing build processes of UMMM users.

So I am wondering what the options would be. One thought is to specify some kind of option in the INI file to instruct UMMM which style of pathing in the manifest you prefer. Maybe there are other possibilities...

I can probably contribute some code but wanted to make sure the solution made sense before attempting anything on my own.

Thanks

PS: At the moment I work around this issue by copying all our DLLs to a temporary folder and creating the manifest there. This works OK but leaves some room for error and a lot of extra maintenance of the build process. Files have to be specified in more than one place (instead of only in the UMMM INI) which leaves things open to getting out of sync.

[wqweto]

I'm wondering what is the output of your build process? This temp folder you now use just to create the manifest looks like the actual output folder of the build. At least this is how we do it at out place.

Basicly keeping dlls/ocxs next to the main executable is a poor strategy as VB6 runtime has the nasty feature to auto-register ActiveX controls that cannot be loaded from registry at runtime. Auto-registration uses LoadLibrary (or similar) to locate the ocx and this function actually succeeds locating it in main executable folder. This wrecks havoc to the client registry or (now) usually fails with mysterious errors as HKLM hive is read-only when process is not elevated.

Nevertheless best practice for VB6 reg-free deployment is to keep dependencies piled in a separate subfolder. We keep these in Support or similar just to prevent accidental auto-registration.

[DaveInCaz]

One constraint for us is the numerous third party DLLs which we incorporate. The process of creating our application installer picks them up from various paths; when the installer later runs on the target PC it deploys them, our EXE, & custom DLLs to the single target folder.

The difficulty with treating the temp folder as the formal output of the build is the need to maintain the same information in multiple places. Different build operations all need this in their own format. This presents opportunities for mistakes.

And while I like the idea of somehow consolidating all that information into one place which all build operations would rely on... so far that hasn't been practical. Hence looking into this incremental improvement of simplifying our use of UMMM.

---

Re: auto-registering issues...

This hasn't been an issue because the build environment is used only for builds. The app is never run there. Also it is within a virtual machine so if (when) it gets messed up for any reason we revert to a clean starting point.

We also do build testing in a separate VM including verifying the manifest works as intended, etc.

One step of our build initially registers things which are needed for compiling in the VB6 IDE. Then compilation itself registers our custom DLLs. (That part is coordinated using Kinook Visual Build Pro.)

[wqweto]

Auto-registration is an issue on client machines, when this portable build is deployed there is a chance that certain ocx does not get correctly manifested. In this case VB6 runtime will try to auto-register it when certain form is loaded. This will either mess up the registry on client machine or fail with access denied on HKLM.

You can try to impl a global option (or a param on Identity or other command) that replaces relative folders in file tag with a fixed output folder (which can be empty).

[wqweto]

Implemented in 77c7e07

[DaveInCaz]

@wqweto cool, I will check it out!