Home/ Questions/Q 778189
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-14T19:43:32+00:00

The scenario: I have a PRISM application developed in Silverlight (4), and I’m using

  • 0

The scenario:
I have a PRISM application developed in Silverlight (4), and I’m using a ASP.NET server side application to host several web-services (which, in turn, accesses WCF-services, but that’s not really important here). The Silverlight application must be able to call the web services cross-domain (meaning that the web services isn’t necessarily on the same server hosting the silverlight application).

The Silverlight application consists of several modules, each accessing the ASP.NET web-services.

I do not have much experience with Silverlight and PRISM, but as far as I can see, this is not a very unusual scenario…

The problem:
My challange is, that when 2 different modules access the web-services, I get 2 new sessions on the web-server. I would have thought that since both modules live on the same HTML-page (and then also in the same browser session), they would get the same session on the web-server…?

I have tried to make the web-service Proxy-client globally available in the container (using Unity), by registering an instance (using Container.RegisterInstance), and then getting this instance whenever a module needs to make a web-service call (using Container.Resolve), but this doesn’t seem to help.

However, any calls made within the same module always gets the same session on the server.

Can anyone see what I’m missing here…?

Thanks!

Jon

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Looks like I found my own answer.

    The problem was that my application was firing multiple web-service calls upon startup (the different PRISM-modules working independently). And when several calls were made before any responses was given from the web-server, no session (and hence no “ASP.NET_SessionId” cookie was provided) back to the client before subsequent calls were made.

    My solution was to make sure I make one call (async as always), for example to a simple Ping-like web-service, then hold all other calls to the web-server until this response is back. Then, all subsequent calls are given the same Session on the server (because now they all contain the “ASP.NET_SessionId” cookie in the header).

    In pratice, this call is made by the PRISM-shell, and no modules are beeing loaded before I receive the reponse. Then I’m absolutely sure that none of the other modules get trigger-happy before I have a session-state on hand.

    Still, if anybody sees any other problems with this solution, I’m more than happy to hear from you.

    Thanks!

    Jon

    • 0