6 replies to this topic

[jverne]

Greetings.

I've just started using Dynamic file links in two of my file groups.  Both depend on environment variables being present, and work well on my test machine.  The environment variables are correctly set and exported to the ISBuild environment.  We keep our project under source-code control, and part of the automated nightly build is to check out the IS project and running a script.  The problem is that I'm finding out that the dynamic links are broken in the checked out copies of the project.  That is, the links will fail to work when building the disk image via ISBuild.exe.

A closer look at the "File Group Link Type" dialog shows that the Link Properties are blank.  The environment variables, including the two I created earlier, are present when I click the disclosure arrow, but the text box that holds the "<ENVIRONMENT_VAR>\path" and the Wild Cards are blank.  This information is lost via version control.  Our version control software versions anything and everything that happens to be in a text file.

There are no surprises that when I peek inside the file group text files, I find no references to these variables, or the paths constructed with them.

Once I edit this dialog, using the variables already present in the project, it works ok.  I'm just finding that this particular information is NOT stored in the project and seems system specific.  The environment variables are preserved, just not the use of them.

Is the assumption that an environment variable is machine-specific?  If so, this is a serious design flaw.

Anyone know what I have to do to get this information into the project so that anyone recreating it on their desktop can build it?

[Taco Bell]

Why are you using a custom enviroment variable instead of the built-in ISPROJECTDIR (i.e. <ISPROJECTDIR>\!_Data Files_\...)???

[jverne]

Quote (TacoBell00 @ Mar. 14 2003,18:40)

Why are you using a custom enviroment variable instead of the built-in ISPROJECTDIR (i.e. <ISPROJECTDIR>\!_Data Files_\...)???

... because those variables do not contain the files I need.  You can use arbitrary environment variables to get files from a variety of places.  It works great on the system where the changes are made.  These just do not survive being moved to another system via source-code control.  In fact, none of the IS project files appear to change when changes are made to dynmaic file group settings.

So my guess is that even if I was  using the builtin variables, this wouldn't solve anything.

The problem is not that the variables aren't set or found, but that the actual entry in the file group panel is erased.  That is, using a dynamic file group does not appear to save this information in the IS project.

In fact, making changes to a dynamic file group settings does not seem to trigger any "such and such file is read only, do you want we to save anyway" message when the project is saved.

[jverne]

Got it.

The file links were actually new filegroups (well, one was, and the other was renamed, which is probably the same thing).  The .fgl files were not added to source-code control.  Only the filegroup reference was there in the  Default.fgl, but the actual info required to find them was not present.

Simple, really.

[Taco Bell]

Okay, I see why you need enviroment variables then.

Also makes sense now why it wasn't working.

[Scott Mayham]

Glad you "got it".  I do things here almost exactly the way you describe, and I've been bitten in a similar way.

I'm just chiming in to reassure everyone that (a) dynamic links work fine in conjunction with EnvVars, and ( that developing such a setup on one box but then overnight building them on a different box via source-control checkout and ISBuild work fine.  That is exactly how I've been doing it for some time now.  

For Source Control, we use StarTeam, which, when you go to check in your project, automatically identifies for you any files which it hasn't seen before (aka "not in view"), to remind you to add them to it's "view" of your project.  Perhaps the tool you are using can be set to do something similar, so that when you add a new file to your project (such as a new .fgl file), it points that out to you, giving you the chance to check it in.

A few caveats about dynamic links.  They are convenient, but a bit more risky than static links.  If the routine builds for your application are fairly stable, static links will right away make it clear when something is missing from the app build.  Dynamic links won't - if one, none, or a thousand files satisfy the wildcard(s), that's what you'll get - it has no way of knowing whether something is missing or if there is something which does not belong.  That isn't necessarily bad, as long as other aspects of your app's build process are working cleanly.

Another caveat is the known bug in how the IDE handles the wildcard itself.  Despite what the IDE leads you to believe, it will only record the first wildcard you enter in the .fgl file - if you enter more, say, *.exe and *.dll, only the *.exe is recorded by the IDE in the .fgl - the *.dll is simply ignored.  There is an easy way around this (I think I found out about this here in this forum):  just edit the .fgl file, which is a plain text file.  

If you open your .fgl file with NotePad, you'll find a line with your first wildcard, which looks something like this:

       WILDCARD0=*.exe

All you need to to is to add additional lines immediately following this one, with your additional wildcards:

       WILDCARD1=*.dll
       WILDCARD2=foob*r.txt
       WILDCARD3=blahblah.*

Well, you get the idea.  Anyway, I'm not sure what the upper limit is on how many such lines you can add, but I have a few with 5 or 6.  They work fine.

Anyway, that's my wee contribution.  Have a great weekend.

[jverne]

Thanks for the tip.  I use

Code Sample

<EnvVar>\Path\*.*

only so far, but I know I'd run into this limitation eventually, as I'm really starting to use dynamic links more.

They are just too convenient, and our buildmaster hates absolute paths to things cluttering up the build boxes.