Upgrading a 1.1 webservice to a 3.5 webservice

[Whiskey Romeo Lima]

I have a previous development environment on a XP machine using 1.1
..NetFramework and SQLServer 2000 and VS 2003. The code is gold.

I am now attempting to move those projects to a Vista machine, using 3.5 SP1
..NetFramework and SQLServer 2008. The windows application upgraded with
little problems. It depends on the webservice to interface with SQLServer.

The webservice and the windows application are separate solutions. Even
though the webservice appears to be set up correctly in IIS 7.0 (I can
navigate to it directly using IE and all the methods show), I cannot debug it.

I get this error when trying to access this line of code:

Private Sub SetAppData()
Dim ds As New DataSet
Dim rw As DataRow

ds.Merge(wsCommon.GetAppData) <--Errors here

Error Message:

Unable to automatically step into the server. Unable to determine a
stopping location. Verify symbols are loaded. Symbol not found:
DMSDataWS.wsCommon.GetAppData().

The webservice is located at http://localhost/dmsdataws/wscommon.asmx. The
only problem I encountered with the upgrade is that VS Studio 2008 and IIS
7.0 didn't seem to know what to do with the Global.asax file.

I appreciate any help on this.

 

[Whiskey Romeo Lima]

Thanks for replying. Unfortunately those steps did not change anything. The
only thing I can imagine are permissions within Vista but I am run VS 2008 as
administrator. So I am bufuddled.

wrl

 

[Mr. Arnold]

Thanks for replying. Unfortunately those steps did not change anything.
The
only thing I can imagine are permissions within Vista but I am run VS 2008
as
administrator. So I am bufuddled.

Are you running with elavated permissions using UAC with VS or using the
hidden admin account on Vista?




__________ Information from ESET NOD32 Antivirus, version of virus signature database 4235 (20090711) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

 

[Whiskey Romeo Lima]

Sorry for the delay in my response but the MSDN Newsgroups were unavailble
over the weekend. I am using the hidden Admin account when I run VS. It
should have been using my user account but instead it was the Network Service
account. It was indeed persmission problems. I found this out by unchecking
Show User Friendly Error messages in IE.

Once I gave that account permisions to folder and a login to the SQL Server
2008 and granted it permission to the database. Everything worked.

Which begs the question, how can I find out how an applications is
connecting to IIS and SQL Server ahead of time and how can I control it so it
will work on development machine (at home) and the production machine/network
(at my customer's network).

wrl

 

[Mr. Arnold]

Sorry for the delay in my response but the MSDN Newsgroups were unavailble
over the weekend. I am using the hidden Admin account when I run VS. It
should have been using my user account but instead it was the Network
Service
account. It was indeed persmission problems. I found this out by
unchecking
Show User Friendly Error messages in IE.

Once I gave that account permisions to folder and a login to the SQL
Server
2008 and granted it permission to the database. Everything worked.

Which begs the question, how can I find out how an applications is
connecting to IIS and SQL Server ahead of time and how can I control it so
it
will work on development machine (at home) and the production
machine/network
(at my customer's network).

If it were me, I would set up a test harness doing a functional test against
the backend. This can done without a UI and using a ClassLib project that
has a reference to a Web service or to a DAL, as an example. With the use
of Resharper, MBUnit and Gallio as tools to run the functional test with the
Classlib project against real references in the project, to test
connectivity from home or at the client's site, it could be tested that way.



__________ Information from ESET NOD32 Antivirus, version of virus signature database 4240 (20090713) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com