I'm submitting a request to a web service, but I'm receiving some errors. They've asked to see an example of the xml request and response. I used Visual Studio to consume the web service, so I'm just calling a method in my code - I don't actually see any xml.
Is there a way to grab the XML request and response as XML or at least a text string?
Thanks
The easiest way to do this is using a 3rd party tool, like Fiddler . You'll be glad you started using this tool anyway.
You could use Fiddler.
I had to debug what was going across the line recently and tools like wireshark and fiddler are great tools for debugging the request and response unless you are using HTTPS or you are debugging on your local machine and executing the client and the web service locally.
I found a method that allows you to see the details of both the request and response without having to modify a single line of your code.
.NET has a feature built in called tracing. By enabling tracing for the System.NET namespace you can capture everything.
Here are the steps to enable.
Add the following code to your app.config in your client applications.
<system.diagnostics>
<trace autoflush="true" />
<sources>
<source name="System.Net">
<listeners>
<add name="System.Net"/>
</listeners>
</source>
</sources>
<sharedListeners>
<add name="System.Net"
type="System.Diagnostics.TextWriterTraceListener"
initializeData="System.Net.trace.log" />
</sharedListeners>
<switches>
<add name="System.Net" value="Verbose" />
</switches>
</system.diagnostics>
Now when you execute your client application you can go into the folder that your executable was run from and find the file System.Net.trace.log
You will then find in the log file your request and the servers response. The great thing about this solution is you do not have to install or run anything extra. However the solution is probably only a solution for developing or diagnosing something in test or stage environment rather than production. However I am assuming because you mention creating the solution in Visual Studio and it not working that you are clearly in the development stage.
Related
I'm converting an old .NET WCF service to Web API 2
To maintain backwards compatibility I have applied a RoutePrefixAttribute to my controller as shown:
All has gone pretty smoothly until I try to publish my service and access it via IIS
When I run my service via localhost (debugged from Visual Studio) and make a request via Postman all is well and I get the expected response:
However, after I publish the site to IIS, set a host entry and try to access the same endpoint:
I receive a 404 not found:
I did some playing around, and decided to remove the ".svc" from my RoutePrefixAttribute for my Controller. And voila, I can now hit my endpoint via IIS:
So my question is: Does Web API 2 not support the ".svc" or even perhaps periods in their routes? Has anyone encountered something similar and found a reasonable workaround?
Thanks
My issue was as Kiran Challa indicated. I had to add the following line to my system.webServer handlers:
<system.webServer>
<handlers>
<add name="ApiURIs-ISAPI-Integrated-4.0" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
</handlers>
</system.webServer>
More information here: Dots in URL causes 404 with ASP.NET mvc and IIS
I have two different versions of a Silverlight 5 project using Ria services. Both work locally. The older version (A) works when deployed to ISS7. The new version (B) does not. There is user/password authentication that fails for version B with the error:
Load operation failed for query 'Login'. the remote server returned an error: NotFound.
Referencing various SO and MSDN posts over the past week, I have tried many troubleshooting techniques. Adding error logging as suggested here to the web.config results in the following being logged:
The service '/ClientBin/MyApp-Web-Services-AuthenticationService.svc' does not exist.
Researching that led to finding this forum post which suggests creating a dummy .svc file with the name/path it is looking for. The result:
The service '/ClientBin/DBCRM-Web-Services-AuthenticationService.svc' cannot be activated due to an exception during compilation. The exception message is: The ending bracket '>' for the 'ServiceHost' directive is missing in the '.svc' file..
The details of the above error aren't largely important as it was a blank .svc file I supplied. It merely served to confirm that fact that the project was indeed dependent on it
Here's the kicker... the working version DOES NOT contain this file either, yet it does not throw an exception.
Searching for any reference to needing the service surprisingly turned up a result in both solutions. Both MyApp.Web.g.csfiles are identical (ran a CSDiff) and both contain the line:
public AuthenticationContext() :
this(new WebDomainClient<IAuthenticationServiceContract>(new Uri("DBCRM-Web-Services-AuthenticationService.svc", UriKind.Relative)))
{
}
Both have the same package/deploy settings. I am deploying to a file system, then copying the files over to IIS on my host server.
Questions:
Where is a setting that makes this .svc file a requirement? It's clearly not needed in version A, but is in version B. Again, file MyApp.Web.g.csis the only reference to it, and it exists in both versions.
MyApp.Web.g.cs is a generated file. What service in Visual Studio 2010 creates this file? Also, can I modify it to not include the call to the .svc file in question?
I'm going to start merging the two solutions together to see at which point the .svc file becomes neccessary. Any ideas in the meantime would be greatly appreciated!
WCF Ria Services registers an HttpModule in order to manage the wcf ria services calls. When the request arrive to the server that module read the url and understand which service to instantiate and which method to call. So it's absolutely normal that you don't find any .svc file
Don't mess with the .g.cs your problem isn't here.
Take a look at your web.config file, you should find rows like this
<system.web>
<httpModules>
<add name="DomainServiceModule" type="System.ServiceModel.DomainServices.Hosting.DomainServiceHttpModule, System.ServiceModel.DomainServices.Hosting, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
</httpModules>
...
</system.web>
and this
<system.webServer>
<modules runAllManagedModulesForAllRequests="true">
<add name="DomainServiceModule" preCondition="managedHandler" type="System.ServiceModel.DomainServices.Hosting.DomainServiceHttpModule, System.ServiceModel.DomainServices.Hosting, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
</modules>
...
</system.webServer>
Besides making sure that the "DomainServiceModule" entries are present in Web.Config as stated above, another thing is that RIA requires ASP .NET compatibility mode to be enabled. Here is a link to Microsoft's deployment guide for RIA:
http://msdn.microsoft.com/en-us/library/ff426912(v=vs.91).aspx
In the third paragraph of the "Configure the Web Server" section, it states that you need the following in your Web.Config file:
<system.serviceModel>
...
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true" />
...
</system.serviceModel>
When this is missing, you get the behavior described in your question.
Before you do any of this make sure the regular bin folder is actually deployed containing your actual code.
I was deploying with MSDEPLOY to a new server and it did not deploy bin folder. You're not going to get anywhere without that!
I have a website which contains a small Silverlight plugin that calls a very simple WCF service to save values in Session.
It works fine on my PC and works ok only on my computer on the server (hosting provider). I noticed that for all machines that have Silverlight Developer Edition installed my Silverlight app works fine, however for all machines that have Silverlight Generic Edition installed my application fails when calling WCF service with the following message:
Additional information: [MessageXmlProtocolError]
Arguments:
Debugging resource strings are unavailable. Often the key and arguments provide sufficient information to diagnose the...
I have crossdomain.xml and clientaccesspolicy.xml files in place which should be correct and I am using basicHttpBinding with no security. Also, there is no issues with developer editions. Can anyone help? (Silverlight version = 4)
The issue is that the response received is not what the WCF service was expecting. From the MSDN documentation, MessageXmlProtocolError is:
"A problem occurred with the XML that was received from the network. See the inner exception for more details."
This means that you need to see what the inner exception is in order to determine the actual cause.
If the WCF service is hosted in IIS on a specific URL, it could be that the senders are not authorized to access that URL in the web site. We've had this issue more than once.
Ways to help troubleshoot the problem include:
1) Install the SDK on a computer having the problems to see if you can get the full exception.
2) Use WCF tracing by adding a block like the following to your web.config (assuming the WCF service is hosted in IIS):
<system.diagnostics>
<sources>
<source name="System.ServiceModel"
switchValue="Information, ActivityTracing"
propagateActivity="true">
<listeners>
<add name="traceListener"
type="System.Diagnostics.XmlWriterTraceListener"
initializeData="c:\log\WebTrace.svclog" />
</listeners>
</source>
</sources>
</system.diagnostics>
3) Use a tool like fiddler to trace the request and response from the WCF client to see if you can track down the issue.
I just added some code that changes wcf service url to make sure it runs on the correct server. This fixed the problem
We have a site running on MOSS 2007 which makes calls to custom web service asmx methods on the same domain from the client.
At first everything works fine, but after a bit of time has passed the service will start to fail with:
http://[domain]/_layouts/error.aspx?ErrorText=Request format is unrecognized for URL unexpectedly ending in %27%2FIsSuspectWaterLevel%27.
Interestingly enough
http://[Domain]/_vti_bin/Custom/CustomFunctionality.asmx?op=IsSuspectWaterLevel
is still available, but a call to
http://[Domain]/_vti_bin/Custom/CustomFunctionality.asmx/IsSuspectWaterLevel
will fail as described.
We've found that "touching" C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\ISAPI\ web.config will bring the webservice back to life.
The asmx file lives at
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\ISAPI\ECan\MyECan_ComplianceWaterUsage.asmx
Any ideas of what might be going on here and how to resolve them?
Some extra detail:
App pool settings in case they're useful: http://i51.tinypic.com/x51qw.png
The following web.config settings are present in the root and sub directory hosting the asmx:
<system.web>
<webServices>
<protocols>
<add name="HttpSoap" />
<add name="HttpGet" />
<add name="HttpPost" />
</protocols>
</webServices>
...
</system.web>
We are calling the web service from javascript (jQuery). I've checked all the settings mentioned in this link and all match. I think calling from javascript may not be the culprit though as going directly to
[domain]/_vti_bin/Custom/CustomFunctionality.asmx/IsSuspectWaterLevel
with parameters supplied also fails with the same error - no javascript involved. Failing after a short period of time has passed, but works fine when web.config has just been "touched" again.
Thanks in advance for any help! Cheers, Gavin
I'm currently working on the same problem, and I think you barked the wrong tree.
The problem is, that in the ISAPI folder of SharePoint is a web.config with the following lines:
<webServices>
<protocols>
<remove name="HttpGet"/>
<remove name="HttpPost"/>
<remove name="HttpPostLocalhost"/>
<add name="Documentation"/>
</protocols>
</webServices>
The problem is, that the desired protocols POST and GET will be removed for the entire ISAPI folder and its subfolders. I also tried to reactivate the protocols via
<location path="[Path to my Web Service].asmx" allowOverride="false">
<webServices>
<protocols>
<add name="HttpGet"/>
<add name="HttpPost"/>
</protocols>
</webServices>
</loaction>
in different places (machine.config, web.config of root folder, web.config app.config, ...), but it didn't last.
The only thing that worked, was, to change the "remove" items in the web.config of the ISAPI folder to "add" items.
But this has the nasty side effect, that the built-in web services, like "Lists.asmx" throw errors if you try to request their documentation pages...
If you can live with that, this would be your solution. I can't, so I still try to figure out a way to make my
<add name="protocol">
items persistent.
By the way: Also adding lockItem="true" to the <add/> items didn't do the trick...
Chris
It has been awhile since I have touched Sharepoint so this is a shot in the dark. If I remember correctly modifying anything in the web.config will restart the website in IIS. So what you may be seeing is IIS restarting the website that hosts the webservice putting it back into a good state.
Do you have the following in the web.config for the web application?
<webServices>
<protocols>
<add name="HttpGet"/>
<add name="HttpPost"/>
</protocols>
</webServices>
This is a strange problem and hard to diagnose due to the number of occcurances of the 12 hives web.config protocols issue which would appear to resolve 99% of the cases of this issue.
There is another issue called URL rewriting that will cause this
problem.
Some reverse proxy devices can modify the path of a request (the
portion of the URL that comes after the hostname and port number) in
such a way that a request sent by the user to
http://www.contoso.com/sharepoint/default.aspx, for example, is
forwarded to the Web server as
http://sharepoint.perimeter.example.com/default.aspx.
This is referred to as an asymmetrical path. Windows SharePoint
Services 3.0 does not support asymmetrical paths. The path of the URL
must be symmetrical between the public URL and the internal URL. In
the preceding example, this means that the "/sharepoint/default.aspx"
portion of the URL must not be modified by the reverse proxy device.
Even more depressing is that microsoft knows about this and actively refuses to support it.
Ref: URL Rewrite + SharePoint = No Support
Also : SharePoint, url rewriter, WebServices
An inelegant workaround to this issue that works for us: We've swapped out the web service asmx end point for a web handler ashx endpoint. This doesn't suffer the same issue for some reason.
I'm guessing from this that there's some issue creeping in after a period of time which is causing urls to resolve incorrectly. I suspect that the / after the .asmx in the url is the curprit. The ashx endpoint implemented is working purely on url parameters and posted data.
Obviously this work around won't always be an option for others who might experience the same issue as we're loosing a lot of the rich web service functionality that's pre-baked in to an asmx endpoint.
Unfortunately I won't be able to test any other solutions that people might put forward from now on as we've moved away from the web service asmx approach. Sorry. Thanks for all the suggestions though - it's been very much appreciated!
I have a WCF service than in my development and production environments works without any trouble but in my test environment it will occasionally throw a CommunicationObjectFaultedException. This has been very difficult to track down but it seems to happen only after going a long time with out calling it.
The client is a web applictaion running on two load balanced servers, the WCF service is hosted in IIS and running on two load balanced servers.
There is no difference in the WCF configuration between the three environments so I believe there must be something different in the way the servers are set up. What are some things I can ask my server admins to check? (I don't have proper access to these servers to check stuff myself).
You may want to enable tracing on the server in order to get more detailed error information. Can you ask your admins to enable that?
<configuration>
<system.diagnostics>
<sources>
<source name="System.ServiceModel"
switchValue="Information, ActivityTracing"
propagateActivity="true">
<listeners>
<add name="traceListener"
type="System.Diagnostics.XmlWriterTraceListener"
initializeData= "c:\log\Traces.svclog" />
</listeners>
</source>
</sources>
</system.diagnostics>
</configuration>
MSDN link here. I'll update my answer for any additional information you can post.
Good luck!