Web Config problem

  • Thread starter Thread starter bob
  • Start date Start date
B

bob

Hi,
I have a web app that feeds off two web services.
Been working for a while and hasn't had any development activity for
months.
Went to fire up the solution in the IDE and found it was broken.
The web app could access the small web service (A logon Facility) but
couldn't access the large web service (business logic)

Anyway I found that the IDE had decided on a new port for running the
business logic webservice.
So I altered the web reference Web reference URL Property to match the
new Port number
and the solution worked again in the IDE.

Didn't think much about it after that.

Published the app and the services onto production server.
The web app consumes the Log On web service OK but attempt on business
logic service fails with:

No connection could be made because the target machine actively
refused it 127.0.0.1:54642

54642 is the new port number that the IDE decided to use when running.

The web.config file for the web application looks good to me.

<applicationSettings>
<wbTracker.Properties.Settings>
<setting name="wbTracker_Tracker_wsTracker"
serializeAs="String">
<value>http://localhost/wsTracker/Tracker.asmx</value>
</setting>
<setting name="wbTracker_TrackLogon_TrackLogon"
serializeAs="String">
<value>http://localhost/wsTrackLogon/TrackLogon.asmx</value>
</setting>
</wbTracker.Properties.Settings>
</applicationSettings>


The Tracker.asmx wsdl is accessible from a web browser both internally
and externally and a simple test function invokes OK internally.

Any thoughts on how to sort this out would be appreciated.
thanks
Bob
 
bob said:
Hi,
I have a web app that feeds off two web services.
Been working for a while and hasn't had any development activity for
months.
Went to fire up the solution in the IDE and found it was broken.
The web app could access the small web service (A logon Facility) but
couldn't access the large web service (business logic)

Anyway I found that the IDE had decided on a new port for running the
business logic webservice.
Click to expand...

No, the IDE decided nothing here unless it was told. It maybe that the
Web service no longer had a virtual directory on your machine pointing
to the port it was originally assigned maybe 80, as opposed to the logon
service that had a virtual directory pointing to port 80 which is why
one worked unchanged and the other one had to be change on the port.

So I altered the web reference Web reference URL Property to match the
new Port number
and the solution worked again in the IDE.

Didn't think much about it after that.

Published the app and the services onto production server.
The web app consumes the Log On web service OK but attempt on business
logic service fails with:
Click to expand...

The above Web service on the production server may have the Web service
listening on a different port. I don't know what the port would have
been in production, but I would assume it was port 80 as to why the
login service is still working unchanged.
No connection could be made because the target machine actively
refused it 127.0.0.1:54642
Click to expand...

You told the IDE in the development environment that the service is
listening on the above port 54642, which changed the port number away
from 80 possibly with 80 being the default.
54642 is the new port number that the IDE decided to use when running.
Click to expand...

The IDE VS development Web server is used at times in this situation.
The web.config file for the web application looks good to me.

<applicationSettings>
<wbTracker.Properties.Settings>
<setting name="wbTracker_Tracker_wsTracker"
serializeAs="String">
<value>http://localhost/wsTracker/Tracker.asmx</value>
</setting>
<setting name="wbTracker_TrackLogon_TrackLogon"
serializeAs="String">
<value>http://localhost/wsTrackLogon/TrackLogon.asmx</value>
</setting>
</wbTracker.Properties.Settings>
</applicationSettings>


The Tracker.asmx wsdl is accessible from a web browser both internally
and externally and a simple test function invokes OK internally.

Any thoughts on how to sort this out would be appreciated.
thanks
Bob
Click to expand...

The URL below would be the value that needs to be in the Web config,
which the url can be entered into a browser address line to see of the
Web service is listening on the port.

http://localhost:54642/wsTracker/Tracker.asmx.

However, it wouldn't be localhost if the Web service was running on a
production Web server. It would be the IP of the Web server machine.

The way the URL is in the Web.config of the following.....

http://localhost/wsTracker/Tracker.asmx

It was originally listening on port 80 because the URL doesn't have
:NNNN showing the port number, which 80 is the default, when the
solution was originally developed.

And why you have to change it is because the solution running on your
Web server machine doesn't match production anymore of it knowing it was
originally suppose to be on port 80.

If the Web service references were updated in the project that consumed
the Web service in question, then the Web.config and references to the
service would have been changed pointing to the right port.
 
Hello,
No connection could be made because the target machine actively
refused it 127.0.0.1:54642
Click to expand...

You referenced a service hosted on your development machine using the
development web server (that uses a dynamic port by default). Obviously it
doesn't work any more in production.

Which kind of service it is ? WCF or ASMX ? You could alter likely change
the url inside the config file. Another option would be to have some logic
in the code to decide which url should be targeted (it seems this is the
local machine ?).

As a side note it seems you are consuming the service from the same web
application that hosts the service, you could also call directly the
underlying function exposed by your service without going through the
additional web service layer (that is usefull only when called from another
machine)...
 
Hi Mr A,
Thank you for your reply.
Found it.
Typo in Web.config
Too much coffee, not enough brains
thanks
Bob
 
Back
Top