Comment 6 for bug 1231877

Hi Charlie,
thanks for the example project file, i'll take a look at it. Yes, a project file should fulfill the following:

Provide basic configuration stuff.
Provide the test-dll names
Provide path/name of output files e. g. report files
Provide include/exclude of categories
Provide filters/selectors to choose certain testmethods by namespace

Possibly things are different when using the gui-version and the console-version. Usually the console-runner is scheduled to run a night, because we have so many tests to run, that takes hours to complete. Currently we start the console-runner from a batchfile, we loop through the lines of a configuration file, this one is some kind of csv-file. Each line holds the following info:

NameOfTestcase , DLL-Name, Parameters (/Fixture= | /Run= | /Include= | /Exclude=)

The batchfile loops through all the lines and does a call to the console-runner using the dll-name as well as the parameters, the resultreport-filename is taken from the TestcaseName

Now doing it like this meanas, we start a new console-runner process for each Testcase. This works of course and each new process has a clean memory segment when starting. But i think, why not put this "loop" inside the console-runner, so we would start the console-runner just once but it would behave like it would run multiple times, each time with a different TestDll and/or different parameters as well as resultfile-names. So thats why i am thinking about a way to provide 1..* run-parameters. This is more a scenario for a console-runner, interactively using the GUI runner one would load project-file A, press run, wait for the tests to finish and load the next project-file B, press run ... and so on.

Ok, so let me have a look at the existing project file and hopefully i will get an idea how to realize the feature wish. Thanks for your help.