I'll second that this would be a useful correction, and probably low risk (E.g. you aren't going to break much by asserting permissions). I suspect that it would be a lot of work - and wouldn't be very useful unless it were very thorough.
2006/5/2, Mark Douglas <[EMAIL PROTECTED]>:
Hi,
I am currently using log4net in an application that is run from MSRS
(Microsoft Reporting Services).
MSRS does not grant my application FullTrust, and I am running as
partially trusted. This is fine as I can Assert the permissions
required for my application to function correctly, but log4net does not
appear to Assert *ANY* permissions at all. This results in many
SecurityExceptions being thrown when attempting to log.
The log4net assembly is marked wit the AllowPartiallyTrustedCallers
attribute, and is strong named. In this case, it can be used by
partially trusted application (mine for example). However, instead of
log4net asserting the required permissions, it seems to gracefully
handle the SecurityExceptions. This results in no logging statements
being generated.
For example, my application does not have sufficient permissions to
write to the local disc. This results in the FileAppender(s) failing.
Shouldn't log4net Assert it's required permissions? If not, won't it
only work where the calling application has the required permissions?
Regards,
Mark
This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom it is addressed. If you have received this e-mail in error you must not copy, distribute or take any action in reliance on it. Please notify the sender by e-mail or telephone.
We utilise an anti-virus system and therefore any files sent via e-mail will have been checked for known viruses. You are however advised to run your own virus check before opening any attachments received as we will not in any event accept any liability whatsoever once an e-mail and/or any attachment is received. Any views expressed by an individual within this e-mail do not necessarily reflect the views of Systems Union Group plc or any of its subsidiary companies.
