This blog post is NOT of general interest. I recently had to make changes to a web service that was written years ago by one of my employees. The ultimate goal was to change the application so that it would hit the service and the database running on the local machine instead of on different servers. I have never written a web service and I’ve never written an ASP.NET application. A figurative lost babe in the woods on this particular project. I didn’t figure things out on my own. I had help from the original developer, I don’t want to forget the lessons learned so I am documenting them here.
The first thing I did was take the folder for the web site from the server and moved it over to the target machine. IIS and SQL Server were both installed already on the target machine. I then launched the IIS management tool on the target machine and set up the just copied folder to be the default web site. This is a client machine and no other web site is going to run on it. I disabled the default site. I verified that the web service was available by launching a browser and navigating to http://localhost/nameofwebservicefile.asmx
When the list of web services showed up I knew the web server and the services were running correctly.
The first service that would need to work would be the GetUserInfo service as it was the gateway to the database. Clicking on the service allowed me to test the service.
Typing a valid username and password was not returning the expected results. I wanted to modify the web service to add some debugging messages. When I loaded the solution for the Client piece of the application things were pretty straight forward and it worked just like a normal WinForm application. The client piece is a winform application not an ASP.net application. However, loading the solution does not load the web service piece. I was able to use File->Open->Web Site option and navigate to the folder than contained. the *.asmx.cs file and App_Data and App_Code folders. This automatically created a solution for me. After making changes I would build the files. But this being a web service I was perplexed that I couldn’t find any files that were changed that seemed suitable for copying over to the target machine. It turns out I needed to use the Build->Publish web site option. The default build settings created the web site in the following path
C:\Users\*myUserName*\Documents\Visual Studio 2008\Projects\*MyServiceName*\PrecompiledWeb\*MySeriveName*\bin
Changes I made to the *asmx.cs files were precompiled into the bin folder in App_code.dll. I could then take this file and move it over to the target machine that was running the final application.
I modified the web service to return some debugging information, like the connection string and status of the connection and it became obvious that while the connection string was valid I was not connecting to the database. I then used Visual Studio to try and log in to the database directly. The SQL Server credentials did not work. I then tried logging in as a trusted domain user and that worked. A quick check of the database showed a couple of problems. First the user login credentials being used by the web service had to be added to the new SQL Server install (duh), and equally importantly the SQL Server by default was only allowing trusted connections. Right-clicking on the database and selection Properties brought up the dialog shown below where I could select the radio button for mixed mode authentication.
Now I could successfully run Test Connection from VS and the web service also started to work. Now back to the web service code and I could change the login string to point to “localhost” instead of the server for SQL Server. Then I needed to make the client application piece point to the local web server instead of the original IIS server.
The initialization piece of the main form of the winform application had the following line:
capServices_ = new CapClient.localhost.ClaimsAssistantProfessional();
Following this to the defintion (F12) took me to a References.cs file
The code had an assignment statement for a member field named Url which I was able to change from:
Url = “https://services.somedomainname.com”;
I built, moved the .exe and associated files over to the target machine and I was done. Of course that’s the Reader’s Digest condensed version and the actual process took about three days but that’s why I’m writing this down. The original solution also stored some of these hard-coded strings in configuration files but I just elided that detail to make some of the explanations simpler. I also had to configure SQL Server with a maintenance plan so that backups and integrity checks, optimizations etc. would all be run. The final step was to configure Carbonite to include files of type .bak. (Right click on a file of the type you are interested in, go to properties, use the Carbonite tab).