[ 
https://issues.apache.org/jira/browse/LOG4NET-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Bodewig resolved LOG4NET-265.
------------------------------------

    Resolution: Fixed

I was at the point of "the first test always fails" without your changes, 
likely because of the .NET 4.0 security related changes made to trunk earlier.  
It turned out to be a timing issue and making the tests wait a bit longer fixed 
the problem.

Tests pass for me using trunk svn revision 1166042.

> RemoteFileAppender Tests fail on Windows 7
> ------------------------------------------
>
>                 Key: LOG4NET-265
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-265
>             Project: Log4net
>          Issue Type: Bug
>          Components: Appenders
>         Environment: Windows 7 32bit
>            Reporter: Rob Prouse
>            Priority: Minor
>             Fix For: 1.2.11
>
>         Attachments: log4net-265.patch
>
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> Compiled the version of log4net in the repository and ran the unit tests. All 
> of the RemotingAppenderTests fail. Enabling internal logging gives the 
> following error.
> log4net:ERROR [RemotingAppender] ErrorCode: GenericFailure. Failed in 
> SendBufferCallback
> System.Runtime.Serialization.SerializationException: Because of security 
> restrictions, the type System.Runtime.Remoting.ObjRef cannot be accessed. 
> ---> System.Security.SecurityException: Request failed.
>    at 
> System.Runtime.Serialization.FormatterServices.nativeGetSafeUninitializedObject(RuntimeType
>  type)
>    at 
> System.Runtime.Serialization.FormatterServices.GetSafeUninitializedObject(Type
>  type)
> The action that failed was:
> Demand
> The type of the first permission that failed was:
> System.Security.Permissions.SecurityPermission
> The first permission that failed was:
> <IPermission class="System.Security.Permissions.SecurityPermission, mscorlib, 
> Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
> version="1"
> Flags="Infrastructure"/>
> The demand was for:
> <PermissionSet class="System.Security.PermissionSet"
> version="1">
> <IPermission class="System.Security.Permissions.SecurityPermission, mscorlib, 
> Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
> version="1"
> Flags="Infrastructure"/>
> </PermissionSet>
> The only permitted permissions were:
> <PermissionSet class="System.Security.PermissionSet"
> version="1">
> <IPermission class="System.Security.Permissions.SecurityPermission, mscorlib, 
> Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
> version="1"
> Flags="SerializationFormatter"/>
> </PermissionSet>
> The method that caused the failure was:
> System.Runtime.Remoting.Channels.ServerProcessing 
> ProcessMessage(System.Runtime.Remoting.Channels.IServerChannelSinkStack, 
> System.Runtime.Remoting.Messaging.IMessage, 
> System.Runtime.Remoting.Channels.ITransportHeaders, System.IO.Stream, 
> System.Runtime.Remoting.Messaging.IMessage ByRef, 
> System.Runtime.Remoting.Channels.ITransportHeaders ByRef, System.IO.Stream 
> ByRef)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to