Problems communicating with WCFHost (Silverlight)

It’s not that – I double checked a few times.  I’m getting the Silverlight App opening and I can debug a few lines of code.  I’m basically trying to simulate what the CompanyEditor.axml page is doing except I hard-coded my id#.

  void Page_Loaded(object sender, RoutedEventArgs e)

        {

            CslaDataProvider provider = this.Resources["DataEntrySessionDataProvider"] as CslaDataProvider;

            provider.FactoryParameters.Add(4609);

            provider.FactoryMethod = "GetDataEntrySession";

            provider.Refresh();

        }

As soon as I do the Refresh() it jumps to here:

public Csla.WcfPortal.WcfResponse EndFetch(System.IAsyncResult result) {

                object[] _args = new object[0];

                Csla.WcfPortal.WcfResponse _result = ((Csla.WcfPortal.WcfResponse)(base.EndInvoke("Fetch", _args, result)));

                return _result;

            }

The most common source of trouble here is that Visual Studio keeps switching the default startup project to the Silverlight client app, rather than the hosting web app.

You must have your startup app be the web app, otherwise you'll end up going "cross domain" to two different portal on localhost.

I solved my issue but I do not really understand how.  Any explanation would be appreciated.

What I did was take the wcfHostWeb project from Rolodex and copied it into my solution.  I tweaked the port so it didn’t conflict with Rolodex and it is working…

So what is the difference?  I believe I created a website vs. a webapp or is it just a webservice using WCF?  I don’t really have a clue after banging my head so much– I’m using the WCF website I copied from PTracker for a winapp test window and the wcf proxy works fine.

If I had a WPF and a Silverlight implementation should I have separate WCF project/site?  Or can I have two different services?

I don’t even want to start having to think about what the different binding options are… I had wsHttp for nonSilverlight and now basicHttpBindings for Silverlight. 

Too many new things J

jack

I was ramming my head against a wall with a problem communicating to the host too. When I was establishing my projects based off the silverlight ones, I set the assembly name for each project (in properties of the project) to be what I was used to- CompanyName.Application.Client and CompanyName.Application.Server (for my client/silverlight class library and my server class library, respectively).

These need to be the same!! CompanyName.Application.Business is the route I took.

It's hardly obvious but I hope that's your problem!

Chris

I don’t know what all you did, so can’t offer an explanation.

The rules are relatively simple though.

Silverlight can talk to the site it came from with no extra effort.

If it needs to talk to another site, that site must have a cross domain policy file to allow the communication.

This is true for WCF, sockets, HTTP or any other server communication from Silverlight, and is a very necessary security precaution.

In development environments this can be confusing, because it is easy to forget that each instance of Cassini is a different site – http://localhost:1234 is different from http://localhost:6543.

And because Visual Studio will create a temporary website to host/debug your Silverlight app if the app is set as the startup project, it is terribly easy to accidentally end up in a cross domain scenario you didn’t expect. I realize you said this wasn’t your issue – but it is the most common issue.

The Rolodex app has two web sites: the one to host the SL app, and a separate one to host the server-side data portal components. The data portal host has a clientaccesspolicy.xml file to allow the SL app to interact with it. This was a conscious choice in implementing Rolodex, because it illustrates what I think will be a very common (perhaps the most common) scenario, where the web server and application server are separate machines.

Rocky

I definitely didn’t have the clientaccesspolicy.xml file or crossdomain.xml in the beginning but I did try copying them over – I just thought since I had the WCF working for the proxy from a winapp it would be a piece of cake J. 

I will likely not worry too much about it until it becomes time to deploy and then concentrate on making sure I understand.

Maybe it was the server address thing, although I was aware of it from the forum, I had the Rolodex working fine, and I was checking my taskbar to see the addresses.  Like anything when you are frantic and banging your head it’s likely that just starting from scratch would have done the trick.  It gets so confusing when you have 3 web.configs open at once plus alt-tab back to everything in VS for Rolodex and google + the CSLA forums open J.

Going forward – If I am using the WCF proxy from different UI’s, can they all communicate through the same webapp or is that just asking for trouble?

Thanks

jack

I don’t know what all you did, so can’t offer an explanation.

The rules are relatively simple though.

Silverlight can talk to the site it came from with no extra effort.

If it needs to talk to another site, that site must have a cross domain policy file to allow the communication.

This is true for WCF, sockets, HTTP or any other server communication from Silverlight, and is a very necessary security precaution.

In development environments this can be confusing, because it is easy to forget that each instance of Cassini is a different site – http://localhost:1234 is different from http://localhost:6543.

And because Visual Studio will create a temporary website to host/debug your Silverlight app if the app is set as the startup project, it is terribly easy to accidentally end up in a cross domain scenario you didn’t expect. I realize you said this wasn’t your issue – but it is the most common issue.

The Rolodex app has two web sites: the one to host the SL app, and a separate one to host the server-side data portal components. The data portal host has a clientaccesspolicy.xml file to allow the SL app to interact with it. This was a conscious choice in implementing Rolodex, because it illustrates what I think will be a very common (perhaps the most common) scenario, where the web server and application server are separate machines.

Rocky

The Silverlight data portal and .NET data portal are not the same. You can host both of them in the same virtual root, but they require different endpoints, and probably different WCF bindings.

The Silverlight data portal uses the MobileFormatter, and is designed specifically to support Silverlight clients. There is no .NET proxy for interacting with this type of host.

The .NET WcfHost in the data portal uses the NetDataContractSerializer, which doesn’t exist in Silverlight. It supports Windows clients (of all interface types), but won’t work with a Silverlight client.

Silverlight only works with the basicHttp binding in WCF, so the Silverlight WcfHost must use this binding.

Normally in .NET you’d use wsHttp binding because it offers more capabilities around security. I typically use this binding for Windows clients. basicHttp will work fine too, but you lose the more modern feature options.

Rocky

I definitely didn’t have the clientaccesspolicy.xml file or crossdomain.xml in the beginning but I did try copying them over – I just thought since I had the WCF working for the proxy from a winapp it would be a piece of cake J. 

I will likely not worry too much about it until it becomes time to deploy and then concentrate on making sure I understand.

Maybe it was the server address thing, although I was aware of it from the forum, I had the Rolodex working fine, and I was checking my taskbar to see the addresses.  Like anything when you are frantic and banging your head it’s likely that just starting from scratch would have done the trick.  It gets so confusing when you have 3 web.configs open at once plus alt-tab back to everything in VS for Rolodex and google + the CSLA forums open J.

Going forward – If I am using the WCF proxy from different UI’s, can they all communicate through the same webapp or is that just asking for trouble?

Thanks

Jack