I have a list iterator that I use to iterate through the build output from a VS.NET build. This will have to iterate through potentially hundreds or thousands of lines of output. I checked the "Suppress Log Messages" in the Runtime tab for the List Iterator so I don't have to actually see each iteration, yet I still see the List Iterator line in the log.
Am I missing something? Shouldn't the "Supress Log Messages" have gotten rid of the iterator lines in the log? How should this work? Is there way to turn this off so I don't see all those messages?
Thanks!
FinalBuilder 6.2.0.1074
Hi Robert,
To remove the iterator log entries from the log you’ll need to enable the ‘Hide Action From Log’ option on the List Iterator.
As an alternative to the list iterator (and depending on what you need to achieve) you may want to look at output monitors, they contain a lot of functionality for processing action output without requiring the use of iterators (Action Properties -> Runtime Tab -> Monitor Action Output).
Hope this helps,
Paul.
Hi Paul
I forgot to mention that I did check the “Hide Action From Log”. I still get all the List Iterator messages in the log.
I started out by looking at the Monitor Action Output and was successful in getting it to work. However it didn’t have enough functionality for what I was trying to do. For example, I wanted to examine the output log from the compile of my solution looking for specific error messages (i.e. Missing XML Comment). I wanted it to collect the line containing that message, but this isn’t enough. You need to know what project that message occured in which is not on the same line in the log. It would change the color of the line containing the monitor output, but would not change the color of the project that contained those lines so it was impossible to easily search for the output that was found.
And if you do a search in the log, all it does is put you at the very top of the action that ultimately contains the text you searched for. In the case of the build output, this message could be buried hundreds or thousands of lines down in the output for that action. You still have to search, by hand, through all the messages to find the actual line you where searching for in the first place. It would be nice if the search would place you on the exact line containing the text you searched for.
Here is a couple of other minor things I noticed:
If you defined an output monitor and set its behaviour to “Save All Matches to Variable”. Then you go back later and change the behaviour to say “Fail action if match found”, then variable combo is still enabled and there is no way to clear the variable other than deleting the action and recreating it. I don’t believe this breaks anything, but might be confusing to someone.
I also tried this…defined an output monitor (Search string: “Missing XML Comment”, Use wildcards checked, behaviour: “Save All Matches to Variable” and set variable to “BuildMessage”). Then I run my compile and use the “Log variable” action to write out the contents of “BuildMessage”.
In my compile output I have 2 lines in the output as follows:
WARNING CS1591 in NymexFuturesHttpParser.cs(150,20) : Missing XML comment for publicly visible type or member ‘Tranz.Plugins.Parsers.Nymex.NymexFuturesHttpParser.AddMapping(string, string)’
WARNING CS1591 in NymexOptionsHttpParser.cs(191,20) : Missing XML comment for publicly visible type or member ‘Tranz.Plugins.Parsers.Nymex.NymexOptionsHttpParser.AddMapping(string, string, string)’
The output monitor found the 2 lines above. But when I had it write the output of “BuildMessage” to the log, I got:
Current variable values :
BuildMessage = WARNING CS1591 in NymexFuturesHttpParser.cs(150,20) :
WARNING CS1591 in NymexOptionsHttpParser.cs(191,20) :
Success
I would have expected it to write the ENTIRE content of the 2 log lines. Could this be a bug?
Thanks!
Hi Robert,
My apologies, it looks like the ‘Hide Action From Log’ option doesn’t work as expected when live logging is enabled, I’ll let you know when this is fixed.
With regards to the output monitor issue, I haven’t been able to reproduce it here, but I’m still looking into it.
Regards,
Paul.