VisBuildPro.macros on network drive
 

I've placed the VisBuildPro.macros (and the other files) on a network drive. VBP finds them there (I added the ConfigFilesPath key in the registry) and uses it.

When I'm trying to update a global macro, the program compelets the step without failure but does not update the macro.

I've tried setting the ConfigFilesPath to \\server\folder and drive:\folder but neighter seems to do the job. Is this a problem with VBP or our network? One more thing, the folder is a hidden share!

I have write permission on the share as I can create, delete and update other files there.

Any suggestions?

System: Win2000
VBP: 5.7

What do you mean by a "hidden" share? An administrative share? I tried that (using \\server\c$\temp for ConfigFilesPath) and this worked ok:


ABC
2
%DATETIME%
1
Set Macro


If that doesn't help, please provide a little more detail on your network scenario and the VBP project involved. Thanks.

The adminstrative share is indeed the correct name.

Let me explain how we have setup our machines for using vbp.

We have 2 build machines, 1 for our daily build and development tasks and one for creating patches that should go directly into the production environment (at short notice).

The build scripts and our storage needs for generated files (except for the source code) is placed on the a network share //server/share$.

If tried using the network share for storing the configuration files of vbp by updating the registry key ConfigFilesPath.

When I do this, the global macro's still read correctly but not always stored correctly (not sure it this happens always or sometimes). If I change back to a local path, everything seems to work correctly again.

Most of the global marco's are initialized by the %read_ini% macro to be initialized.

Note, currently only one system is up and running

We haven't been able to reproduce this behavior here. If you could provide more details on your computer and network configuration, along with a simplified .bld file that reproduces the problem and we can build, we will investigate further.

I think I've finally figured this one out. At least I could reporduce the behaviour outside of our build procedure. I'm now curious to see if this has the same effect at you're location.

I've set the ConfigFilesPath in the registry to a network location \\server\sharename$ and everybody has full control. Next I open the main.bld and step trough every step.

Main will first remove 2 global macros and then call create.bld. This will create 2 global macros and initialize them with a value one with 'ABC' and the other wih '123'. This works as expected.

Next step logs these values, once again correctly. The next step should change the values of both macros, but when you examine the value of these macros in the result log you will notice that these have not changed.

As you can see from the log file the macro's value isn't changed although the change message has been logged.

... partial log file ...

_TEST_MACRO_1 = ABC
TEST_MACRO_2 = 123
Building project step 'Change global macro'...
Building project step '_TEST_MACRO_1'...
Updated Global macro '_TEST_MACRO_1'
Building project step 'TEST_MACRO_2'...
Updated Global macro 'TEST_MACRO_2'
Building project step 'Log values after'...
Building project step 'Log values A'...
AAAAAAA

_TEST_MACRO_1 = ABC
TEST_MACRO_2 = 123
...

What I noticed during this is that sometimes the global macro's tab isn't updated with the created macros (the log.bld will promt for the macro values) when stepping. When running, the problem seems to be a little bit diffrent, I just can't put my finger on it.

I've tested this with vbp 5.7 on a windows 2000 server against a windows 2000 network share and a windows 2003 network share.

If you need more infomration, just let me know.

We were able to reproduce the problem with your sample -- thanks. It seems that the timestamps returned by Windows for files on a network share aren't very precise, leading to problems with how VBP was handling modifications to global macros from external actions. We've tweaked things and this should now work correctly. The download has been updated with a fix for this issue.

Thanks a lot, this made the build procedure a lot easier.