Why does this WSDL file generate an empty service proxy in VS2008?
If you look at the Reference.cs file generated, it's empty. Any ideas?
right click on service reference , cofigure , un-check “Reuse types in referenced assembles” and click OK. Try to Update Service Reference. This worked for me!
Have you read your error list? I got the following:
Custom tool warning: There was a validation error on a schema generated during export:
Source:
Line: 144 Column: 12
Validation Error: Wildcard '##any' allows element 'http://search.yahoo.com/mrss:text', and causes the content model to become ambiguous. A content model must be formed such that during validation of an element information item sequence, the particle contained directly, indirectly or implicitly therein with which to attempt to validate each item in the sequence in turn can be uniquely determined without examining the content or attributes of that item, and without any information about the items in the remainder of the sequence.
Custom tool warning: Cannot import wsdl:portType
Detail: An exception was thrown while running a WSDL import extension: System.ServiceModel.Description.XmlSerializerMessageContractImporter
Error: Cannot import invalid schemas. Compilation on the XmlSchemaSet failed.
XPath to Error Source: //wsdl:definitions[#targetNamespace='http://fliqz.com/services/search/20071001']/wsdl:portType[#name='IVideoSearchService']
Custom tool warning: Cannot import wsdl:binding
Detail: There was an error importing a wsdl:portType that the wsdl:binding is dependent on.
XPath to wsdl:portType: //wsdl:definitions[#targetNamespace='http://fliqz.com/services/search/20071001']/wsdl:portType[#name='IVideoSearchService']
XPath to Error Source: //wsdl:definitions[#targetNamespace='http://tempuri.org/']/wsdl:binding[#name='basicHttpBinding_IVideoSearchService_20071001']
Custom tool warning: Cannot import wsdl:port
Detail: There was an error importing a wsdl:binding that the wsdl:port is dependent on.
XPath to wsdl:binding: //wsdl:definitions[#targetNamespace='http://tempuri.org/']/wsdl:binding[#name='basicHttpBinding_IVideoSearchService_20071001']
XPath to Error Source: //wsdl:definitions[#targetNamespace='http://tempuri.org/']/wsdl:service[#name='VideoSearchService']/wsdl:port[#name='basicHttpBinding_IVideoSearchService_20071001']
Custom tool error: Failed to generate code for the service reference 'ServiceReference1'. Please check other error and warning messages for details.
Edit: I did some digging, and I came across the following links:
MSDN Question
Blog Entry
I tried following the instructions by ScottAnderson in the first link, but was unable to generate a client proxy with them. Perhaps you can have better luck.
It appears the reason this doesn't work is because Fliqz is using XmlSerializer rather than DataContract/MessageContract for its contract definitions, and WCF doesn't want to play nicely with them and generates inappropriate WSDL. If you could control the original contract, you could probably fix the issue and be on your way; unfortunately, you may be entirely out of luck.
If you can get the ServiceContract interface and the types it exposes, you might be able to generate your own client by hand. Judging by some of the class names I see in there, it appears that Fliqz is exposing internal objects in their contract, so I doubt you could, you know, call them up and ask them for a .dll you can reference.
You could try to write out the interface and data / message contract types yourself by analyzing the WSDL and XSDs. Looks like it'd be a lot of work, though.
Sorry I can't help more. This seems to be a combination of poor WCF legacy support and poor architecture/design on the part of Fliqz.
Try adding it as .NET 2.0 Web Reference.
Go to Add Service Reference, then click the "Advanced" button. Then you're given to option to add it as a .NET 2.0 Web Reference. I did this, and got it to work. I couldn't via the standard "Add Service Reference"
I don't see any <wsdl:portType> elements in your WSDL - that might be the problem.
Also, are you creating your service from a live URL, or some files on disk? If you're using "on disk" files: did you also get the "wsdl0" file as referenced in this line here:
<wsdl:import namespace="http://fliqz.com/services/search/20071001" location="http://services.fliqz.com/LegacyServices/Services/search/R20071001/service.svc?wsdl=wsdl0"/>
Marc
Related
This is my first try trying to use WCF, so I'm guessing I'm doing something incorrect.
I'm trying to access a soap service defined by the WSDL at http://confluence.atlassian.com/rpc/soap-axis/confluenceservice-v1?wsdl I'm using VS2010, and I add a Service Reference to my project and point it to the URL there (or rather, our intranet install of it), but when I use the Object Browser to view the service, the operations on the interface are ALL void methods with no parameters. It seems that WCF is not reading the type information correctly. It doesn't give errors, but it's giving tons of warnings like the following:
Warning 1 Custom tool warning: Fault
named InvalidSessionException in
operation getPermissions cannot be
imported. Unsupported WSDL, the fault
message part must reference an
element. This fault message does not
reference an element. If you have edit
access to the WSDL document, you can
fix the problem by referencing a
schema element using the 'element'
attribute. Z:\TestLibrary\Service
References\Confluence\Reference.svcmap 1 1 TestLibrary
Warning 2 Custom tool warning: The
optional WSDL extension element 'body'
from namespace
'http://schemas.xmlsoap.org/wsdl/soap/'
was not handled. XPath:
//wsdl:definitions[#targetNamespace='http://confluence.atlassian.com/rpc/soap-axis/confluenceservice-v1']/wsdl:binding[#name='confluenceservice-v1SoapBinding']/wsdl:operation[#name='getPermissions']/wsdl:input[#name='getPermissionsRequest'] Z:\TestLibrary\Service
References\Confluence\Reference.svcmap 1 1 TestLibrary
What am I doing wrong? I tried changing the config of the service with a combinations of options, but I could never pull in the types from the WSDL correctly. I've been assuming that WCF will auto-generate the type classes along with the service interface. Am I supposed to figure out what types are in use in the WSDL and create the classes and data contracts myself, or is it something else?
Hhmm... interesting - I ran svcutil.exe from the command line against that URL you provided, and while I get a ton of warnings about WSDL issues, I do also get some code - something like:
//------------------------------------------------------------------------------
// <auto-generated>
// This code was generated by a tool.
// Runtime Version:2.0.50727.4952
//
// Changes to this file may cause incorrect behavior and will be lost if
// the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------
[System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "3.0.0.0")]
[System.ServiceModel.ServiceContractAttribute(Namespace="http://confluence.atlassian.com/rpc/soap-axis/confluenceservice-v1", ConfigurationName="ConfluenceSoapService")]
public interface ConfluenceSoapService
{
// CODEGEN: Generating message contract since the wrapper namespace (http://soap.rpc.confluence.atlassian.com) of message getPermissionsRequest does not match the default value (http://confluence.atlassian.com/rpc/soap-axis/confluenceservice-v1)
[System.ServiceModel.OperationContractAttribute(Action="", ReplyAction="*")]
[System.ServiceModel.XmlSerializerFormatAttribute(Style=System.ServiceModel.OperationFormatStyle.Rpc, Use=System.ServiceModel.OperationFormatUse.Encoded)]
getPermissionsResponse getPermissions(getPermissionsRequest request);
// CODEGEN: Generating message contract since the wrapper namespace (http://soap.rpc.confluence.atlassian.com) of message searchRequest does not match the default value (http://confluence.atlassian.com/rpc/soap-axis/confluenceservice-v1)
[System.ServiceModel.OperationContractAttribute(Action="", ReplyAction="*")]
[System.ServiceModel.XmlSerializerFormatAttribute(Style=System.ServiceModel.OperationFormatStyle.Rpc, Use=System.ServiceModel.OperationFormatUse.Encoded)]
[System.ServiceModel.ServiceKnownTypeAttribute(typeof(RemoteException))]
[System.ServiceModel.ServiceKnownTypeAttribute(typeof(Vector))]
[System.ServiceModel.ServiceKnownTypeAttribute(typeof(RemotePermission))]
[System.ServiceModel.ServiceKnownTypeAttribute(typeof(RemoteNodeStatus))]
[System.ServiceModel.ServiceKnownTypeAttribute(typeof(RemotePageHistory))]
[System.ServiceModel.ServiceKnownTypeAttribute(typeof(RemoteContentPermission))]
[System.ServiceModel.ServiceKnownTypeAttribute(typeof(AbstractRemotePageSummary))]
[System.ServiceModel.ServiceKnownTypeAttribute(typeof(RemoteSpaceSummary))]
[System.ServiceModel.ServiceKnownTypeAttribute(typeof(RemoteSearchResult))]
searchResponse search(searchRequest request);
So I would try to use svcutil.exe from the command line to generate your ConfluenceSoapService.cs file and then use that to talk to your Confluence service.
Just encountered this problem on JIRA 4.4, and it DOES work if you use the older Web Reference instead of a Service Reference.
For instructions on doing this, see: Web Reference vs. Service Reference
This was the simplest solution for me, since I know JIRA is moving toward REST (away from SOAP) and I am just trying to quickly get up and running.
After much research it appears to create and use our own security manager in the web browser control in IE we need to override the GetSecurityId method for both IInternetHostSecurityManager and IInternetSecurityManager as at some point they are compared and if found to return a different result they throw a UnauthorizedAccess exception. Has anyone had success with overriding IInternetHostSecurityManager. MSDN suggests accessing it through SID_SInternetSecurityManager , but I have not found any other references to SID_SInternetSecurityManager. Also I have not found a guid for IInternetHostSecurityManager so I can not access it through IServiceProvider.QueryService. Any one successfully get around this or find a different method of access cross domain iframes in the webbrowser control?
IID_IInternetHostSecurityManager, SID_SInternetSecurityManager and SID_SInternetHostSecurityManager are defined in urlmon.h and urlmon.idl. If you have link errors in C++, check How to avoid error "LNK2001 unresolved external" by using DEFINE_GUID.
If you are using a script language you can use midl /tlb to generate a type library from urlmon.idl and import the type library instead. You can also declare the guids and interfaces based on the definition in urlmon.idl.
Building an app that is relying on a 3rd party provider who has a very verbose set of SOAP services (we're talking 50+ WSDL files). Each individual WSDL however has numerous shared type declarations. When generating client code with wsdl.exe, there used to be a /sharedtypes flag that would merge duplicate entries if a type was found several times.
When I attempt to generate my client code, I bomb on these overlapping types that the 3rd party includes in all their WSDL files.
svcutil /t:code /importxmltypes [mypath]/*.wsdl
Results in error messages alluding to the type collisions. For example, a couple samples of the error messages below:
Error: There was an error verifying some XML Schemas generated during export:
The simpleType 'http://common.soap.3rdparty.com:CurrencyNotation' has already been
declared.
Error: There was an error verifying some XML Schemas generated during export:
The complexType 'http://common.soap.3rdparty.com:NumberFormat' has already been
declared.
I do not have control over the output of the WSDLs. I do not want to have to edit the WSDLs by hand for fear of an error that breaks in a fashion at runtime that would be highly difficult to track back to our editing of the WSDL files. Not to mention that there are 50 some WSDL files that range from 200-1200 lines of XML. (Remind me again why we thought SOAP was the great salvation to us all back in the late 90s?)
Try specifying all the WSDLs in one command:
svcutil http://example.com/service1?wsdl http://example.com/service2?wsdl ...
This should automatically take care of duplicate types. Another option is to take a look at the /reference command switch:
/reference:<file path> - Add the specified assembly to the set of
assemblies used for resolving type
references. If you are exporting or
validating a service that uses 3rd-party
extensions (Behaviors, Bindings and
BindingElements) registered in config use
this option to locate extension assemblies
that are not in the GAC. (Short Form: /r)
This means that if you already have some types defined in some assembly you may include this assembly and svcutil will exclude types from it to avoid duplicates:
svcutil /reference:someassembly.dll http://example.com/service?wsdl
I was having similar problems. By defining different CLR namespaces for the different xml namespaces (using the /namespace argument of svcutil) i was able to get it working.
/namespace:http://www.opengis.net/gml,OpenGIS.GML
I have been using wsdl.exe to get round this because I work with some SOAP webservices which define the same data transfer objects at different endpoints. So I use wsdl.exe because it has the sharetypes switch. I'm not a WPF developer so I don't really care that the output does not implement IWhatever for WPF, but the classes generated are all partial so you can do some work to implement interfaces you care about in a separate file.
I recently added some namespaces to my web.config file so that all of my aspx pages can reference various constants and enums without the need to add an import statement on each aspx page. Since adding this, we are now getting an error when trying to test an asmx web service. It appears that during the wsdl generation we get the following error:
CS0104: 'Message' is an ambiguous
reference between
'System.Web.Services.Description.Message'
and 'InsTech.ForeSight.Message'
While researching this, I found out that DefaultWsdlHelpGenerator.asmx is called during the runtime compilation and there is a method in there that has the following signature:
void WriteSoapMessage(MessageBinding messageBinding, Message message, bool soap12) {
We have an object defined in our namespace called Message which is causing the ambiguous reference since this web service file is not fully qualifying their message.
How can I go about resolving this without removing the namespaces from the web.config? We have our web services in another folder in our virtual directory so I tried adding a web.config that did a clear on the namespaces but that did not appear to work.
Any help would be appreciated.
Thanks
Kevin
You can use namespace aliases in your code and use that to differ between them:
using ourOwn=our.own.namespace;
And refer to your Message class as ourOwn.Message. That will avoid the collision.
I am currently developing a webapp based on c# that calls some webservices. I have imported three different WSDLs from the provider into my WebApplication3 project (references -> add web reference). In the class viewer they appear as:
WebApplication3.com.provider.webservices1
WebApplication3.com.provider.webservices2
WebApplication3.Properties
Apparently the first and second WSDL have repeated functions (is that the correct name?)
If I add to my Default.aspx.cs the following using:
using WebApplication3.com.sabre.webservices1;
using WebApplication3.com.sabre.webservices2;
using WebApplication3.Properties;
and then try using:
MessageHeader msgHeader = new MessageHeader();
in my WebApplication3 namespace, I get the error
"Ambiguous reference between WebApplication3.com.provider.webservices1 and
WebApplication3.com.provider.webservices2"
I guess this is because it is declared in both WSDL? How can I fix this so I can use it?
Thanks, and sorry if the question is stupid!
try referencing MessageHeader by using its full namespace.
eg.
WebApplication3.com.provider.webservices1.MessageHeader msgHeader = new
WebApplication3.com.provider.webservices1.MessageHeader()
for brevity you can try
using MessageHeader = WebApplication3.com.provider.webservices1.MessageHeader
which would let you use
MessageHeader msgHeader = new MessageHeader()
where MessageHeader is from the webservices1 namespace
Fully qualify the class name with the namespace.
WebApplication3.com.sabre.webservices1.MessageHeader msgHeader = new WebApplication3.com.sabre.webservices1.MessageHeader();
It would seem as though you have imported the same WSDL twice -- or at least some of the types used by both are the same. You may be able to disambiguate between the two same-named types not importing both web reference namespaces or by using a namespace alias.
Could you post the actual code snippet and also indicate the URLs that you imported using "Add Web Reference"? Also, what version of Visual Studio are you using and what version of the .Net Framework are you targeting?
EDIT -- Follow-up based on the information Peter provided in the comment
I Examined both the URLs you posted, and just wanted to provide a little background. In deed the reason you first saw the error is that both WSDL imports specify the use of the same type, namely MessageHeader. Examining the top of each WSDL file:
http://webservices.sabre.com/wsdl/sabreXML1.0.00/usg/SessionCreateRQ.wsdl
<definitions targetNamespace="https://webservices.sabre.com/websvc">
<types>
<xsd:schema>
<xsd:import namespace="http://www.opentravel.org/OTA/2002/11" schemaLocation="SessionCreateRQRS.xsd"/>
<xsd:import namespace="http://www.ebxml.org/namespaces/messageHeader" schemaLocation="msg-header-2_0.xsd"/>
...
http://webservices.sabre.com/wsdl/sabreXML1.0.00/tpf/OTA_AirAvailLLS1.1.1RQ.wsdl
<definitions targetNamespace="https://webservices.sabre.com/websvc">
<types>
<xsd:schema>
<xsd:import namespace="http://webservices.sabre.com/sabreXML/2003/07" schemaLocation="OTA_AirAvailLLS1.1.1RQRS.xsd"/>
<xsd:import namespace="http://www.ebxml.org/namespaces/messageHeader" schemaLocation="msg-header-2_0.xsd"/>
...
The last line in each WSDL file shows the reason for your type name collision -- the same XSD file is imported by each WSDL file, obviously because both use the same type. When you create a web reference to each WSDL file, Visual Studio examines the WSDL and generates a class that matches the imported msg-header-2_0.xsd schema.
Unfortunately, Visual Studio can't tell that the schema in each separate WSDSL reference is really the same type, and so it dutifully imports each and generates a separate class for each. Although each of the classes generated share the same name, each is defined within it's own unique namespace that correlates to each of the WSDL files.
So, this is why the solution you accepted for your question works -- either specifying the full name of one the types works or using an alias to one of the types within one of the specific namespace.
Another solution would be to fix the two web references to share a single MessageHeader type. This could be done manually, however, you'd have to redo the manual edit each time you refreshed the web service reference, so I wouldn't recommend it. Also, it's probably a better idea to use the proper MessageHeader type defined for with each service, despite the fact that they're the same. So, I would create two using aliases if you assuming you were going to call both services from the same source file:
using MessageHeader1 = WebApplication3.com.sabre.webservices1.MessageHeader;
using MessageHeader2 = WebApplication3.com.sabre.webservices2.MessageHeader;
I would use MessageHeader1 with whatever service you referenced under the namespace WebApplication3.com.sabre.webservices1 and likewise, MessageHeader2 with the other.
Good luck!