Difference between revisions of "ConfigurationOptions"

Line 28: Line 28:
 
* optimize
 
* optimize
  
==== Overriding values ===
+
==== Overriding values ====
 
* on libraries directly included in the application we can specify option values directly in the library group that includes the library
 
* on libraries directly included in the application we can specify option values directly in the library group that includes the library
  
 
=== Application ===
 
=== Application ===
 
An application should have full control, therefore we use values specified in the application. A common scenario could be that a user has a library which he uses in another application and the testing of the library is done by using it in the application, therefore all warnings should be reported, debugs, trace, profile could be enabled, assertion level may be higher.
 
An application should have full control, therefore we use values specified in the application. A common scenario could be that a user has a library which he uses in another application and the testing of the library is done by using it in the application, therefore all warnings should be reported, debugs, trace, profile could be enabled, assertion level may be higher.

Revision as of 15:06, 13 October 2006

Handling of options specified in libraries.

Config example.png

Available Options

  • read only
  • assertions
  • .NET namespace
  • profile
  • trace
  • optimize (unused)
  • .NET application optimize
  • debug clauses
  • warnings

Problem

Should option values be specified in a library or in a project that uses the library?

Solutions

Library

A library is a black box and therefore everything is specified in the library. Usual settings could be

  • read only
  • precondition assertions
  • some useful .NET namespace
  • no profile, no trace, no debug, no warnings
  • optimize

Overriding values

  • on libraries directly included in the application we can specify option values directly in the library group that includes the library

Application

An application should have full control, therefore we use values specified in the application. A common scenario could be that a user has a library which he uses in another application and the testing of the library is done by using it in the application, therefore all warnings should be reported, debugs, trace, profile could be enabled, assertion level may be higher.