I have a reference to a web service written in java. I need to use it in my BizTalk project. So I add the reference via Add Service Reference - Advanced - Add Web Reference since java web service is not a WCF service. OK, VS generates for me XSDs and ODX for the service. But when I try to compile the project, I get very weird error "Missing partial modifier on declaration of type XXX; another partial declaration of this type exists". The same error is described here.
I thought that I'd missed something so I created a brand new solution, added there a Console Application, added the web reference and that solution builded successfully. Thus I can conclude that I get the error only if I add a web service reference in BizTalk solution.
I tried to fix the error manually, opened the Reference.map.cs file, added ".Biztalk" suffix to the generated namespace and everything compiled successfully. Is it really a bug in code generator for BizTalk project or am I missing something?
Not sure, I have never seen that error...
However, what I would do is create a class library project and add the web reference here. You can then use this in the SOAP send port, as described here (see point #5). You can also reference the class library in your BizTalk project directly. Since you said that the web reference works in a Console application, perhaps this could work...
Also, you could use the XSD schemas directly - but this will require more work. You will have to promote a couple of properties manually in an orchestration or custom pipeline component. You can find more details on this post (website is currently down, but hopefully will be back online eventually).
Finally, you could also try the WCF adapter, using the httpBinding. That's designed for interop and should work as long as you have the schemas to define the messages.
Good luck!
Related
It seems that most of the new kids on the block are using RESTful web services rather than SOAP. I've only dabbled in them enough to know the basics of how they work.
Essentially in a SOAP implimentation, you are able to use a WSDL file that describes data types as well as usable RPC's. Finding a WSDL file and simply adding it as a service reference in visual studio is awesome and easy to impliment.
In a REST web service you have one (or more, depending on overrides) method for each action you are wanting to take (GET, POST, PUT, DELETE). While I can see how this would be beneficial, I can see problems with this... such as still having to deserialize into a local object.
So my question is... can you actually get intellisense when consuming REST web services? When you add a service reference to a WSDL you are able to see the list of usable methods. Otherwise, is the only way to actually see the usable methods through documentation? Is there any "self-containing" document that describes to VS what you can use and/or how to interpret data types without having to deserialize/serialize.
What is the reason why hitting, for example, http:///_vti_bin/UserGroup.asmx?wsdl gives me a not full wsdl specification (if compared with http://msdn.microsoft.com/en-us/library/dd965659%28v=office.12%29.aspx)?
What I mean about not full: it does not contain some of complex types definition, e.g. User (unlike the full one), so this types are no generated by the wsdl.exe.
I have a question in regard of this: is it safe to generate c# web service stub basing on specification from MSDN or this approach is dangerous due to possible changes in contract?
For your first question as to the WSDL not being the same: it really should be equivalent and contain all the types! Whenever you append /_vti_bin/UserGroup.asmx?wsdl to your site's URL, SharePoint should definitely display the FULL WSDL, including the complex type definitions, etc. I just tried it now against my own SharePoint instance and the WSDL returned from http:// mysite.com/ ...snip... /pierre/_vti_bin/UserGroup.asmx?wsdl is pretty much the same size as the one from http://msdn.microsoft.com/en-us/library/dd965659%28v=office.12%29.aspx and a quick check to make sure complex types are in both places confirm that.
To answer your second question: I think you should NOT create your Web Service stubs and skeletons based on the WSDL in the documentation. Instead use the WSDL returned from your site. If you're not getting all the complex types in the WSDL returned from SharePoint, you should fix that issue first.
First thing I would try: download SOAPui (free) and simply plugin the URL that ends with ?wsdl and create sample requests. Maybe you'll run into access issues (UAG or other) but at least you'll know that the WSDL is well formed. If SOAPui can generate the client code based on the WSDL, you can too (using wsdl2java or the wsdl2dotnet equivalent; I can't remember the name of the .net version).
And yes, it's dangerous to copy the WSDL from the docs but I'd be more worried about some things being abbreviated or documentation going stale, etc.
As for the contract changing, I'm using the UserGroup.asmx?wsdl endpoint since 2009 and it still works on newer versions of SharePoint (even after the upgrade to SP2010). And I'm using java as the client code. Microsoft really nailed the Web Services in SharePoint, it was surprisingly easy to integrate our java stack and make calls to/from the SharePoint web services. And it was also very inter-operable with the other tools we use to test Web Services like SOAPui, etc.
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
OK, this is impossible, but I will try to explain the situation here.
Let's say we have cases, that we need a fast setup of a web server in order to have a simple soap web service running (querying a db and so on).
In VS though, upon debugging a web project, it creates a quick ASP.NET development server without relying on the actuall IIS that might be installed on the PC.
Is there any project that does something like that?
This would be ideal for small projects, where a simple executable would get a server ready to go and would allow web services to be executed right away.
I have looked at some stuff over the net like http://msdn.microsoft.com/en-us/magazine/cc163879.aspx and http://mtaulty.com/CommunityServer/blogs/mike_taultys_blog/archive/2004/05/24/4479.aspx but they seem to be quite outdated and i am not sure how well they work (havent tested them thoroughly)
EDIT: I have build an application like the one you suggest. However, how can i implement HTTP GET/POST requests to the service using this method? I tried using WebGet after my operationcontract but it didnt work. For example, my service is at http://localhost:8080/Service and i would like to use it such as http://localhost:8080/Service/getMethod?x=2.
I believe that the development server used by Visual Studio is based off of the Cassini code base (of which there is a fork here). I also found this article on hosting the asp.net runtime. It was also created a while back (2004), but has been updated since (2008). I think a lot of the core concepts are probably still the same.
Another approach would be a roll-your-own web server using the HttpListener class. This could take some work if you want to use it for hosting asmx type services, but if you were doing RESTful services, it isn't too bad of an option (this is actually how RavenDB works if you are not hosting it under IIS).
A WCF service can be hosted in almost any kind of application, including a Windows Service or a console application. There is no need for a web server at all.
Alright,
i've done it so im posting it here to help anyone who has issues with similar problems.
Create your WCF Service file as usual and then by using ServiceHost (or WebServiceHost) you can easily create a WCF service.
In order to use GET http requests to make it simple to communicate with mobile devices (such as iphone) you can use WebGet above your service methods and make sure you manually add a service endpoint using WebHttpBinding for WebServiceHost or WebHttpBinding with an WebHttpBehavior for ServiceHost.
Then you can call your service methods such as http://localhost:port/webhttpendpointaddress/mymethod?x=2.
I am currently working on a SharePoint project that needs to use the Lists SharePoint web service (Lists.asmx). Therefore, we need to add a service reference to it in Visual Studio. However, we all develop and test on different virtual machines (with different VM names, URLs, etc.). The QA, Test and Production environments all have different names and URLs as well.
Adding a service reference adds a bunch of references to the URL that was specified when the reference was created (in the app.config. .wsdl, .disco, etc.). This is obviously a problem for us as code that works on one machine won't work anywhere else (which breaks the build and continuous integration) We also have to delete and add the service reference every time we work with code that was checked-in by someone else.
This must be a fairly common problem for people developing Web services so I wondered if there was a way around it. I know you can't really create a "dynamic" web reference, but perhaps the impacts of the URL change could be minimized somehow?
Thanks!
By default, the web-service uses the location where it was initially created. The WebService proxy has a URL property which can be set.
This example shows setting it dynamically: http://www.codeproject.com/KB/XML/wsdldynamicurl.aspx
EDIT:
You're also not limited to using the Add Web Reference feature in Visual Studio. You can use the wsdl.exe tool that ships with the .NET Framework SDK to generate the code file.