Deployment of Silverlight App + Silverlight-Enabled WCF... RSS

• 

  Dengue

  Member

  2 Points

  1 Post

  • Reply
  •  

  Re: Re: Re: Re: Re: Deployment of Silverlight App + Silverlight-Enabled WCF Service to Production

  Apr 10, 2010 09:34 AM | LINK

  The thread is really long but I've got something to add as well. First of all, the best method that worked for me was (IIS 6.0 - prod, VS 2008 SP1 - dev): System.ServiceModel.BasicHttpBinding binding = new System.ServiceModel.BasicHttpBinding(); System.ServiceModel.EndpointAddress address = new System.ServiceModel.EndpointAddress(new Uri(Application.Current.Host.Source, "../YourService.svc")); MathServiceReference.MathServiceClient MathClient = new MathServiceReference.MathServiceClient(binding, address); HOWEVER! it works only with data not exceeding 64k!!! And THAT what causes the exception. To change this value you need to add this code: binding.MaxReceivedMessageSize = 2147483647; I didn't try a bigger value, because this one worked for me. Bare in mind that it may cause some security flaws leading to DoS attacks vulnerability.
• 

  hiteshspatel

  Member

  9 Points

  17 Posts

  • Reply
  •  

  Re: Re: Deployment of Silverlight App + Silverlight-Enabled WCF Service to Production

  Apr 20, 2010 06:33 PM | LINK

  Thank you GearWorld for posting the link..... You saved my time and my A??......lol.... Thanks a lot....

  Thanks Sladapter- the Rank 1 guy..... for giving the coding hint to set the endpoint dynamically.........

  Special thanks to both of you......

• 

  BirdWareDele...

  Member

  4 Points

  4 Posts

  • Reply
  •  

  Re: Re: Deployment of Silverlight App + Silverlight-Enabled WCF Service to Production

  Dec 10, 2010 04:49 PM | LINK

  Thanks a lot for the tips, I created a factory class with your code suggestions to instantiate my silverlight webservice client.
  

  And it worked first time.
  

• 

  Tanneeru

  Member

  37 Points

  60 Posts

  • Reply
  •  

  Re: Deployment of Silverlight App + Silverlight-Enabled WCF Service to Production

  Jun 02, 2011 09:52 AM | LINK

  Hi,

  I am trying to deploy a Silverlight application (4.0) which also contains Silverlight enable WCF Service. The deployment went well and able to run the applciation, after running the application if any action is trying to access wcf service then i am getting this error

  the service callis not working, giving error.

  It looks like error in Silverlight.js file

  Error :

  Message: Unhandled Error in Silverlight Application [Async_ExceptionOccurred]
  Arguments:
  Debugging resource strings are unavailable. Often the key and arguments provide sufficient information to diagnose the problem. See http://go.microsoft.com/fwlink/?linkid=106663&Version=4.0.60310.0&File=System.dll&Key=Async_ExceptionOccurred   at System.ComponentModel.AsyncCompletedEventArgs.RaiseExceptionIfNecessary()
     at SilverlightApplication2.ServiceReference1.DoWorkCompletedEventArgs.get_Result()
     at SilverlightApplication2.MainPage.objMyServiceClient_DoWorkCompleted(Object sender, DoWorkCompletedEventArgs e)
     at SilverlightApplication2.ServiceReference1.MyServiceClient.OnDoWorkCompleted(Object state)
  Line: 1
  Char: 1
  Code: 0
  URI: http://localhost/Trideo/Silverlight.js

  
  

  
  

  
  

  Deployment Issues -- silverlight on IIS

  Raju Tanneeru
• 

  suhasharidas

  Member

  4 Points

  2 Posts

  • Reply
  •  

  Re: Deployment of Silverlight App + Silverlight-Enabled WCF Service to Production

  Oct 28, 2011 05:53 AM | LINK

  Deploying Silverlight with WCF Services

  So I know that this topic is nothing new, however, this is still one of the most common deployment issues that people ask me about. That being the case, I decided to add a post on the topic to demonstrate my approach.

  I love the work the Silverlight team has put in to generating client stubs for web services. It was not that long ago that I was having to write out all of those stubs and I’m glad to be done with it. However, there is one piece of the puzzle that seams to be missing from the solution: smooth deployment of the Silverlight application and the WCF services.

  Setting up Our Project

  To get started on the topic, let’s begin by setting up a project so we can look at what is going on under the hood.

  Start by creating a new “Silverlight Application” in Visual Studio 2010. When creating the project, make sure you have the following two options set: “Host the Silverlight application in a new Web site” and do not check the “Enable WCF RIA Services”.

  

  We are not enabling RIA on this project simply to keep the solution clean and focus our WCF services.

  Once your project is created, add a new “Silverlight-enabled WCF Service” (I called mine MyService.svc) to our Web project.

  

  If you open up the new service, you will find there is a sample “

  DoWork

  ” method already created for you to demonstrate how to set up methods in your service. For our purposes, we are just going to modify that method a bit to return a

  string

  .

  [OperationContract]
  public string DoWork()
  {
      // Add your operation implementation here     return "Hello from My WCF Service";
  }

  I know, nothing too terribly exciting, but it will work for our purposes.

  Reminder:

  Anytime you add a new service to your web project or make a modification to the structure of it (i.e. add/change the method signatures), you need to recompile the web project prior to adding/changing the service in the Silverlight application.

  Once we compile our Web project, we can move on to adding our new WCF service to the Silverlight application. To do that, right-click on the Silverlight Project and select “Add Service Reference”. Once the service dialog box comes up, click the “Discover” button and you should see your service in the list.

  

  After giving your service a namespace and selecting “OK”, there are several things that get added to your project. Most of the items can be found if you expand the service reference that was added to your project. In addition, you will notice a “

  ServiceReferences.ClientConfig

  ” file added to your project. Don’t forget about this file, because we will be coming back to this file in a minute.

  The last thing that we need to add to our project, to make it test worthy, is some sort of interaction with our service. If you remember, our service simply returns a

  string

  . So, our nice and complicated UI is going to consist of a

  TextBlock

  :

  <Grid x:Name="LayoutRoot" Background="White">
      <TextBlock x:Name="txtMsg"
                 HorizontalAlignment="Center"
                 VerticalAlignment="Center"/>
  </Grid>

  Thanks to all of the plumbing that is done for us, it is a rather straight forward process to call our new service in code.

  public partial class MainPage : UserControl
  {
      public MainPage()
      {
          InitializeComponent();
          Loaded += new RoutedEventHandler(MainPage_Loaded);
      }
  
      void MainPage_Loaded(object sender, RoutedEventArgs e)
      {
          MyServiceClient client = new MyServiceClient();
  
          client.DoWorkCompleted +=
              new EventHandler<DoWorkCompletedEventArgs>
                              (client_DoWorkCompleted);
          client.DoWorkAsync();
      }
  
      void client_DoWorkCompleted(object sender,
                                  DoWorkCompletedEventArgs e)
      {
          txtMsg.Text = e.Result;
      }
  }

  This code simply creates a client to our service and calls our one method. Once the service returns, we are simply displaying the results in our

  TextBlock

  .

  And that is that. You should be able to compile and run your application and get back something like this:

  

  Deploying the Project

  Now that we have our new Silverlight application, we simply can’t wait to deploy it and show off our new Silverlight skills to all of our friends. So you deploy the project to your IIS server, launch the site, and….. it breaks…

  You have to love it when that happens…

  So why won’t it deploy? What could be so different between your IIS box and your development box? The answer lies in that “ServiceReferences.ClientConfig” file. Yep, the same one I told you we would come back to in a minute.

  Let’s have a look at it real quick:

  <configuration>
      <system.serviceModel>
          <bindings>
              <customBinding>
                  <binding name="MyServiceCustom">
                      <binaryMessageEncoding />
                      <httpTransport maxReceivedMessageSize="2147483647"
                                     maxBufferSize="2147483647" />
                  </binding>
              </customBinding>
          </bindings>
          <client>
              <endpoint address="http://localhost:40228/MyService.svc"
                        binding="customBinding"
                        bindingConfiguration="MyServiceCustom"
                        contract="MyService.MyService"
                  name="MyServiceCustom" />
          </client>
      </system.serviceModel>
  </configuration>

  The culprit is the endpoint address. When you create a service client, it defaults to the address that is listed here (which, more than likely, is not the same location that you deployed it to). Any time that you create a service client in your code, using the default constructor, this is the location that it assumes the service is at.

  So now we know where the problem lies, how do we fix it?

  The Solution…

  Now the first temptation is to simply update the address to point to the appropriate location. While this will fix your problem, it’s really not the cleanest approach. The first issue you run into, is you will need to remember to change it between the development and the production versions. In addition, any time the URL changes to your application (whether you move it, rename the site, etc.), you will have to go in and update this location. The first and only time I went this route, it bit me several times.

  A more forgiving approach is to look at the constructor of our service client. Instead of using the default constructor, which uses the default location, we are going to dynamically assign our service location.

  [Note: In addition to assigning the location of the service, you can also set all of the endpoint and binding information that is defined in our

  ClientConfig

  ]

  There are a couple of different approaches you can take here. However, most of the information in our

  ClientConfig

  I don’t want to have to change or assign in code. So I simply want to update the address of our service and use the rest of the defaults that are assigned in the

  ClientConfig

  .

  Before we can do that, there is one piece of information that we need to add to our web service in the web.config.

  We need to add a name to the endpoint of our service on the server. This will allow us to reference the correct endpoint. Here is what you will need to add:

  

  Once you have done that, then head back over the our MainPage.xaml.cs, where we called our service client. Instead of using the default constructor, we are going to use the following:

  Uri servUri = new Uri("../MyService.svc", UriKind.Relative);
  EndpointAddress servAddr = new EndpointAddress(servUri);
  MyServiceClient client = new MyServiceClient("MyServiceCustom", servAddr );

  The constructor that we used for the client has two properties. The first is the

  endPointConfigurationName

  , which is what we added to our endpoint in the web.config.

  The second is the location to our service, which is defined as an

  EndpointAddress

  .

• 

  suhasharidas

  Member

  4 Points

  2 Posts

  • Reply
  •  

  Re: Deployment of Silverlight App + Silverlight-Enabled WCF Service to Production

  Oct 28, 2011 05:57 AM | LINK

  Deploying Silverlight with WCF Services

  So I know that this topic is nothing new, however, this is still one of the most common deployment issues that people ask me about. That being the case, I decided to add a post on the topic to demonstrate my approach.

  I love the work the Silverlight team has put in to generating client stubs for web services. It was not that long ago that I was having to write out all of those stubs and I’m glad to be done with it. However, there is one piece of the puzzle that seams to be missing from the solution: smooth deployment of the Silverlight application and the WCF services.

  Setting up Our Project

  To get started on the topic, let’s begin by setting up a project so we can look at what is going on under the hood.

  Start by creating a new “Silverlight Application” in Visual Studio 2010. When creating the project, make sure you have the following two options set: “Host the Silverlight application in a new Web site” and do not check the “Enable WCF RIA Services”.

  

  We are not enabling RIA on this project simply to keep the solution clean and focus our WCF services.

  Once your project is created, add a new “Silverlight-enabled WCF Service” (I called mine MyService.svc) to our Web project.

  

  If you open up the new service, you will find there is a sample “

  DoWork

  ” method already created for you to demonstrate how to set up methods in your service. For our purposes, we are just going to modify that method a bit to return a

  string

  .

  [OperationContract]
  public string DoWork()
  {
      // Add your operation implementation here     return "Hello from My WCF Service";
  }

  I know, nothing too terribly exciting, but it will work for our purposes.

  Reminder:

  Anytime you add a new service to your web project or make a modification to the structure of it (i.e. add/change the method signatures), you need to recompile the web project prior to adding/changing the service in the Silverlight application.

  Once we compile our Web project, we can move on to adding our new WCF service to the Silverlight application. To do that, right-click on the Silverlight Project and select “Add Service Reference”. Once the service dialog box comes up, click the “Discover” button and you should see your service in the list.

  

  After giving your service a namespace and selecting “OK”, there are several things that get added to your project. Most of the items can be found if you expand the service reference that was added to your project. In addition, you will notice a “

  ServiceReferences.ClientConfig

  ” file added to your project. Don’t forget about this file, because we will be coming back to this file in a minute.

  The last thing that we need to add to our project, to make it test worthy, is some sort of interaction with our service. If you remember, our service simply returns a

  string

  . So, our nice and complicated UI is going to consist of a

  TextBlock

  :

  <Grid x:Name="LayoutRoot" Background="White">
      <TextBlock x:Name="txtMsg"
                 HorizontalAlignment="Center"
                 VerticalAlignment="Center"/>
  </Grid>

  Thanks to all of the plumbing that is done for us, it is a rather straight forward process to call our new service in code.

  public partial class MainPage : UserControl
  {
      public MainPage()
      {
          InitializeComponent();
          Loaded += new RoutedEventHandler(MainPage_Loaded);
      }
  
      void MainPage_Loaded(object sender, RoutedEventArgs e)
      {
          MyServiceClient client = new MyServiceClient();
  
          client.DoWorkCompleted +=
              new EventHandler<DoWorkCompletedEventArgs>
                              (client_DoWorkCompleted);
          client.DoWorkAsync();
      }
  
      void client_DoWorkCompleted(object sender,
                                  DoWorkCompletedEventArgs e)
      {
          txtMsg.Text = e.Result;
      }
  }

  This code simply creates a client to our service and calls our one method. Once the service returns, we are simply displaying the results in our

  TextBlock

  .

  And that is that. You should be able to compile and run your application and get back something like this:

  

  Deploying the Project

  Now that we have our new Silverlight application, we simply can’t wait to deploy it and show off our new Silverlight skills to all of our friends. So you deploy the project to your IIS server, launch the site, and….. it breaks…

  You have to love it when that happens…

  So why won’t it deploy? What could be so different between your IIS box and your development box? The answer lies in that “ServiceReferences.ClientConfig” file. Yep, the same one I told you we would come back to in a minute.

  Let’s have a look at it real quick:

  <configuration>
      <system.serviceModel>
          <bindings>
              <customBinding>
                  <binding name="MyServiceCustom">
                      <binaryMessageEncoding />
                      <httpTransport maxReceivedMessageSize="2147483647"
                                     maxBufferSize="2147483647" />
                  </binding>
              </customBinding>
          </bindings>
          <client>
              <endpoint address="http://localhost:40228/MyService.svc"
                        binding="customBinding"
                        bindingConfiguration="MyServiceCustom"
                        contract="MyService.MyService"
                  name="MyServiceCustom" />
          </client>
      </system.serviceModel>
  </configuration>

  The culprit is the endpoint address. When you create a service client, it defaults to the address that is listed here (which, more than likely, is not the same location that you deployed it to). Any time that you create a service client in your code, using the default constructor, this is the location that it assumes the service is at.

  So now we know where the problem lies, how do we fix it?

  The Solution…

  Now the first temptation is to simply update the address to point to the appropriate location. While this will fix your problem, it’s really not the cleanest approach. The first issue you run into, is you will need to remember to change it between the development and the production versions. In addition, any time the URL changes to your application (whether you move it, rename the site, etc.), you will have to go in and update this location. The first and only time I went this route, it bit me several times.

  A more forgiving approach is to look at the constructor of our service client. Instead of using the default constructor, which uses the default location, we are going to dynamically assign our service location.

  [Note: In addition to assigning the location of the service, you can also set all of the endpoint and binding information that is defined in our

  ClientConfig

  ]

  There are a couple of different approaches you can take here. However, most of the information in our

  ClientConfig

  I don’t want to have to change or assign in code. So I simply want to update the address of our service and use the rest of the defaults that are assigned in the

  ClientConfig

  .

  Before we can do that, there is one piece of information that we need to add to our web service in the web.config.

  We need to add a name to the endpoint of our service on the server. This will allow us to reference the correct endpoint. Here is what you will need to add:

  

  Once you have done that, then head back over the our MainPage.xaml.cs, where we called our service client. Instead of using the default constructor, we are going to use the following:

  Uri servUri = new Uri("../MyService.svc", UriKind.Relative);
  EndpointAddress servAddr = new EndpointAddress(servUri);
  MyServiceClient client = new MyServiceClient("MyServiceCustom", servAddr );

  The constructor that we used for the client has two properties. The first is the

  endPointConfigurationName

  , which is what we added to our endpoint in the web.config.

  The second is the location to our service, which is defined as an

  EndpointAddress

  .

• 

  Henning Fles...

  Member

  2 Points

  1 Post

  • Reply
  •  

  Re: Deployment of Silverlight App + Silverlight-Enabled WCF Service to Production

  Jan 04, 2012 08:38 PM | LINK

  Your proposal solved my problem with my WCF service.

  I see the same problem with the authentication service, but I have no idea how to apply your solution to the authentication service.

  Any idea?

• 

  DamienDunphy

  Member

  4 Points

  3 Posts

  • Reply
  •  

  Re: Deployment of Silverlight App + Silverlight-Enabled WCF Service to Production

  Feb 22, 2012 05:56 AM | LINK

  Guys I found I had to add the following code to make this work. Basically detect if it's debugging or deployed at runtime:

              if (HtmlPage.Document.DocumentUri.ToString().StartsWith("file"))
              {
                  QGlobals.Service = new OperionServiceClient();
              }
              else
              {
                  Uri baseAddressData = new Uri(Application.Current.Host.Source, "/OperionWCFService/Operion.svc");
                  string test = Application.Current.Host.Source.AbsolutePath + " : " + Application.Current.Host.Source.AbsoluteUri + " : " + baseAddressData;
                  QGlobals.Service = new OperionServiceClient("BasicHTTP", baseAddressData.AbsolutePath);
              }