I see.
Since you can't use the Exception because of the ReflectionPermission
required by the Source property you have to come up with something else to
get your exception to the next stop in your workflow.
May be something like this would work:
<warning reason="FreeStyleCode">
class ExceptionSurrogate
{
public string ExceptionTypeName;
public string ExceptionAssemblyName;
public string Message;
public string StackTrace
public ExceptionSurrogate InnerExcection;
public ExceptionSurrogate() {}
public ExceptionSurrogate( Exception ex )
{
ExceptionTypeName = ex.GetType().FullName;
ExcepionAssemblyName = ex.GetType().GetName();
Message = ex.Message;
// you get the idea
// ...
}
public Exception ToException()
{
Exception newEx = Activator.CreateInstance( ExceptionAssemblyName,
ExceptionTypeName );
newEx.Message = Message;
// you get the idea, again ...
}
}
</warning>
Then you could use a class like the one I spec'ed out above to transmit the
data and implement a ToException() method to get an Exception object again
on the other side.
Does that make sense ?
Christoph
----- Original Message -----
From: "Rolls, Robert" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, June 24, 2002 6:25 PM
Subject: Re: [DOTNET] XmlSerialisation
> Apologies, as part of workflow application we transfer data via transfer
> agents (email.ftp/tcpip) etc as part of this transfer we store any
failures
> with the actual data we were transferring. so we have a class that
contains
> properties that represent named valued pairs that each transfer agent
> understands.
>
> so the class that we serialise holds an Exception member so the next part
of
> the workflow can process errors; i.e. write an entry within the database,
> reschedule the transfer, raise an snmp alarm to HP open view.
>
> Regards
> Robert.
>
>
> -----Original Message-----
> From: Christoph [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, 25 June 2002 0:55
> To: [EMAIL PROTECTED]
> Subject: Re: [DOTNET] XmlSerialisation
>
>
> Robert,
>
> Generally, it would help if you posted specifics about the exception
youare
> catching, together with some code to reproduce the problem.
> I am gueesing, however, that you would see the following message upon
> examing the Message property if the InnerException of the exception you
are
> catching:
>
> The property 'Source' on type 'System.Exception' cannot be serialized
> because it is decorated with declarative security permission attributes.
> Consider using imperative asserts or demands in the property accessors.
>
> The XmlSerializer is designed to work in all environments without special
> security privileges. I am guessing that it does not process anything that
> would cause problems in more restricted environments.
>
> A more general question though: Why are you trying to serialize an
> Exception? Given all the limitations and restrictions of the XmlSerializer
> it is best to only serialize types that were explicitly designed to be
used
> with it.
>
> HTH,
> Christoph Schittko
> Software Architect
> Mshow - a division of InterCall
> ----- Original Message -----
> From: "Rolls, Robert" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Sunday, June 23, 2002 11:50 PM
> Subject: [DOTNET] XmlSerialisation
>
>
> > Hi all,
> >
> > I want to serialise a class using the XmlSerialiser but it fails when I
> add
> > a public member of type Exception; why can't It serialise an exception
> > class, and does anybody have any suggestions on how to best achieve the
> > serialisation.
> >
> > Regards,
> > Robert.
> >
> >
> >
> >
> > **********************************************************************"
> > This correspondence is for the named person's use only. It may
> > contain confidential or legally privileged information or both. "
> > No confidentiality or privilege is waived or lost by any "
> > mistransmission. If you receive this correspondence in error, please
> > immediately delete it from your system and notify the sender. You
> > must not disclose, copy or rely on any part of this correspondence
> > if you are not the intended recipient.
> >
> > Any views expressed in this message are those of the individual sender,
> > except where the sender expressly, and with authority, states them to
> > be the views of Vodafone.
> >
> > This email has been checked for viruses.
> >
>
****************************************************************************
> ******************
> >
> > You can read messages from the DOTNET archive, unsubscribe from DOTNET,
or
> > subscribe to other DevelopMentor lists at http://discuss.develop.com.
>
> You can read messages from the DOTNET archive, unsubscribe from DOTNET, or
> subscribe to other DevelopMentor lists at http://discuss.develop.com.
>
>
> **********************************************************************"
> This correspondence is for the named person's use only. It may
> contain confidential or legally privileged information or both. "
> No confidentiality or privilege is waived or lost by any "
> mistransmission. If you receive this correspondence in error, please
> immediately delete it from your system and notify the sender. You
> must not disclose, copy or rely on any part of this correspondence
> if you are not the intended recipient.
>
> Any views expressed in this message are those of the individual sender,
> except where the sender expressly, and with authority, states them to
> be the views of Vodafone.
>
> This email has been checked for viruses.
>
****************************************************************************
******************
>
> You can read messages from the DOTNET archive, unsubscribe from DOTNET, or
> subscribe to other DevelopMentor lists at http://discuss.develop.com.
You can read messages from the DOTNET archive, unsubscribe from DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.
