cannot use static fields in AJAX applications?

  • Thread starter Thread starter PJ6
  • Start date Start date
P

PJ6

I have an ASP.NET application that serializes data containing types that are
dynamically constructed. There are special considerations for this,
especially for arrays of an interface type containing heterogeneous dynamic
types.

ViewState's built-in serialization does not like dynamically constructed
types, so I manually serialize the data, and encapsulate it with
information, including type names, that is helpful for properly creating
serializers for later deserialization requests. In order to make sure that
the type names are resolved properly, I register any new assembly names into
a static list of strings as needed. These can later be resolved to
assemblies, which can resolve type names into types.

This sounds complicated, but it works well in all cases on localhost when
running on a development machine. But it fails when deserialization requests
come from AJAX calls in our test environment.

I just discovered that the static list of assemblies (and indeed, any static
list) may have elements added on serialization, but these additions are NOT
there when the deserializing AJAX calls attempt to retrieve it. If I had to
guess I would say that the process that is handling AJAX requests is running
on one or more separate app domains.

If I cannot preserve some state across all processes within this application
(how else will I propagate constructed types across them as they are
created?) I may be forced to conclude that serialization of dynamic types is
in principle not feasible in ASP.NET.

The only thing I can think of to fix this is some obscure config or
application pool setting. Any ideas?

Paul
 
Never mind, dumb question.

No static fields or lookups are required, I just needed to use the target
type as a generic parameter on the deserialization function; for now that
type's assembly is sufficient to resolve additional types. The dynamic type
generator occasionally "forgets" that it constructed types for interfaces
(maybe it's deliberate, uber GC through app domain reinstatiation since
everything outside of session should be truly stateless), but that's fine,
it just recreates them as needed. I'm glad it's this way because now I can
say that scaling won't break anything.

Um, wow, and that's why they don't persist information that may speed up xml
serializer construction for specific types. Everything gets regularly
flushed!

Paul
 
Back
Top