How does Silverlight find its Web service when the latter is in an assembly? [SOLVED]
-
I've been trying to figure out how Silverlight communicates with a WCF Web service when the VS2010 Silverlight solution is set up as an ASP.NET Web Application Project rather than an ASP.NET Web Site. As you know, when you set up a Web Application Project, the Web service is generated as a .dll assembly rather than a set of loose .cs files that are supposed to be compiled once, when the Website is first accessed. But when the solution is set up as a Web Application Project, the service is encapsulated in a dll assembly. In my case, the service is in a DLL called PPTWebsite.Web.dll. When I build the solution, the Silverlight application is also wrapped in a xap file called PPTWebsite.xap and from what I've read, the xap file and the WCF Web service assembly have to be in the same folder on the Website, and further, the xap file has to be in the ClientBin folder off the root of the Website, so that's also where the PPTWebsite.Web.dll file must be located. (I've tried putting the xap file in the root of the Website and that doesn't work at all.) When I build my solution, a .svc file also gets created that identifies the location of the C# source file containing my Web service. This .svc file must be in the root of the Website and contains the following line:
<%@ ServiceHost Language="C#" Debug="true" Service="PPTWebsite.Web.PHDWebsiteService" CodeBehind="~/ClientBin/PHDWebsiteService.svc.cs" >
What confuses me is that the value of CodeBehind points to the C# source file containing the source of my service implementation but doesn't identify the assembly containing its CIL code. So: how does the Silverlight application know where the code for the Web service is stored when it makes calls to it? I should also make clear that I have no problem communicating with the Web service when I execute everything from within VS2010. Everything is working perfectly when executed within the IDE. The reason this is an issue is because when I deploy everything to the actual Website, the Silverlight application is not communicating with the Web service. I know this is true because I stripped down one of the services to a one line function that simply returns true and when the Silverlight event handler gets control it immediately throws an exception with the text, "The remote server returned an error: NotFound." (Google for that text and you will get thousands of hits on forums like this one, and the scary part is that most of the reported problems never seem to get resolved
-
I've been trying to figure out how Silverlight communicates with a WCF Web service when the VS2010 Silverlight solution is set up as an ASP.NET Web Application Project rather than an ASP.NET Web Site. As you know, when you set up a Web Application Project, the Web service is generated as a .dll assembly rather than a set of loose .cs files that are supposed to be compiled once, when the Website is first accessed. But when the solution is set up as a Web Application Project, the service is encapsulated in a dll assembly. In my case, the service is in a DLL called PPTWebsite.Web.dll. When I build the solution, the Silverlight application is also wrapped in a xap file called PPTWebsite.xap and from what I've read, the xap file and the WCF Web service assembly have to be in the same folder on the Website, and further, the xap file has to be in the ClientBin folder off the root of the Website, so that's also where the PPTWebsite.Web.dll file must be located. (I've tried putting the xap file in the root of the Website and that doesn't work at all.) When I build my solution, a .svc file also gets created that identifies the location of the C# source file containing my Web service. This .svc file must be in the root of the Website and contains the following line:
<%@ ServiceHost Language="C#" Debug="true" Service="PPTWebsite.Web.PHDWebsiteService" CodeBehind="~/ClientBin/PHDWebsiteService.svc.cs" >
What confuses me is that the value of CodeBehind points to the C# source file containing the source of my service implementation but doesn't identify the assembly containing its CIL code. So: how does the Silverlight application know where the code for the Web service is stored when it makes calls to it? I should also make clear that I have no problem communicating with the Web service when I execute everything from within VS2010. Everything is working perfectly when executed within the IDE. The reason this is an issue is because when I deploy everything to the actual Website, the Silverlight application is not communicating with the Web service. I know this is true because I stripped down one of the services to a one line function that simply returns true and when the Silverlight event handler gets control it immediately throws an exception with the text, "The remote server returned an error: NotFound." (Google for that text and you will get thousands of hits on forums like this one, and the scary part is that most of the reported problems never seem to get resolved
-
Not sure what your question is - the ServiceReferences.ClientConfig file contains information that is used to find the web service. Hope that helps.
Abhinav S wrote:
Not sure what your question is
I tried to make that clear by displaying my question in italics: how does the Silverlight application know where the code for the Web service is stored when it makes calls to it?
Abhinav S wrote:
the ServiceReferences.ClientConfig file contains information that is used to find the web service.
The ServiceReferences.ClientConfig file has a client endpoint element defined which of course has an address attribute. Since making my first post in this thread I've been trying to figure out the answer to my question myself. As near as I can figure out, the service needs to be in a folder named bin that is relative to the endpoint address. When VS2010 makes a new Silveright Web Application project, it places the .svc in the root of localhost, or the root of your project. Then when you build the project, the service assembly winds up in the bin folder off the .Web project. So presumably when you deploy all this to a live Website, the .svc file goes into the root of the Website and the service assembly goes into a directory called bin that lies off the root of the Website. So I did this and now for the first time since I tried accessing my service from the Website itself, everything works! I've been pulling my hair out over this for two extremely frustrating and depressing weeks and was ready to bring a consulting firm into my house for $250 an hour to solve my problem. I suspected it would only taken an expert five minutes to find out what was wrong because my Web Application project had no problem at all contacting my service when everything was run from my local PC. And I was right! Once I understood what is written in the previous paragraph, it took me all of two minutes to solve my problem! Judging from the number of unanswered threads about this on the Web, there seems to be a huge problem of being able to contact the service perfectly fine when the project is executed from within VS2010 and failing miserably when it is deployed to the live Website. Tons of unanswered questions are out there! I really feel for all these people, because until this morning I've been suffering from the same misery for the last two weeks! However, even though my real concern is now satisfied, I'm not going to mark this thread as SOLVED because my question wasn't "how do I connect to my service when it is located in my li
-
I've been trying to figure out how Silverlight communicates with a WCF Web service when the VS2010 Silverlight solution is set up as an ASP.NET Web Application Project rather than an ASP.NET Web Site. As you know, when you set up a Web Application Project, the Web service is generated as a .dll assembly rather than a set of loose .cs files that are supposed to be compiled once, when the Website is first accessed. But when the solution is set up as a Web Application Project, the service is encapsulated in a dll assembly. In my case, the service is in a DLL called PPTWebsite.Web.dll. When I build the solution, the Silverlight application is also wrapped in a xap file called PPTWebsite.xap and from what I've read, the xap file and the WCF Web service assembly have to be in the same folder on the Website, and further, the xap file has to be in the ClientBin folder off the root of the Website, so that's also where the PPTWebsite.Web.dll file must be located. (I've tried putting the xap file in the root of the Website and that doesn't work at all.) When I build my solution, a .svc file also gets created that identifies the location of the C# source file containing my Web service. This .svc file must be in the root of the Website and contains the following line:
<%@ ServiceHost Language="C#" Debug="true" Service="PPTWebsite.Web.PHDWebsiteService" CodeBehind="~/ClientBin/PHDWebsiteService.svc.cs" >
What confuses me is that the value of CodeBehind points to the C# source file containing the source of my service implementation but doesn't identify the assembly containing its CIL code. So: how does the Silverlight application know where the code for the Web service is stored when it makes calls to it? I should also make clear that I have no problem communicating with the Web service when I execute everything from within VS2010. Everything is working perfectly when executed within the IDE. The reason this is an issue is because when I deploy everything to the actual Website, the Silverlight application is not communicating with the Web service. I know this is true because I stripped down one of the services to a one line function that simply returns true and when the Silverlight event handler gets control it immediately throws an exception with the text, "The remote server returned an error: NotFound." (Google for that text and you will get thousands of hits on forums like this one, and the scary part is that most of the reported problems never seem to get resolved
Did you try removing the CodeBehind attribute? Its probably not even needed since the Service attribute specifies the namespace and class of the code. It says Service instead of Assembly because the @ directive just points to the service class, not a different assembly from the rest of the project. I haven't used a WCF service in a long time so take this with a grain of salt.
-
Did you try removing the CodeBehind attribute? Its probably not even needed since the Service attribute specifies the namespace and class of the code. It says Service instead of Assembly because the @ directive just points to the service class, not a different assembly from the rest of the project. I haven't used a WCF service in a long time so take this with a grain of salt.
shiznit770 wrote:
Did you try removing the CodeBehind attribute? Its probably not even needed since the Service attribute specifies the namespace and class of the code. It says Service instead of Assembly because the @ directive just points to the service class, not a different assembly from the rest of the project.
I just tried removing the CodeBehind attribute and the Silverlight application still correctly accessed the service. So you're absolutely correct. It plays no part in finding the service.