Some of you may have come across an issue when developing ‘fast and dirty’ demo apps in Silverlight that have a WCF backend service on the web application.
When developing throwaway demo apps for clients, you need to take all of the shortcuts you can get, so I always use the ‘Add service reference’ feature of Visual Studio to add a service reference within my Silverlight app to the host ASP.NET service (not advisable for production-quality apps though). This is a great feature because as you change the service interface you can keep in sync on your Silverlight app using a single service ‘Update’ button.
However, the big drawback of this approach is that the Visual Studio tool that creates the service reference hard-codes the service Uri into the generated classes.
If you were just using Visual Studio then this wouldn't be a problem, but unfortunately VS and Blend use different development servers that cannot co-exist on the same TCP port, so for one of the two development environments the Uri of the service is going to be wrong.
for example, you create the service reference in Visual Studio, which is configured to run the website on url ‘http://localhost:43667/DemoApp’ , then the hard-coded Uri for the service will be something like ‘http://localhost:43667/DemoApp/Service1.svc’.
However, Expression Blend will always run the solution on a different port, so it will run the app on a base url of something like ‘http://localhost:52234/DemoApp/’ which means that the Silverlight app wont access the service and your app will not be able to access the service when run from Blend.
Your gut reaction might be to try the following:
- Fix the port in Visual Studio to be the same as the one in Blend. – This wont work because Blend will detect VS is on it’s preferred port and will automatically switch to an alternative port.
- Use your local version of IIS to avoid the clash of the ports. – This will work but doesn’t really fit in with the idea of creating a portable throwaway demo app.
- Work in both VS and Blend, but only press F5 while in VS. This works but is a pain in the butt.
- Play with crossdomain policy files etc. – Not really a solution, especially as VS always tears-down the dev server when in DEBUG mode.
However, there is a solution for this scenario that only requires changing a single line of code to your Silverlight project.
Below is the some ‘Before’ sample code
private void PageLoaded(object sender, RoutedEventArgs e)
{
var service = new Service1Client();
service.DoWorkCompleted += (source, args) => MessageBox.Show("DONE");
service.DoWorkAsync();
}
And now here is the same code with an added line that fixes this issue.
private void PageLoaded(object sender, RoutedEventArgs e)
{
var service = new Service1Client(new BasicHttpBinding(BasicHttpSecurityMode.None),
new EndpointAddress(Application.Current.Host.Source.AbsoluteUri.Replace(
Application.Current.Host.Source.AbsolutePath,"/Service1.svc")));
service.DoWorkCompleted += (source, args) => MessageBox.Show("DONE");
service.DoWorkAsync();
}
Basically, we’ve just changed the way we’ve constructed the service object, and passed in the necessary parameters to make the service reference relative rather than absolute. (You may need to replace the ‘Service1.svc’ parameter with one that is relevant to your project).
This is a neat little code snippet to keep on hand when developing these kinds of apps
I hope this helps you fix this annoying issue in your Silverlight development.
If you have any further suggestions then let me know.
Dean