.Net Service provider XmlSerialization problems

[email protected] Wed, 19 May 2004 09:17:26 +0200
Newsgroups gmane.comp.sourceid.sso.devel
Message-ID <OFA7683FCA.39ECB87B-ON42256E99.00272D57-42256E99.00280C64@sanlam.co.za>
Hi guys

We've implemented SSO using SourceID's code  as a base with a java idp
backend running on our mainframe and .Net service providers on the
front-end.
This works great except for one thing: XmlSerialization is killing our
servers on the front-end.

Under normal circumstances the first time you serialize an object of a
specific type to XML seven assemblies get created and loaded into the
assembly cache. The next time you serialize those seven objects don't g=
et
recreated, they're just reused.

With the XmlSerialization we use to serialize the saml request this doe=
s
not happen. Every time a user logs on seven objects are added to the
assembly cache untill the server starts misbehaving horribly because of=
 all
the references in memory.

Here is the serialization code:

//Serialize assertionequest to requestDocument
XmlDocument requestDocument =3D new XmlDocument();

XmlSerializer requestSerializer =3D new XmlSerializer(typeof
(Bindings.Saml.Protocol.RequestType), new Type[]{typeof
(Core.SignedSAMLRequestType)});

requestSerializer.Serialize
      (new XmlNodeWriter(requestDocument, false),
      assertionRequest,
      new
XmlSerializerNamespaces(SourceID.Constants.Namespace.Namespaces));

Has anyone come across the same problem yet ?

To check to see if this happens, just open the performance monitor on a=

service provider server and add .Net loading as a counter and look at t=
he
total number of assemblies.

I know this problem might not be a SourceID specific problem, but I'm j=
ust
wondering if any of the .Net guys might have run into the same problem.=


Thanks for any help

***************
Any views expressed in this message are those of the individual sender,=
 and
Sanlam accepts no liability therefore, except where the sender specific=
ally
states them to be those of Sanlam.
Enige sienswyses of stellings wat in hierdie boodskap uitgedruk word is=
 di=E9
van die individuele afsender, en Sanlam aanvaar geen aanspreeklikheid
daarvoor nie, behalwe waar die afsender uitdruklik vermeld dat dit di=E9=
 van
Sanlam is.
=