~ifolder-dev/simias/trunk-packaging

<a href="#timestamp">If I have many process across multiple hosts (possibly across multiple time zones) logging to the same file using the method above, what happens to timestamps?</a>

114

</li>

115

</ul>

116

</div>

117

118

<h2>Customisation</h2>

119

120

<ul>

121

<li>

122

<a href="#customLayouts">Can the log output format be customized?</a>

123

</li>

124

</ul>

125

</div>

126

127

<h2>Troubleshooting</h2>

128

129

<ul>

130

<li>

131

<a href="#internalDebug">How do I enable log4net internal debugging?</a>

132

</li>

133

<li>

134

<a href="#trouble-EventLog">Why doesn't the EventLogAppender work?</a>

135

</li>

136

<li>

137

<a href="#trouble-ASPNET-File">Why can't I log to a FileAppender from a web application?</a>

138

</li>

139

<li>

140

<a href="#troub-Service">Why doesn't the logging in my service work?</a>

141

</li>

142

<li>

143

<a href="#bugs">How do I report bugs?</a>

144

</li>

145

</ul>

146

</div>

147

148

</div>

149

<h2>Answers</h2>

150

151

152

153

<p>

154

log4net is a tool to help the programmer output log statements to a variety of

155

output targets.

156

</p>

157

<p>

158

In case of problems with an application, it is helpful to enable logging so

159

that the problem can be located. With log4net it is possible to enable logging at

160

runtime without modifying the application binary. The log4net package is designed

161

so that log statements can remain in <i>shipped</i> code without incurring a

162

high performance cost. It follows that the speed of logging (or rather not

163

logging) is crutial.

164

</p>

165

<p>

166

At the same time, log output can be so voluminous that it quickly becomes

167

overwhelming. One of the distinctive features of log4net is the notion of <i>hierarchical

168

loggers</i>. Using these loggers it is possible to selectively control

169

which log statements are output at arbitrary granularity.

170

</p>

171

<p>

172

log4net is designed with two distinct goals in mind: speed and flexibility. There

173

is a tight balance between these two requirements.

174

</p>

175

</div>

176

177

178

179

<h3><a id="reliable">Is log4net a reliable logging system?</a></h3>

180

181

<p>

182

No. log4net is not reliable. It is a best-effort and <em>fail-stop</em> logging system.

183

</p>

184

<p>

185

By fail-stop, we mean that log4net will not throw unexpected exceptions at

186

run-time potentially causing your application to crash. <b>If for any reason, log4net

187

throws an uncaught exception</b> (except for <span class="code">ArgumentException</span> and

188

<span class="code">ArgumentNullException</span> which may be thrown), <b>please send an email

189

to the <a href="mailto:log4net-users@lists.sourceforge.net">

190

log4net-users@lists.sourceforge.net</a> mailing list</b>. Uncaught exceptions

191

are handled as serious bugs requiring immediate attention.

192

</p>

193

<p>

194

Moreover, log4net will not revert to <span class="code">System.Console.Out</span>

195

or <span class="code">System.Console.Error</span> when its designated

196

output stream is not opened, is not writable or becomes full. This avoids

197

corrupting an otherwise working program by flooding the user's terminal because

198

logging fails. However, log4net will output a single message to

199

<span class="code">System.Console.Error</span> indicating that logging can not be performed.

200

</p>

201

</div>

202

203

204

205

<h3><a id="prerequisites">What are the prerequisites for log4net?</a></h3>

206

207

<p>

208

log4net runs on many different frameworks and each framework has its own requirements.

209

As a rule of thumb you will need an ECMA-335 compliant CLI runtime, for example,

210

the Microsoft .NET runtime 1.0 (1.0.3705) or 1.1 (1.1.4322).

211

</p>

212

<p>

213

Not all frameworks are created equal and some features have been excluded from

214

some of the builds. See the <a href="framework-support.html">Framework Support</a>

215

document for more information.

216

</p>

217

</div>

218

219

220

221

<h3><a id="usageExample">Is there example code for using log4net?</a></h3>

222

223

<p>

224

There is a directory containing examples in <span class="code">log4net\examples</span>.

225

The examples are broken down by framework.

226

</p>

227

</div>

228

229

230

231

<h3><a id="features">What are the features of log4net?</a></h3>

232

233

<ul>

234

<li>

235

log4net is optimized for speed.</li>

236

<li>

237

log4net is based on a named logger hierarchy.</li>

238

<li>

239

log4net is fail-stop but not reliable.</li>

240

<li>

241

log4net is thread-safe.</li>

242

<li>

243

log4net is not restricted to a predefined set of facilities.</li>

244

<li>

245

Logging behaviour can be set at runtime using a configuration file.

246

Configuration files are in XML format.</li>

247

<li>

248

log4net is designed to handle exceptions from the start.</li>

249

<li>

250

log4net can direct its output to many sinks including: a file, the console, the NT EventLog or even e-mail.</li>

251

<li>

252

log4net uses 5 levels, namely DEBUG, INFO, WARN, ERROR and FATAL.</li>

253

<li>

254

The format of the log output can be easily changed by implementing a new layout class.</li>

255

<li>

256

The target of the log output as well as the writing strategy can be altered by

257

writing a new appender class.</li>

258

<li>

259

log4net supports multiple output appenders per logger.</li>

260

</ul>

261

<p>

262

See the <a href="../features.html">features</a> overview document for more information on the features of log4net.

263

</p>

264

</div>

265

266

267

268

<h3><a id="thread-safety">Is log4net thread-safe?</a></h3>

269

270

<p>

271

Yes, log4net is thread-safe.

272

</p>

273

</div>

274

275

276

277

<h3><a id="sample">What does log output look like?</a></h3>

278

279

<p>

280

The log output can be customized in many ways. Moreover, one can completely

281

override the output format by implementing one's own <span class="code">ILayout</span>

282

</p>

283

<p>

284

Here is an example output using <span class="code">PatternLayout</span> with the conversion

285

pattern <span class="code">%r [%t] %-5p %c{2} %x - %m%n</span>

286

</p>

287

288

176 [main] INFO examples.Sort - Populating an array of 2 elements in reverse order.

289

225 [main] INFO examples.SortAlgo - Entered the sort method.

290

262 [main] DEBUG SortAlgo.OUTER i=1 - Outer loop.

291

276 [main] DEBUG SortAlgo.SWAP i=1 j=0 - Swapping intArray[0] = 1 and intArray[1] = 0

292

290 [main] DEBUG SortAlgo.OUTER i=0 - Outer loop.

293

304 [main] INFO SortAlgo.DUMP - Dump of integer array:

294

317 [main] INFO SortAlgo.DUMP - Element [0] = 0

295

331 [main] INFO SortAlgo.DUMP - Element [1] = 1

296

343 [main] INFO examples.Sort - The next log statement should be an error message.

297

346 [main] ERROR SortAlgo.DUMP - Tried to dump an uninitialized array.

298

467 [main] INFO examples.Sort - Exiting main method.

299

</pre>

300

<p>

301

The first field is the number of milliseconds elapsed since the start of the

302

program. The second field is the thread outputting the log statement. The third

303

field is the level of the log statement. The fourth field is the rightmost

304

two components of the name of the logger making the log request. The fifth field (just

305

before the '-') is the <em>nested diagnostic context</em> (<span class="code">NDC</span>). Note the

306

nested diagnostic context may be empty as in the first two statements. The text

307

after the '-' is the message of the statement.

308

</p>

309

</div>

310

311

312

313

<h3><a id="logger">What are <em>Loggers</em>?</a></h3>

314

315

<p>

316

The notion of loggers lies at the heart of log4net's configuration. Loggers define a

317

hierarchy and give the programmer <em>run-time</em> control on which statements

318

are printed or not.

319

</p>

320

<p>

321

Loggers are assigned levels through the configuration of log4net. A log statement is

322

routed through to the appender depending on its level <em>and</em> its logger.

323

</p>

324

</div>

325

326

327

328

<h3><a id="behaviour">How can I change log behaviour at runtime?</a></h3>

329

330

<p>

331

Logging behaviour can be set using configuration files which are parsed at runtime.

332

Using configuration files the programmer can define loggers and set their

333

levels.

334

</p>

335

<p>

336

Configuration files are specified in XML. See <span class="code">log4net.Config.DOMConfigurator</span>

337

for more details.

338

</p>

339

<p>

340

See the various <span class="code">log4net.Layout</span> and <span class="code">log4net.Appender</span>

341

components for specific configuration options.

342

</p>

343

</div>

344

345

346

347

<h3><a id="disableLogging">How do I completely disable all logging at runtime?</a></h3>

348

349

<p>

350

Setting the <span class="code">Threshold</span> on the Hierarchy to Level OFF will disable all

351

logging from that Hierarchy. This can be done in the log4net configuration file

352

by setting the "threshold" attribute on the log4net configuration element to "OFF".

353

For example:

354

</p>

355

356

357

</pre>

358

</div>

359

360

361

362

<h3><a id="fastLogging">What is the fastest way of (not) logging?</a></h3>

363

364

<p>

365

For some logger <span class="code">log</span>, writing,

366

</p>

367

368

log.Debug("Entry number: " + i + " is " + entry[i]);

369

</pre>

370

<p>

371

incurs the cost of constructing the message parameter, that is converting both

372

integer <span class="code">i</span> and <span class="code">entry[i]</span> to

373

a string, and concatenating intermediate strings. This, regardless of whether

374

the message will be logged or not.

375

</p>

376

<p>

377

If you are worried about speed, then write

378

</p>

379

380

if(log.IsDebugEnabled)

381

{

382

log.Debug("Entry number: " + i + " is " + entry[i]);

383

}

384

</pre>

385

<p>

386

This way you will not incur the cost of parameter construction if debugging is

387

disabled for logger <span class="code">log</span>. On the other hand, if the logger is

388

debug enabled, you will incur the cost of evaluating whether the logger is

389

enabled or not, twice: once in <span class="code">IsDebugEnabled</span> and once in <span class="code">Debug</span>.

390

This is an insignificant overhead since evaluating a logger takes less than

391

1% of the time it takes to actually log a statement.

392

</p>

393

</div>

394

395

396

397

<h3><a id="fasterfasterLogging">What is REALLY the FASTEST way of (not) logging?</a></h3>

398

399

<p>

400

So you don't think that the previous FAQ is really the fastest way

401

of not logging? Well there is a faster way but it does have some

402

drawbacks. Starting from:

403

</p>

404

405

if(log.IsDebugEnabled)

406

{

407

log.Debug("Entry number: " + i + " is " + entry[i]);

408

}

409

</pre>

410

<p>

411

It is possible to further eliminate the calls to <span class="code">IsDebugEnabled</span>

412

so that the call is only made once per logger. If you are using one logger

413

for each class then you can store the enabled state for the logger in a static

414

variable in the class and then test against this variable:

415

</p>

416

417

public class FastLogger

418

{

419

private static readonly ILog log = LogManager.GetLogger(typeof(FastLogger));

420

private static readonly bool isDebugEnabled = log.IsDebugEnabled;

421

422

public void MyMethod()

423

{

424

if(isDebugEnabled)

425

{

426

log.Debug("Entry number: " + i + " is " + entry[i]);

427

}

428

}

429

}

430

</pre>

431

<p>

432

So why exactly is this faster? Well to start with the <span class="code">IsDebugEnabled</span>

433

is not called for each log statement, it is called once per logger. Furthermore as the

434

<span class="code">isDebugEnabled</span> variable is <span class="code">private static readonly</span>

435

the JIT compiler can at <em>run-time</em> optimise out the <span class="code">if</span> test altogether. This means that

436

at runtime the JIT compiler won't even compile the logging statements into native code, i.e.

437

all the logging just disappears.

438

</p>

439

<p>

440

So what is the downside to using this? Well one of the clever features of log4net is that

441

you can change the logging configuration while your program is running. If you need to

442

investigate an issue in your application, you don't have to stop the application, setup the

443

logging and restart the application, you can change the logging configuration and the

444

log4net will reload it (see <span class="code">ConfigureAndWatch</span> APIs for more

445

information). However if the JIT has compiled out all of the logging statements

446

then they are gone and you can't get them back by reloading the configuration file. Effectively

447

this means that the logging configuration can only be set when the application loads and

448

it cannot be changed at runtime. It is up to you to decide if you need ultimate speed or need

449

to be able to reload the logging configuration while the application is running.

450

</p>

451

</div>

452

453

454

455

<h3><a id="namingLoggers">Are there any suggested ways for naming loggers?</a></h3>

456

457

<p>

458

Yes, there are.

459

</p>

460

<p>

461

You can name logging loggers by <strong>locality</strong>. It turns out that

462

instantiating a logger in each class, with the logger name equal to the

463

fully-qualified name of the class, is a useful and straightforward approach of

464

defining loggers. This approach has many benefits:

465

</p>

466

<ul>

467

<li>

468

It is very simple to implement.</li>

469

<li>

470

It is very simple to explain to new developers.</li>

471

<li>

472

It automatically mirrors your application's own modular design.</li>

473

<li>

474

It can be further refined at will.</li>

475

<li>

476

Printing the logger automatically gives information on the locality of the

477

log statement.</li>

478

</ul>

479

<p>

480

However, this is not the only way for naming loggers. A common alternative

481

is to name loggers by <strong>functional areas</strong>. For example, the

482

"database" logger, "remoting" logger, "security" logger, or the "XML"

483

logger.

484

</p>

485

<p>

486

You may choose to name loggers by functionality and subcategorize by

487

locality, as in "DATABASE.MyApp.MyClass" or

488

"DATABASE.MyApp.MyModule.MyOtherClass".

489

</p>

490

<p>

491

<em>You are totally free in choosing the names of your loggers.</em> The

492

log4net package merely allows you to manage your names in a hierarchy. However,

493

it is your responsibility to define this hierarchy.

494

</p>

495

<p>

496

<b>Note:</b> by naming loggers by locality one tends to name things by

497

functionality, since in most cases the locality relates closely to

498

functionality.

499

</p>

500

</div>

501

502

503

504

<h3><a id="className">How do I get the fully-qualified name of a class in a static block?</a></h3>

505

506

<p>

507

You can easily retrieve the fully-qualified name of a class in a static block

508

for class <span class="code">X</span>, with the statement <span class="code">typeof(X).Name</span>.

509

Note that <span class="code">X</span> is the class name and span an instance.

510

However because the <span class="code">LogManager.GetLogger</span> method is overloaded

511

to take an instance of <span class="code">Type</span> as well as <span class="code">string</span>

512

usually only the type of the class is required.

513

</p>

514

<p>

515

Here is the suggested usage template:

516

</p>

517

518

public class Foo

519

{

520

private static readonly ILog log = LogManager.GetLogger(typeof(Foo));

521

... other code

522

}

523

</pre>

524

<p>

525

An equivalent and more portable solution, though slightly longer, is to use the declaring type

526

of the static constructor.

527

</p>

528

529

public class Foo

530

{

531

private static readonly ILog log = LogManager.GetLogger(System.Reflection.MethodBase.GetCurrentMethod().DeclaringType);

532

... other code

533

}

534

</pre>

535

<p>

536

<b>Note:</b> the .NET Compact Framework 1.0 does not support <span class="code">System.Reflection.MethodBase.GetCurrentMethod()</span>.

537

</p>

538

</div>

539

540

541

542

<h3><a id="customLayouts">Can the log output format be customized?</a></h3>

543

544

<p>

545

Yes. You can implement the <span class="code">ILayout</span> interface to

546

create you own customized log format, or you can extend the

547

<span class="code">LayoutSkeleton</span> class which provides a default

548

implementation of the <span class="code">ILayout</span> interface.

549

Appenders can be parameterized to use the layout of your choice.

550

</p>

551

</div>

552

553

554

555

<h3><a id="NDC">Can the outputs of multiple client request go to different log files?</a></h3>

556

557

<p>

558

Many developers are confronted with the problem of distinguishing the log

559

output originating from the same class but different client requests. They come

560

up with ingenious mechanisms to fan out the log output to different files. In

561

most cases, this is not the right approach.

562

</p>

563

<p>

564

It is simpler to use a nested diagnostic context (<span class="code">NDC</span>).

565

Typically, one would <span class="code">NDC.Push()</span>

566

client specific information, such as the client's hostname, ID or any other

567

distinguishing information when starting to handle the client's request.

568

Thereafter, log output will automatically include the nested diagnostic context

569

so that you can distinguish logs from different client requests even if they

570

are output to the same file.

571

</p>

572

<p>

573

See the <span class="code">NDC</span> and the <span class="code">PatternLayout</span> classes for more

574

information.

575

</p>

576

</div>

577

578

579

580

<h3><a id="options">What are the configurable options for an appender?</a></h3>

581

582

<p>

583

log4net uses public properties to configure components such as

584

Appenders, Layouts, Loggers etc.

585

</p>

586

<p>

587

Thus, any writable public property in on the appender corresponds to a

588

configurable option. For example, in <span class="code">RollingFileAppender</span> the

589

<span class="code">public int MaxSizeRollBackups { set; }</span> property corresponds to

590

the <span class="code">MaxSizeRollBackups</span> option.

591

</p>

592

<p>

593

Layouts options are also defined by their writable properties. Same goes for most

594

other log4net components.

595

</p>

596

</div>

597

598

599

600

<h3><a id="rm">Logger instances seem to be create only. Why isn't there a method to remove logger instances?</a></h3>

601

602

<p>

603

It is quite nontrivial to define the semantics of a "removed" logger which is

604

still referenced by the user.

605

</p>

606

</div>

607

608

609

610

<h3><a id="filterByLevel">Is it possible to direct log output to different appenders by level?</a></h3>

611

612

<p>

613

Yes it is. Setting the <span class="code">Threshold</span> option of any appender extending

614

<span class="code">AppenderSkeleton</span>, (most log4net appenders extend

615

<span class="code">AppenderSkeleton</span>) will filter out all log events

616

with a <em>lower</em> level than the value of the threshold option.

617

</p>

618

<p>

619

For example, setting the threshold of an appender to DEBUG will also allow INFO,

620

WARN, ERROR and FATAL messages to log along with DEBUG messages. (DEBUG is the

621

lowest level). This is usually acceptable as there is little use for DEBUG

622

messages without the surrounding INFO, WARN, ERROR and FATAL messages.

623

Similarly, setting the threshold of an appender to ERROR will filter out DEBUG,

624

INFO and ERROR messages but not FATAL messages.

625

</p>

626

<p>

627

This policy usually best encapsulates what the user actually wants to do, as

628

opposed to her mind-projected solution.

629

</p>

630

</div>

631

632

633

634

<h3><a id="multiProcess">How do I get multiple process to log to the same file?</a></h3>

635

636

<p>

637

The <span class="code">FileAppender</span> holds a write lock on the log

638

file while it is logging. This prevents other processes from writing to the

639

file, therefore it is not possible to have multiple processes log directly

640

to the same log file, even if they are on the same machine.

641

</p>

642

<p>

643

You may have each process log to a <span class="code">RemotingAppender</span>.

644

The receiving <span class="code">RemoteLoggingServerPlugin</span> (or

645

<span class="code">IRemoteLoggingSink</span>) can receive all the events and

646

send them to a single log file.

647

</p>

648

</div>

649

650

651

652

<h3><a id="timestamp">If I have many processes across multiple hosts (possibly across multiple time zones) logging to the same file using the method above, what happens to timestamps?</a></h3>

653

654

<p>

655

The timestamp is created when the logging event is created. That is so say,

656

when the <span class="code">Debug</span>, <span class="code">Info</span>,

657

<span class="code">Warn</span>, <span class="code">Error</span>

658

or <span class="code">Fatal</span> method is invoked. This is unaffected by the time at

659

which they may arrive at a remote server. Since the timestamps are

660

stored in UTC format inside the event, they all appear in the same time zone as

661

the host creating the logfile. Since the clocks of various machines may not be

662

synchronized, this may account for time interval inconsistencies between events

663

generated on different hosts.

664

</p>

665

</div>

666

667

668

669

<h3><a id="configureandwatch">Is there a way to get log4net to automatically reload a configuration file if it changes?</a></h3>

670

671

<p>

672

Yes. The <span class="code">DOMConfigurator</span> supports automatic

673

reloading through the <span class="code">ConfigureAndWatch</span> APIs. See the API

674

documentation for more details.

675

</p>

676

</div>

677

678

679

680

<h3><a id="tax">Why should I donate my extensions to log4net back to the project?</a></h3>

681

682

<p>

683

Contrary to the GNU Public License (GPL) the Apache Software License does not

684

make any claims over your extensions. By extensions, we mean totally new code

685

that invokes existing log4net classes. <em>You are free to do whatever you wish with

686

your proprietary log4net extensions.</em> In particular, you may choose to

687

never release your extensions to the wider public.

688

</p>

689

<p>

690

We are very careful not to change the log4net client API so that newer log4net

691

releases are backward compatible with previous versions. We are a lot less

692

scrupulous with the internal log4net API. Thus, if your extension is designed to

693

work with log4net version <span class="code">n</span>, then when log4net release version <span class="code">n+1</span>

694

comes out, you will probably need to adapt your proprietary extensions to the

695

new release. Thus, you will be forced to spend precious resources in order to

696

keep up with log4net changes. This is commonly referred to as the "stupid-tax".

697

By donating the code and making it part of the standard distribution, you save

698

yourself the unnecessary maintenance work.

699

</p>

700

<p>

701

If your extensions are useful then someone will eventually write an extension

702

providing the same or very similar functionality. Your development effort will

703

be wasted.

704

</p>

705

<p>

706

Unless the proprietary log4net extension is business critical, there is little

707

reason for not donating your extensions back to the project.

708

</p>

709

</div>

710

711

712

713

<h3><a id="help">What should I keep in mind when contributing code?</a></h3>

714

715

<ol>

716

<li>

717

Stick to the existing indentation style even if you hate it.

718

<p>

719

Alternating between indentation styles makes it hard to understand the source

720

code. Make it hard on yourself but easier on others.

721

</p>

722

</li>

723

<li>

724

<b>Thoroughly test your code.</b>

725

<p>

726

There is nothing more irritating than finding the bugs in debugging (i.e. logging) code.

727

</p>

728

</li>

729

<li>

730

Keep it simple, small and fast.

731

<p>

732

It's all about the application not about logging.

733

</p>

734

</li>

735

<li>

736

Did I mention sticking with the indentation style?</li>

737

</ol>

738

</div>

739

740

741

742

<h3><a id="internalDebug">How do I enable log4net internal debugging?</a></h3>

743

744

<p>

745

There are several different ways to enable internal debugging in log4net.

746

These different methods are listed below. The prefered method is to sepcify

747

the <span class="code">log4net.Internal.Debug</span> option in the application's

748

config file.

749

</p>

750

<ul>

751

<li>

752

<p>

753

To enable log4net's internal debug programmatically you need

754

to set the <span class="code">log4net.helpers.LogLog.InternalDebugging</span>

755

property to <span class="code">true</span>. Obviously the sooner this

756

is set the more debug will be produced.

757

</p>

758

</li>

759

<li>

760

<p>

761

Internal debugging can also be enabled by setting a value in the application's

762

configuration file (not the log4net configuration file, unless the log4net config

763

data is embeded in the application's config file). The <span class="code">log4net.Internal.Debug</span>

764

application setting must be set to the value <span class="code">true</span>.

765

For example:

766

</p>

767

768

<?xml version="1.0" encoding="utf-8" ?>

769

770

771

772

</appSettings>

773

</configuration>

774

</pre>

775

<p>

776

This setting is read immediatly on startup an will cause all internal

777

debugging messages to be emmitted.

778

</p>

779

</li>

780

<li>

781

<p>

782

To enable internal debugging from a configuration file, the

783

<span class="code">debug</span> attribute on the log4net

784

configuration element can be set to the value <span class="code">true</span>.

785

For example:

786

</p>

787

788

789

790

... configuration ...

791

792

</log4net>

793

</pre>

794

<p>

795

Using this method does require that your configuration file is located

796

and loaded, otherwise the attribute will not be read. If you need to

797

debug the process of locating the configuration file then use one of the other

798

methods for enabling debugging.

799

</p>

800

</li>

801

</ul>

802

<p>

803

Internal debugging messages are witten to the console and to the

804

<span class="code">System.Diagnostics.Trace</span>

805

system. If the application does not have a console the messages logged

806

there will be lost. Note that an application can redirect the console

807

stream by setting the <span class="code">System.Console.Out</span>. The

808

Trace system will by default send the message to an attached debugger

809

(where the messages will appear in the output window). If the process

810

does not have a debugger attached then the messages are sent to the

811

system debugger. A utility like DebugView from

812

<a href="http://www.sysinternals.com">http://www.sysinternals.com</a>

813

may be used to capture these messages.

814

</p>

815

</div>

816

817

818

819

<h3><a id="bugCorrection">How fast do bugs in log4net get fixed?</a></h3>

820

821

<p>

822

As fast as they get reported ;-)

823

</p>

824

</div>

825

826

827

828

<h3><a id="history">What is the history of log4net?</a></h3>

829

830

<p>

831

log4net is a port of the popular <a href="http://jakarta.apache.org/log4j/">log4j</a> logging library.

832

The initial port was done in July 2001, since then we have tried to remain in the

833

spirit of the original log4j.

834

</p>

835

</div>

836

837

838

839

<h3><a id="bugs">How do I report bugs?</a></h3>

840

841

<p>

842

Before reporting an issue please check that the question has not been asked before in

843

the <a href="http://sourceforge.net/mailarchive/forum.php?forum=log4net-users">archive</a>.

844

</p>

845

<p>

846

Ask questions and report bugs via email to the <a href="mailto:log4net-users@lists.sourceforge.net">

847

log4net-users@lists.sourceforge.net</a> mailing list.

848

</p>

849

<p>

850

Please specify the version of log4net and the framework you are using. It is helpful to

851

include log configurations files if any, plus source code. A short example reproducing

852

the problem is very much appreciated.

853

</p>

854

<p>

855

If possible please reproduce your issue with the <a href="#internalDebug">internal log4net debugging</a> enabled.

856

Include this debug output in your post, it is usualy the first thing we ask for in diagnosing

857

issues.

858

</p>

859

</div>

860

861

862

863

<h3><a id="download">Where can I find the latest distribution of log4net?</a></h3>

864

865

<p>

866

The log4net <a href="http://log4net.sourceforge.net/">home page</a> is a good place to start.

867

</p>

868

<p>

869

The log4net project is hosted at <a href="http://sourceforge.net/projects/log4net/">Sourceforge</a>.

870

</p>

871

</div>

872

873

874

875

<h3><a id="trouble-EventLog">Why doesn't the EventLogAppender work?</a></h3>

876

877

<p>

878

If you are not getting events delivered to the event log this usually indicates

879

a permissions problem. Basically if the event log does not exist the EventLogAppender

880

tries to create it, but you need local administrator permissions to create event logs

881

(just to write into the right bit of the registry). You don't need administrator

882

permissions to log to an existing event log, but it must exist. If you are using the

883

event log from a web application or service using the event log can be a little tricky.

884

</p>

885

<p>

886

A web application will run as the user account ASPNET. This account deliberately has

887

few permissions to reduce the chances of someone hacking into the web server. While the

888

account has permission to write to the event log it does not have permission to create

889

event sources (registry create and write access), which are needed to write to the event log.

890

</p>

891

<p>

892

There are a couple of solutions:

893

</p>

894

<ol>

895

<li>

896

<p>

897

Make the ASPNET user a member of the Administrators group. This will work because the

898

user will then have the required permissions. This is not recommended for production use.

899

</p>

900

</li>

901

<li>

902

<p>

903

As the event source only needs to be created once for the machine, create an installer

904

and configure it to create the event source.

905

The installer will need to be run as Administrator (don't they all). See

906

<span class="code">System.Diagnostics.EventLogInstaller</span> in the Microsoft .NET

907

Framework SDK for an example of how to create a simple event log installer.

908

</p>

909

</li>

910

</ol>

911

</div>

912

913

914

915

<h3><a id="trouble-ASPNET-File">Why can't I log to a FileAppender from a web application?</a></h3>

916

917

<p>

918

The web application runs as a special user account on the web server

919

called ASPNET. This account has restricted permissions to protect the

920

web server from attacks. By default this account may not have permission

921

to write to the file system. Make sure that the ASPNET account has

922

permission to create and write to files in the directory chosen for

923

logging.

924

</p>

925

</div>

926

927

928

929

<h3><a id="troub-Service">Why doesn't the logging in my service work?</a></h3>

930

931

<p>

932

A windows service runs as a user account specified in the services

933

control panel. This account may have restricted permissions, make

934

sure that the account has permission to create and write to files

935

in the directory chosen for logging.

936

</p>

937

<p>

938

A windows service is launched by windows. The current directory in

939

a service is set to the windows system directory (e.g.

940

<span class="code">C:\Windows\System32</span>). If you are loading

941

the configuration file from the current directory then be aware

942

that this path will not be the location of your assemblies.

943

The best way to get the path to your assemblies is to use

944

<span class="code">AppDomain.BaseDirectory</span>.

945

Note that the log4net internals never use the current directory.

946

</p>

947

</div>

948

949

950

951

</div>

952

</div>

953

954

955

</body>

956

</html>

Older »