Version : 2.5 Final 10/25/2007 .Net 2.0 Adapter MSSQL

When we generate code it appears that extra carriage returns or spaces are being inserted near some of the comment sections for each new generation. See the attached VSS “show differences” screen shot for an example. This causes VSS to think that all of the files have been modified updating the timestamps and making it impossible to tell what actually changed in each build. Is there any way to prevent this?

Thanks, Aaron

Hi Aaron,

Some points:

• Did you switch off the TdlEmitTimeDateInOutputFiles flag (project property)?

• There is not file attached

• VSS isn't reliable. If possible drop it asap and move to vault or svn.

David,

Thanks for the reply. I just attached the file, not sure what happened when I created the original post. Its currently in "pending" status, hopefully it will be readable soon.

We do have the TdlEmitTimeDateInOutputFiles set to false. Once you can see the attachment my issue will be more clear. VSS sees the difference on the comment line “//_LLBLGENPRO_USER_CODE_REGION_END”. If you look at the lines with the naked eye they appear to be the same.

I know VSS isn’t the greatest source control tool! We have been considering moving to something else, is SVN/Subversion the preferred source control tool in the LLBL community?

Thanks, Aaron

I have a feeling this was reported and solved before, but I can't seem to find the relevant thread.

Anyway, would you please try installing the latest release of v.2.5 as you are using an old one (the first build of it I suppose).

I will download the latest 2.5 release and give that a try. Will post back and let you know the results.

Thanks, Aaron

I'll just close this thread for now, to be removed from our support queue. And it will be automatically re-opened once you post a reply.

I downloaded and installed 2.5 full version build June 2nd and that did not resolved the problem. Additional I downloaded the runtime libraries package build 10162008 and tasks and Templates package build 07232008 and those didn’t resolve it either. Any other ideas of things I should try?

Thanks, Aaron

what exactly is appended, spaces or tabs or other? If you generate code a couple of times on top of the existing files, are there new spaces appended every time or is the # of spaces limited to just the same number?

I'll try to reproduce it on monday. We don't have a bug matching this report in our system, though the issue does sound familiar.

Be sure that when you generate code, the files aren't open in any editor.

Ff the files are different, every sourcecontrol system will pick up the difference, so if there are trailing spaces, it will be picked up by subversion as well. We internally use subversion and we'll notice it if it happens. In a general note: subversion is IMHO better than sourcesafe, as it doesn't pollute your project/solution files and is more robust. Though we used sourcesafe for many years internally and never had many problems with it, however subversion is more flexible and I really like the way subversion works (so we use it internally for many years already )

reproduced. Looking into it. v2.6 has the same problem. It's a 1 time issue though, every time you re-generate afterwards it won't alter it again.

(edit) I think the problem is this: this is a region in the template:

    <[ UserCodeRegion "AdditionalNamespaces" ]>
    // __LLBLGENPRO_USER_CODE_REGION_START AdditionalNamespaces
    // __LLBLGENPRO_USER_CODE_REGION_END
    <[ EndUserCodeRegion ]>

The parser sees the two TDL tokens for start and end. The regular expression to match the region markers matches:

    // __LLBLGENPRO_USER_CODE_REGION_START AdditionalNamespaces
    // __LLBLGENPRO_USER_CODE_REGION_END

so till 'END' but not the CRLF.

The problem is caused by the EndUserCodeRegion statement. As it isn't placed into the output, the tabs in front of it are emitted into the output as that's space between the 'END' and the EndUserCodeRegion token.

The problem is: changing this will cause everyone to get changed generated code all of a sudden. Keeping it will give the problem you ran into: the second time you generate code it's different from the first time.

We'll therefore postpone this fix till v3 due to the impact for existing users. As said: if you generate the code again on top of the existing code, you won't see a change in the generated code anymore. Sorry for this inconvenience, however there's little we can do about it without affecting a lot of people. With a version change (new version) we can warn up front and people expect changes, however a patch ... that should work without problems.

Frans,

Thanks for putting the effort into researching this! It’s not a big issue for us, I was just curious if there was an easy fix to resolve the problem. We can learn to live with it.

As for VSS we have been using it for many years here. When we get some time we plan on evaluating other packages, it sounds like what is available now is much better. Subversion will be high on our list, I have read many positive reviews of it.