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.
Related
I'm importing and consuming a SOAP service in my C# web application through Visual Studio. The error I'm getting is "[class name] Member names cannot be the same as their enclosing type". Here's the catch: this is happening in the code auto-generated by VS using the WSDL. I've read similar issues and I know it's a matter of just changing the class names to eliminate the conflict. In this case, it's a WSDL. So before I go rewriting several hundreds of lines of code, will the service still work if I rename the conflicting classes?
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.
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
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!
Using Visual Studio 2005 and C# .NET I was attempting to call methods from the SkillSoft API through their web service and have been running into issues when creating the instance. I started by adding the web service reference to the project (Add Web Reference) and that works fine. Where I get tripped up is in the main .cs where I wish to call the methods I create an instance with the line of code:
SkillSoftWebService.OlsaService service = new SkillSoftWebService.OlsaService();
When I build and run this I get a CS0029 error: InvalidOperationException and it mentioned implicitly converting the queryInclude type to the queryExclude type. I know this question is specific to only those using Skillsoft but I was wondering if anyone had found a work around to this?
Thank you!
As I stated in my last comment, it was actually an issue with the Web Service provided methods so I was able to work around this generic exception by just removing the offending method (since I didn't need it).