I created an ASP.NET REST service (using WCF) and access it through one of my .aspx page.
the problem is that when I publish (precomile) my code to the web server, I get an error :
"ThunServ not defined" in the Javascript console of my browser.
don't know what's causing it and how to solve it.
It means that the WCF service isn't initializing correctly, and so the client-side object that represents it isn't being created in Javascript.
Make sure your web.config contains the proper bindings and endpoints for the service. Then try testing its ASMX file on the server to see if you can get the client-side script to generate, e.g. http://myserver/myapp/myservice.asmx/js. If it doesn't generate, you should get an error (you'll need to turn on debugging in the web.config to read it) telling you what went wrong.
Related
I have access to WSDL file of a specific web service that contains a SendData method - basically I specify the TimeStamp and Value to be send. I uploaded the WSDL file to my project in Visual Studio 2019 as a connected service (Add->Connected Service->Microsoft WCF Web Service Reference Provider->Browse->I added location of the WSDL file and specified the service that included SendData method). After that I created a new client:
ServiceSoapClient client = new ServiceSoapClient(ServiceSoapClient.EndpointConfiguration.ServiceSoap);
added credentials (the web service requires login):
client.ClientCredentials.UserName.UserName = "test"; client.ClientCredentials.UserName.Password = "test";
created a new variable Data that contains TimeStamp and Value (in a specific format required by the method).
After that I invoked the method:
client.SendData(Data);
but it doesn't work. There are no errors or exceptions thrown, but the Data is not visible on the web service (the web service also has a GUI). I started to wonder if it is possible to send data to a web service in such a way or is it maybe necessary to create an xml file with a request and use HttpWebRequest?
Perhaps someone could help me figure out what is wrong, is there a way to check, what is going on during compilation? Unfortunately, I cannot include the URI or WSDL file, but hopefully my description of the issue will be sufficient. Thanks in advance for any guidance!
Okay, with the suggestion from Robert Harvey (thank you once again) and some trial and error I managed to solve my problem. Hopefully my answer will be useful to someone with the similar issue.
I found out that in some cases WCF web service's calls are not visible in Fiddler. In my case it was due to some packages not being up-to-date. These out-of-date packages were added automatically after connecting the web service via Microsoft WCF Web Service Reference Provider.
System.ServiceModel.Duplex/Http/NetTcp/Security all were installed in version 4.4 instead of 4.7. I updated them using Project->Manage NuGet Packages and now my requests are visible in Fiddler and I managed to verify that the way I used my method was correct, but the access to the web service (with the ability to save data) is currently limited, that is why the result was not visible directly on the web service (in the GUI).
I am working on a project where a webservice is referenced. I can resolve and add the webservice reference to the project, update it and etc. without issue. I can also paste the URL of the webservice in my browser and have it resolved to see the public methods.
However when I publish the webservice to Azure it consistently fails saying that there is no endpoint and/or the address cannot be resolved.
After trying numerous methods of troubleshooting the issue and modifying different sections of my configuration file as it pertains to the webservice; I figured I'd try accessing the service from outside of my work domain.
When I pasted the URL into a browser from my home I received a "Page cannot be found" error.
I then attempted to resolve the URL from within VS from my home system and I received the same error that Azure has been throwing regarding no endpoint and that the URL could not be resolved.
In the past when I've worked with Webservices, I've always been able to resolve the services from my work or home environment so this is a first for me.
I know that methods within a service can be publicly exposed or hidden but can the actual WebService be made inaccessible to the public as well? And if so, would the "No endpoint" message be the typical result?
I am working with the classic WebService model (asmx) not WCF. If that really makes any difference.
This is going to be a bit long so please bear with me.
I have been beating my head against this issue for quite some time. I am not very experienced in web services from a client and am having real issues setting this up. What I have is a web service from a third part hosted on a site. The service is a WSDL service written in JAVA. I am trying to connect to it from y .NET solution and consume the web services provided. One of the requirements from the vendor is to "set the Headers parameter to 'XXXX' and the value to 'YYYY'"
I am having some serious issues doing this. My first attempt was to simply add the web service as a web reference in Visual Studio (2012). There were no methods exposed by the service to set the header so I simply called a function to see what happened. I received an exception "No SOAP Headers specified".
Next I attempted to create a manual proxy using SVCUTIL.exe. I think there may be something wrong with the web services because I receive errors "Cannot import wsdl:binding": "Detail: The required WSDL extension element 'binding' from namespace 'http://schemas.xmlsoap.org/wsdl/http/' was not handled."
However, the class and config files are still created. Anyways, I imported the class into my web app and updated my web.config with the necessary settings from the proxy config. I declare an instance of the needed class and this is where things go south for this attempt. When declaring an instance of the class I receive the error "could not find default end point element that references contract "ContractName" in the ServiceModel client configuration. This might be because no endpoint element matching this contract could be found in the client element". I am wondering if perhaps there is a problem with the services or they simply weren't designed for .NET. The other obvious option is I am doing something wrong. I would be happy to post the config file and such if you would like to see it (I just felt I had loaded this post enough as it is).
What I am really looking for is instructions (a tutorial would be awesome) on how to add a web service as a reference within Visual Studio c# application but being able to set the headers from within the code.
I am sorry for the length of this post.
Thank you for your help.
I hav a C# web application. In that I have added a WCF Service file (.svc) by Right Click project Add New Item >> WCF Service (wcfService.svc). ( Now I have IwcfService.cs and wcfService.cs in my App_Code folder) And also added a function WCFXmlData(string id) inside that.
I am trying to access the function inside wcf service file from an ajax call in my application (in an aspx file).
But I am not able to do that.
Also I tried to browse this .svc file directly. There I got a message like Metadata publishing for this service is currently disabled.
That really depends on your binding, if you use the WebHttpBinding you can simple access the data via a browser. In best case you should modify your contract in such a way that it returns JSON, this is less overhead than XML or even SOAP (which uses also XML).
It your webpage is also implemented in the webservice you have nothing special to care about, but if your service runs under another subdomain you need to implement JSONP or Cross-Origin Resource Sharing (CORS) to manage cross domain calls.
I started learning web services. I learnt about web services, UDDI, WSDL, SOAP etc. and architecture of web services. Visual Studio is running the service in local system successfully.
Then I deployed the entire folder of that web service in IIS wwwroot, and tested. Its running successfully.
But when I remove the other file from the wwwroot\webService1 folder (I left only service1.asmx and bin folder) then also service is running.
Here I see that only two file are used in ruuning the webservice one is .asmx and another one is webService.dll in bin folder.
I'm not able to understand where is SOAP, WSDL, namespace or other things, that are required to run web service.
Please clarify.
SOAP, WSDL, Namespace are all handled by IIS and ASP.NET. In your scenario, your web service endpoint is your asmx file (no .cs file required in your deployment), and the DLL in the bin folder contains the code that you wrote for your webservice (so it does something).
If you call up your webservice in a web browser, you should see your web methods listed out to test. IIS knows how to process *.asmx files to do this. If you click on one, you should see a sample form (if input parameters are expected) and a button. Again, IIS knows how to serve this out to you. When you click the button, IIS and ASP.NET handle the work of SOAPing your request, handling it with your code, and SOAPing the response back to you.
If you create a "test" project in Visual Studio, and set a web service reference that points to your deployed web service, Visual Studio will create a proxy class and pull in some additional code from it's discovery of the service. Try it. You should get at least: a WSDL which defines your web service, a file called reference.cs which contains the code that does the heavy lifting of calling your webservice (SOAPing the request from your application and unSOAPing from the response).
If you download a tool called Fiddler, you should be able to intercept and inspect the SOAP call to your web service.
Take a look at Web Services with ASP.NET for additional information.
There are no such 'files' at all. The asmx and dll files contain all of the code for the service. You can see some of that in the URLs that are requested for the SOAP/WSDL info.
I believe if you append ?WSDL after .asmx you will see the definitions.
Such as this example:
WSDL Example
I think these are protocols and does not require anything. IIS and the requesting applications understand these protocols.