Why dir path is hard coded in the generated dll?

[hujirong]

Hi

I am a build engineer of some VB6 and MSVS VB applications. I notice the directory path (the location of source code, e.g. c:\build_views\v70r3\ ....) information is stored in the generated dll, exe.

This gives us a lot trouble, because I can't use another path to build the dlls, otherwise the binary compare tool will say the dlls are different, due to embeded path info is different.

We have parallel development, and the code has to be built in different machines, different paths. Is there a way to resolve this?

Thanks
Jirong

 

[HughLerwill]

>the binary compare tool will say the dlls are different

Only if the user interface to the dll being produced does not match that of the reference version of the dll. Providing the user interface stays constant the 'internals' of the dll's procedures can change without breaking binary compatibility.

It seems hard to imagine how a hard coded path could get mixed up into a procedure definition except in something pretty awful like;

Public Sub DoSomething(Arg as Long, optional Arg2 as String = "C:\MyFolder")

Have you checked that the same reference dll (or same version copy) is being used when you compile the dll from the various paths?

 

[dilettante]

I'd assume the OP is using some config management tools that are naive about Windows development. Probably something from the open sores world.

My guess is the utility in question is trying to do a byte by byte comparison of files rather than examining COM interface information. It is looking for any difference at all, rather than a compatibility break.

This seems doomed to failure. For all I know there are embedded compilation timestamps, and even if not slightly different compilers (hot fixes, service packs) and linkers won't create identical PE file outputs from the very same source.

 

[hujirong]

Please look into attached image, and you'll know immediately.

The path in green is where the build picks up the source code. We don't want this information embeded inside the dll. It's a release version, somehow got debug information inside? How can we get rid of it?

Below is the code we run the build from Perl:

$cmd = "devenv tacmain.sln /Clean Release;
$retcode = Execute($cmd);
$cmd = "devenv tacmain.sln /Build Release;

Thanks
Jirong