Использование состояния сеанса ASP.NET с Silverlight (Prism)

Question

Сценарий: у меня есть приложение призма, разработанное в Silverlight (4), и я использую приложение Service Server Asp.net для размещения нескольких веб-сервисов (которые, в свою очередь, доступ к WCF-службам, но это не очень важно здесь ). Приложение Silverlight Silverlight должно быть в состоянии вызвать перекрестный домен веб-сервисов (что означает, что веб-сервисы не обязательно на одном и том же сервере, размещенном приложении Silverlight).

Приложение Silverlight состоит из нескольких модулей, каждый каждый доступ к веб-службам ASP.NET.

У меня нет большого опыта с Silverlight и Prism, но, насколько я вижу, это не очень необычный сценарий ...

Проблема: Моя задача заключается в том, что когда 2 разных модуля доступа к веб-службам, я получаю 2 новых сеанса на веб-сервере. Я бы подумал, что поскольку обе модули живут на той же HTML-странице (а затем также в одном сеансе браузера), они получили ту же сеанс на веб-сервере ...?

Я попытался сделать веб-сервис-клиент-клиент в глобальном масштабе в контейнере (используя единство), зарегистрировав экземпляр (используя контейнер. Регистрация), а затем получение этого экземпляра всякий раз, когда модуль должен сделать вызов веб-сервиса ( Использование Container.Resolve), но это не помогает.

Однако любые звонки, сделанные в одном модуле, всегда получают один и тот же сеанс на сервере.

Кто-нибудь может увидеть, что я скучаю здесь ...?

Спасибо!

Джон

Answer 1

Похоже, я нашел свой собственный ответ.

Проблема заключалась в том, что мое приложение выпустило несколько вызовов веб-службы при запуске (различные модули призма, работающие независимо). И когда несколько звонков были сделаны до того, как любые ответы были переданы на веб-сервере, не было предоставлено сеанс (и, следовательно, нет «ASP.NET_SESSIDID» cookie) назад к клиенту, прежде чем были сделаны последующие вызовы.

Мое решение было, чтобы убедиться, что я делаю один Вызов (Async как всегда), например, к простому веб-службу, подобно пингу, затем удерживайте все другие вызовы на веб-сервер, пока этот ответ не вернется. Затем все последующие вызовы дают ту же сеанс на сервере (потому что теперь все они содержат печенье «ASP.NET_SINEID» в заголовке).

В Pratice этот вызов сделан призма-оболочкой, и никакие модули не загружаются перед тем, как получить ответ. Тогда я абсолютно уверен, что ни один из других модулей не добивается спускового крючка, прежде чем у меня есть состояние сеанса под рукой.

Тем не менее, если кто-нибудь видит любые другие проблемы с этим решением, я более чем рад услышать от вас.

Спасибо!

Джон