DataPortal timeout when running application OOB

DataPortal timeout when running application OOB

Old forum URL: forums.lhotka.net/forums/t/8938.aspx


MarkOviedo posted on Sunday, May 16, 2010

I'm hoping that there might be an easy answer for this issue. My Silverlight application has a standard structure of a Web project which hosts the application and a Silverlight project that defines the application.

When I run the Web project, the Silverlight application launches and it successfully communicates with the data portal. When I install the application out-of-browser, it will execute through the first data portal call, but that call will timeout. When I monitor the web requests via Fiddler, I observe that no call originates from the OOB application. Here are a few more details :

1) To isolate this from being a potential Cassini issue, I have published the data portal web site to IIS on my local dev machine. I have placed the clientaccesspolicy.xml in the wwwroot folder to ensure this is not a cross-domain issue. When I run the Silverlight application from the web project, it works against the IIS-hosted data portal.

2) To test OOB, I have configured the Silverlight project to debug the OOB application. When I trace into this project, I trace over the data portal call and then get the callback after the timeout elapses. I have peeked into the .xap that is being used in the debug scenario, and have validated that the ServiceReference.clientconfig is pointing to the correct data portal location.

3) My dev machine is Windows 7, 64-bit. I am using CSLA 4 beta, VS 2010 and targeting .NET 4 framework for all components.

Any ideas? I am quickly running out of troubleshooting avenues!

RockfordLhotka replied on Sunday, May 16, 2010

Take the data portal out of the equation. Try creating a simple WCF service - hello world or something - and invoking it from an OOB app. Assuming that works, compare its config to yours to see if there's a difference.

MarkOviedo replied on Thursday, May 27, 2010

Thanks for the advice! I did finally root cause this, and am happy to report it has nothing to do with CSLA. Big Smile  It does seem to be a Silverlight idiosyncracy between an application running in-browser and out-of-browser.

To summarize, before I was doing something like this in the App.xaml.cs Application_Startup. I was initializing the RootVisual element in the asynchronous callback of a data portal call, since my ShellView required the back-end configuration information to be displayed. :

        private void Application_Startup(object sender, StartupEventArgs e)

        {

            //[Data portal fetch to retrieve configuration information ->

               callback to LoadConfigurationHandler when complete.]

        }

 

        // Invoked when asynchronous call to data portal completes.

        private void LoadConfigurationHandler(Request request, Exception exception)

        {

            RootVisual = new ShellView();

 

            //[Configure view using loaded configuration data.]

        }

This works fine in an in-browser scenario, but will hang in an out of browser scenario. So the fix was to remove the configuration dependencies of the ShellView and initialize the RootVisual element in the Application_Startup. Then configure the view in the callback. This works in both in-browser and OOB scenarios.

        private void Application_Startup(object sender, StartupEventArgs e)

        {

            RootVisual = new ShellView();

 

            //[Data portal fetch to retrieve configuration information ->

                callback to LoadConfigurationHandler when complete.]

        }

 

        // Invoked when asynchronous call to back-end completes.

        private void LoadConfigurationHandler(Request request, Exception exception)

        {

            //[Configure view using loaded configuration data.]

        }

Copyright (c) Marimer LLC