Config files and command line

To fit into our build process, I need to be able to specify some options from the command line and others from the config file. Everything works as I like when I use this command line:

ncover.console "%PETRELHOME%\Petrel.exe" -quiet -licensepackage Package1 -test "%PETRELEXTDIR%Slb.Drilling.Mako.UnitTest.DV.dll" //wal 10 //ias Slb.Drilling.* //x bin\Slb.Drilling.Mako.UnitTest.DV.dll.coverage.xml //l caviar\caviar2\coverage.log //cs bin\petrel_dv3_ncover_settings.xml

But when I try to remove some of the command line options and read them from the config file instead, this doesn't seem to work.

In particular, if I switch to this command line:

ncover.console "%PETRELHOME%\Petrel.exe" -quiet -licensepackage Package1 -test "%PETRELEXTDIR%Slb.Drilling.Mako.UnitTes.DV.dll" //cr bin\petrel_dv3_ncover_settings.xml //x bin\Slb.Drilling.Mako.UnitTest.DV.dll.coverage.xml //l caviar\caviar2\coverage.log

with this config file

<?xml version="1.0" encoding="utf-8"?> true petrel_dv3 Symbol Branch CyclomaticComplexity MethodVisits ^Slb.Drilling.*$ None NCover.Console.exe false true false false 0 15 300 10

I get this message:

---- Invalid NCover Settings Detected ---- You must specify a command to execute. ---- End of Invalid Settings List ----

So I get the impression I must specify ALL the options in the config file, which won't work very easily with our automated build process.

Any ideas?

Mike

RE: Config files and command line

I know we have made some changes in the next release for config files but from what I can remember, the command line flags were never meant to be mixed with the config file.

Once you declare a config file, it is assumed that everything will be read from that file, and the command line switches are assumed to be ignored.

I assume you are using the config file because it is auto generated by a tool. If not, can you explain the goal you are trying to achieve?

Joe

RE: Config files and command line

In our baseline build procedure, we have baseline build procedures (scripts) that are shared by many baselines. We have added NCover support as an option. We want some options for NCover to be consistent between all baselines, for instance where logs and output xml files are written, and to have variations there come only as directory paths through environment variables. This is most naturally done through the command line.

Other options, like which Assemblies to include in the coverage measurement, have more variation between projects and we would like these options to be controlled by an NCover configuration xml file that is checked into the baseline.

As it is, we'll probably have to end up doing additional script processing, like making an NCover configuration file that contains embedded environment variable names that will have to be processed and expanded by a script at runtime. Not very nice... It would have been much easier if I could specify some options on the command line and some in the config file. It's hard to understand why you wouldn't have done it this way to begin with.

In some of our more complex baselines, it's likely that we will now need several configuration files with duplicated information in each of them. For instance, it's quite typical to run several different target command lines (for different test programs) but to want to use the same set of assemblies for coverage measurement for each. Since the entire target command line is one of the entries in the config file, I need a config file for each of these, but that means I have to duplicate and maintain separately the entire config file, including the list of regular expressions for the included assemblies.

So basically, NO, I wasn't using a config file that was autogenerated by a tool, but becuause YOUR tool is inflexible, I now have to write a tool of my own to generate a config file for my build process.

RE: Config files and command line

Mike,

I am sorry you feel our tool is inflexible. We have spent a tremendous amount of time ensuring flexibility in the product without causing confusion when items collide or items are not parsed in a way people expect.

I am looking at the source code for the command line parser and it appears that we no long have the issue of having a config file and command line options only if the //cr flag is FIRST. The cr flag causes the item to be deserialized and override the current settings.

I need to talk to the person who wrote that feature and see if that is a side effect or intended result.

I can send you the latest nightly build if you would like to try it out and see if it better fits your need.

Joe Feser