Windows Server 2003 (IIS 6) Visual Studio 2008 .NET FrameWork 3.5 SP1
I am a .NET developer for a living and I have over 40 hours in the problem
Project type = "Silverlight Navigation Application", "APS.NET Web Site" (when I tried it as "ASP.NET Web Application Project" I could not copy it to the production web site - well I could copy it but I could not make it run) Created a service.cs on the .Web side of the application.
Created a reference to that service.cs on the Silverlight side. For a time all is good as I can reference the service as localhost:port (e.g. localhost:1374) in Visual Studio and debug both Silverlight side and service.cs To access the application in production mode (from IE) I update the service refrence and replace localhost:port with the IP address. The problem with the IP address is I cannot debug the service.cs so I have to change it back to localhost:port to debug. Now to the problem. After a period of time localhost:port just plain breaks.
I get an error message no service at the other end Yes I know the port can change - that is not the problem - the port on the service side just plain breaks!
For example from Visual Studio from the Silverlight side of the project right click "Service Reference", "Add Service Reverence". It finds 1 service in the application on a port. But when I click that service under "Services:" in the modal dialog box "Add Service Reference" I get an error: There was an error downloading 'http://localhost:1377/SehaleCSS.Web/Service.svc'.
The request failed with the error message: -- Could not load file or assembly 'App_Web_tipnndfq, If I go back to the IP address the service is repsponding (with the right answer)
The service just plain goes a while responding to localhost:port and then fails Even making NO change to service.cs it go a while then fails as a localhost:port It is not IIS environmental as I can go back to a prior saved version of the code and it works Something is happening that the .web side of the application is failing. It still works as an IP and it still exposes itself as a localhost:port but it fails to properly repsonde as a localhost:port.