My project in Visual studio 2013 consumes Acumatica web service APIs on another server. I had no problem with adding web reference and calling Acumatica web service API in my code, until recently I added new API into the web service in Acumatica, and then tried to update web service reference in my project. I right clicked on "web service" in Visual studio and then click on "update web reference" to update, however, I was still getting the old APIs, even though I used exactly same URL. I put the URL in browser and I could see the new APIs but when I tried to update, I just couldn't get them into Visual Studio.
When I put that URL into browser to view the WSDL XML, I noticed I only got new APIs after I logged into Acumatica and I was getting old APIs before I logged in. It seems Acumatica only sends updated WSDL xml after users log in, which causes problem to Visual Studio, since there is no way to log in first in Visual studio.
Actually I had successfully updated my web reference before, but almost every time I tried to update reference, I got this problem, then after keeping trying many times, the reference eventually got updated...but this time, the problem seems to just hang on there and doesn't go...
By the way, I tried to go to command line to use wsdl.exe to generate reference class but still got old APIs.
I just don't understand why Acumatica requires logging in to give out new APIs...
If anybody could give me any clue to solve this problem, that would be really appreciated.
(Converting my solution from a comment to an answer)
I believe the Visual Studio GUI frontend for wsdl.exe does allow you to perform a login action (by showing a WebBrowser control) prior to downloading the .wsdl file, but in the event that doesn't work you can always manually download the .wsdl via your desktop browser and then invoke wsdl.exe from the command-line, providing the downloaded file as a command-line argument.
Related
Summary:
I have an Office 365 E3 account where I'm trying to deploy a Word task pane app that will read some SharePoint list data. Right now, I'm just trying to get the task pane app to load, however, it shows the Office 365 login page (in the pane) but does not do anything after clicking Login.
Details:
I went through the instructions provided here:
http://msdn.microsoft.com/en-us/library/office/fp179815.aspx
Basically, I create an App for SharePoint configured as SharePoint-hosted, then in the same project, added an App for Office (Task Pane App for Word only). The SharePoint app also has a custom document library.
I am able to install the app to my App Catalog, and it correctly shows up in Site Contents where I see it being provisioned to the app web. I can also launch Word 2013 with the Trusted App Catalog configured correctly, and I am able to see my Task Pane App and insert it. When I click Insert, it loads it but prompts for credentials.
I am using the same credentials all throughout this exercise so by virtue of being able to install and deploy the SharePoint app, you can trust that I'm providing the right credentials.
It also appears the custom document library is never created - I wonder if both suffer from the same underlying issue.
I encountered the same problem and the solution provided in the answer below did not help.
After some desparation i created a taskpane app using the Napa Cloud App, opened the application in Visual Studio and went looking for differences.
In the Taskpane app manifest.xml file i found the following entries which were missing in my own application manifest:
<AppDomains>
<AppDomain>https://login.microsoftonline-int.com</AppDomain>
<AppDomain>https://login.microsoftonline.com</AppDomain>
</AppDomains>
This solved my problem and cured one horrible friday.
I was able to get this to work. It turns out doing a Deploy from Visual Studio (whether you right-clicked Deploy or F5-debug), the installation of the app isn't enough.
To make it work, I skipped doing a Deploy all together, but instead published my app. I then took the .app file and loaded it in my App Packages folder, and then deployed it from there.
Unfortunately, I don't know the difference between the two, but I'm assuming it has something to do with provisioning the app web for the Office App.
After a Windows 7 fresh restart, I open the Visual Studio 2010 as administrator, create a new project of Windows Azure Project with ASP.NET Web Role, then at the WebRole1 project I add a WebService1.asmx and press F5 (run).
The Windows Azure services starts OK and the browser open the http:/127.0.0.1:8080/WebService1.asmx perfectly. But when I click at Invoke button to test the webservice method I always receive a Bad Request - Invalid Hostname, with a http:/127.0.0.1:8081/WebService1.asmx/HelloWorld.
The most likely cause is ASMX's WSDL file doesn't stand by load balanced environment such as Windows Azure. The test feature relies on WSDL. You will see similar issues if you add a web/service reference. It is recommended to upgrade to WCF. In WCF, you can use useRequestHeadersForMetadataAddress (http://msdn.microsoft.com/en-us/library/ee816894.aspx) to fix the issue. If you need to use ASMX, please try to manually provide a correct WSDL file.
No matter what I change in an asmx service in Visual Studio, the WSDL file stays always the same. Deleting methods, changing method signatures don't have any effect when I browse to service definition.
I have had a simular problem.
When removing an enum and replacing it by a string, the enum wouldn't go away from the wsdl. No matter what I tried (clean, rebuild, clear browser cache, other browser), it kept returning the enum as a complex type within the WSDL.
The solution in my case was remove the local folders of the project via windows explorer, then perform a get latest from TFS. After this the problem was solved.
Of course this solution only aplies when using a sourcecontrol system.
After changing your service, you must build it and ensure that the new version is running. One shortcut would be to build it (and make sure there are no errors), then right-click the .ASMX file and choose "View in Browser".
Also, although I'm sure you're aware of it, you should not be using ASMX web services for new development. Microsoft now considers ASMX to be a legacy technology. Use WCF instead.
I have encountered this problem and have a solution.
Cause: When you create a new "Web Service" project in Visual Studio, it automatically adds a "Service1.asmx" file to your project. You rename this file and change the class declaration inside of it, but Studio still thinks it's "Service1" wnd will only ever display the web service definition for "Service1".
Solution:
Delete all "bin" and "obj" folders in your project.
Copy the methods from your existing asmx file to notepad.
Remove the service from your project.
Add a new service to your project, with the name you want.
Paste the code from Notepad into the new service.
Rebuild All
Your asmx should now accurately reflect your web service and update normally on future builds.
I had today the very same issue. It was caused by a GACed version of the assembly that contained the type definitions exposed by the web service. I had to remove the assembly from the Global Assembly Cache first, like:
"C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\gacutil.exe" /u YourAssemblyNameWithouthDllExtebsion /f
Be sure to restart the web server hosting the web service to reload the new version of the assembly, for example, in case of IIS Express, you can kill the former process instance by PowerShell:
(Get-Process -Name iisexpress).Kill()
After that, the updated WSDL version was displayed as expected.
I am working on a Pocket PC 2003 application that is referencing a Webservice.
I was figuring out ways to debug the Webmethods but not successful.
-I checked the URL property of the Service in WebReferences and made sure it is correct.
-I started debugging the PocketPC application, then built the Webservice as start without debugging, after that went to Debuh> Attach process and attached devenv-"Pocket PC app"
-I also tried attaching to the aspwp.exe process but couldn't seem to hit the break points in Web Methods.
-The webservice is deployed to IIS virtual directory.
-I copy pasted the entire webservice folder in the virtual directory. Then I am opening the solution file in Visual Studio. Start without debugging, when the webmethods show in browser, click on it, then click Invoke
Can someone guide me the proper way to debug a Webservice of this type? Thanks in advance.
If you're using Visual Studio 2005 or higher, instead of IIS, use the toy Web service that comes with Visual Studio. In the properties of your ASP.NET project with the Web services, under "Web", check the "Use Visual Stuidio Development server". In order to make the toy server start, you have so start the ASP.NET project from Visual Studio.
Then you attach to the process called Webdev.Webserver.exe using Managed code debugging.
I deployed a web service to iis 7, it was working all the way right.
Then I wanted to update the code of a web method in the web service.
I recompiled the service and updated the dll in the iis directory with the new one.
My problem is when I invoke the service, it invokes the older code.
I tried changing the number of parameters passed to a web method inside the service, and when invoking it still sees the older parameters which I erased.
Web services after Framework 2.0, are compiled as DLL files by default as far as I know. Normally, this happens when you PUBLISH the website and webservice, or when you use Web Applications.. But in WebServices, Visual Studio compiles the output as DLL. Therefore, you should compile your dll and update on the IIS. Even though you see the CS code files on IIS folder, they are not being used. Only the asmx file (not asmx.cs) are used to map the code in the dll.
I am guessing that the old code is cached. Try restarting IIS. That should cleanup any remnants of the old code.
It seems that you need to update your service reference.
Go to the project who's using the service, left-click the service reference in your solution explorer and finally choose "Update Service Reference".
Maybe I'm wrong and you did it, but as you don't mention that in your question, this is my suggestion.
rebuild the solution, And deploy the service on IIS. It will work definitily