VB.net response.write question

Poster Steven Estes question- *How many Web Sites Could There Be. * Reminded me about how many very sharp people are on this board.

I don’t have the code in front of me, but am working with jquery/AJAX javascript and VB. Working in VS2015.

My problem is working with WCF.

Here we go -

Client javascript calls aspx.vb. VB code behind calls a WCF data contract that returns data from an SQL data base. A VB function returns serialized XML to the response.write that should return it directly to the calling javascript to be processed.

It fails. No exceptions, no errors, nothing.

This code works fine when I just pass a string of XML and avoid the WCF call. I can pass the EXACT same string of data as the WCF creates and it works.

I THINK that when the aspx.vb code behind calls a WCF data contract using https to a different server, the response.write is redirected to the recent WCF.dll call instead of the client javascript that originally called the aspx page.

This code has worked perfectly for years using a call to a database and serializing that. I suspect that the call to an https WCF data contract is confusing the response.write. The response.write is sending the XML back to the WCF .dll instead of the original client javascript function that called it.

? Would/Could that be the issue why response.write is not calling the original javascript?

Do you have WCF logging turned on? It’s pretty easy to do, and you get incredibly verbose logs. That would allow you to at least determine if your theory that the response is going to the WCF service is correct.

Here’s how to turn on WCF logging.

One caveat - wherever the log file is written needs to be accessible to the account the service is running under. That’s bitten me multiple times. Not puting a path in the log file specification is the easiest way to ensure this doesn’t happen.

Are you able to browse to the WSDL for the WCF service from the server hosting the web site?
If so, then look into the service bindings. WCF has a myriad of transport security options that may, or may not be accepting the request from the web server.
If not, determine why your web server can’t browse to the service, or ensure that the service is running properly.

Unfortunately, I did not write the WCF. And the fellow that did is gone for a week. I don’t have access to it to turn on the call logging. That’s a good link though. Thanks.

I was basically given the code and asked to insert into my 10,000 lines of code. We are going to WCF to prevent SQL injection attacks (currently my code uses inline SQL). Fortunately, this is completely in development/testing mode. I’m just a bit stuck.

The WCF service is running fine and returning the data that I need.

I’ll try to clarify/simplify. It’s kinda hard to explain.

[ol]
[li]Client javascript calls Server aspx.vb code behind.[/li][li]aspx.vb code behind reads http request from client javascript and calls a function that exists on the same aspx.vb page that the client javascript called. That function performs the WCF call to a different server.[/li][li]The WCF function uses an https URL for the reference to the WCF code on a different server. WCF returns data.[/li][li]Then the aspx.vb code behind accepts the data from the function that contains the WCF call and uses response.write to pass the XML back to javascript on client.[/li][/ol]

The above is what is supposed to happen.

If I skip step three where WCF makes the https call and just insert my own test XML string for the response.write, it works fine. The client javascript gets called by the response.write and my test XML is passed to it.

If I allow vb.net code behind to make the https call to WCF, the response.write ‘fails’ I have that in air quotes because I don’t get an exception or error. It’s just that nothing happens. I think that when the aspx.vb makes the https WCF call (step three above), response.write loses the path to the original calling client javascript, and responds to the WCF https URL instead of the client javascript.

I’m thinking that maybe if I put the function that calls the WCF in a different aspx.vb page, then the response.write might keep the proper path back to the client. Don’t know.

I am a .NET dev with 16 years experience; albeit almost all in C#.Net

Your question is a little unclear (even after restating it) but there is no way that the WCF call would cause the loss of the path back to the client - unless you are starting up a new thread (which is extremely unlikely to do by mistake)

So it seems that the function that calls the WCF service is not returning the required XML. You’ve stated that it is working if you “hard code” the XML as the return value of this function, right?

I take it you are using Visual Studio and using debugging breakpoints? Are you seeing an XML response from the WCF call in the debug window?

I am going to say that the function that calls WCF is at fault; further I will wager that it is a Config setting, because you say the WSDL is available in a browser.

I think FordPrefect’s advice is a good place to start.
Oh, and moving the function to another .aspx.vb class won’t make any difference; your code behind as is does just two jobs. No point in over-complicating it.

On further read: it seems you tested by hard coding the XML into the “response.write” function that is called via javascript.

Try moving that to the function that calls the WCF instead; and check the XML is actually being returned to the function that calls it.

Can you post the code snippet where the call is being made? That could expose the issue.

I agree that one should look for the results of the WCF call in the debugging, and also that it is most likely a config issue, and also that it is difficult to lose the path to the client.

One way to make sure of this however is to both make the WCF call and hardcode the response in the aspx.vb. If you comment out the call to the WCF and it works, and then put the WCF back in and it doesn’t work, even though you are just calling it and then throwing away the data, then something weird is going on.

Yep, something weird is going on. I’ve tested just what you suggest -

If I make the call to the WCF and throw the returned data away and pass hard coded XML with the response.write it does not work.

If I don’t make the call to the WCF and pass hard coded XML with the response.write it does work.

(this is why I’m thinking about putting the WCF call in a different aspx.vb page, perhaps I won’t lose the path for the response.write [I’m running out of ideas on what to test])

When I make the WCF call, It really seems like it makes the response.write lose contact with the client.

The WCF call does return data. No problems there. I’ve tested taking the serialzer function out of the loop too. I’ve stripped things down to the barest of bones to try to figure this out. My try/catch is not throwing any exceptions when this fails, that’s why I think the response.write is being redirected to the WCF https. And unfortunately, I don’t have access to turn logging on for the WCF code for at least a week.

It’s interesting (in a bang your head on the keyboard kind of way). I want to thank everyone for their input. I won’s be able to test anything more until tomorrow, Monday 2/19

I think a view of the code that makes the WCF call and returns the response is needed here. It seems that the current website session is being lost/dropped/reused when you make the call to the WCF service, when instead the call from the web server to the web service should be a new session for that request. Typically, that just happens by default but perhaps something is wonky with the code?

I’ll post the code tomorrow. I will strip it down further to make it easier to follow. Of course I will test it before I post the code and I’ll include inline comments. Should only be about 50 lines of code.

It’s very, very strange, and hard to debug since no exceptions are being thrown.

I do wonder if there is a ‘retain’ property that needs to be set for the response.write method that needs to be set in the web.config file. I can’t find anything though.

Thank you again.

I have a link to the code below. It’s just a text file.

Thanks, still stuck.

I discovered that response has an isConnected property that returns true/false if connected to a client.

If I make the call to the WCF service, it gets set to false. So that’s pretty definitive. It’s definitely losing its connection to the client.

Thinking that perhaps if I put the function that calls the WCF in a different class in the App_Code folder, the response.write may retain its path to the calling client.

I haven’t worked with VB.NET or WCF directly in a long time, however, I have been involved tangentially with an MVC 2 project written in VB.NET calling WCF and I have access to the source, I am going to take a look tomorrow and refresh my memory. But given the code you’ve provided, I don’t see anything on the face of it that would cause the execution of methods in dataRetrievalService to overwrite the Page.Response object. Unless there is some freaky-ass magic going on in the newed up SCG_WCFChannelFactory.

Moving the WCF calling code to a different class and calling that from the ownerSearchList should make zero difference from what you have currently, unless there is some freaky ass shit going on. Like global/static variables being assigned the current page or something like that.

In your ownerSearchList method, can you replace:
AssessorSearchByOwnerResultsForGISList = dataRetrievalService.GetAssessorRealPropertySearchByOwnerLastNameForGIS(“SMITH”)
with
System.Diagnostics.Debug.WriteLine( dataRetrievalService.GetAssessorRealPropertySearchByOwnerLastNameForGIS(“SMITH”))

and see the expected results in the debug window?

I can make the replace to System.Diagnostics.Debug.WriteLine( dataRetrievalService.GetAssessorRealPropertySearchByOwnerLastNameForGIS(“SMITH”))

[sub]Just to mention it again-[/sub]
The WCF AssessorSearchByOwnerResultsForGISList = dataRetrievalService.GetAssessorRealPropertySearchByOwnerLastNameForGIS(“SMITH”) returns exactly what I need. I can cut and paste the returned data into a respose.write string and it works. The response.write only loses the client connection when I make the https call to the WCF.

There are no global variables being set. The code I linked is bare bones test code.

I thought that getting the WCF https call off of the aspx.vb page that makes the response.write back to the client may allow the response.write connection back to the client to persist. The call to the WCF service is breaking the connection to the client.

Thanks for your help, I’ll try a few things tomorrow and get back.

I feel like an idiot… got sidetracked by the Response object when it sounds like the web service call is returning before it is complete.

Check out this link:
https://forums.asp.net/t/1338972.aspx?How+to+call+a+WCF+service+asynchronously+from+ASP+NET+page+

Hey Ford, it sounds like you think that the response.write is firing before the WCF call is complete?

That’s not happening. The WCF call is in a function that returns the XML to a sub routine that then processes the response.write.

I can take the data returned from the WCF, save it, comment out the WCF call and paste the data into the response.write just as a string and it works fine.