Altaf,
Thank you for your response. My runtime version is 1.1.4322.2032. I cannot
go back to 523 as you suggest because of some other wsdl.exe bugs - you may
have noticed the hotfixes I pointed out as having installed. Our wsdl
includes 2 schemas, schema 1 and schema 2, and schema1 and schema2 both
include schema3. The elementFormDefault setting I am referring to is set in
schema1 and schema2 which are imported by the wsdl. Going back to the
runtime you suggest (which I have experimented with) causes a problem because
of the bug 892202 with including external schemas.
Yes, manually changing the proxy class to Qualified instead of unqualified
does work around the problem, but our customer does not want to have to
manually change their proxies. We are generating schemas based on their
datatype, and generating a version of our wsdl which is specific to their
datatype on the fly. However, just a change from unqualified to Qualified
doesn't seem to arduous to me, we'll see if they agree.
Thank you for your response
--
Cindy
"Altaf Al-Amin Najwani" wrote:
[color=blue]
> Though this problem is not coming on my side but i tried to regenerate this
> case, the version i m using creates WSDL with the qualified value of
> elementformdefault, instead if i tried to remove defaultnamespace of my
> webservice, it compiled with this messege
>
> This web service is using
http://tempuri.org/ as its default namespace.
> Recommendation: Change the default namespace before the XML Web service is
> made public.
>
> So, I tempered the generated WSDL and changed value of elementformdefault
> from qualified to unqualified, and I came up with the same proxy code as u
> posted here. So it means that you need to change this value to Qualified and
> use some earlier version Or use autogenerated proxy using .net IDE.
>
> "Altaf Al-Amin Najwani" wrote:
>[color=green]
> > Hi
> > First of all i would like to know what RunTime Version are you using.
> > I am using version 1.1.4322.573 and its working perfectly fine. The schema
> > file is generated with elementformdefault="Qualified" value. Yes but you are
> > right. This is problem and this has been discussed many times on many groups.
> > I dont have KB number of this bug but what seems to me that this issue gets
> > resolved if you replace unqualified with qualified value. As solution i will
> > suggest that you use earlier version of WSDL to generate Stub. As I have seen
> > similar problem in VS 2005 too.
> >
> > "CindyRob" wrote:
> >[color=darkred]
> > > Using .NET framework 1.1 SP1, .NET framework SDK 1.1 SP1, Visual Studio .NET
> > > 2003, hotfixes 892202 and 823639.
> > >
> > > I create a proxy class using wsdl.exe, and in the serialized XML request, I
> > > see that any elements that are nested elements in the schema (not global
> > > elements) have their namespaces set to the null namespace. I can see that
> > > the proxy classes have serialization attributes specifying these nested
> > > elements as unqualified:
> > > /// <remarks/>
> > >
> > > [System.Xml.Serialization.XmlElementAttribute(Form= System.Xml.Schema.XmlSchemaForm.Unqualified)]
> > > public AuthenticationDataLoginData LoginData;
> > >
> > > and so in the XML, the namespace is set to null:
> > >
> > > <AuthenticationData>
> > > <LoginData xmlns="">
> > > etc...
> > >
> > > I expected that this was happening because in the schema file,
> > > elementFormDefault="unqualified". Therefore, I would expect that if I
> > > changed it to elementFormDefault="qualified", I would see the proxy class
> > > change and would get rid of the xmlns="" in the LoginData field. That didn't
> > > happen - the generated proxy is exactly the same. In other words, no matter
> > > what you set for elementFormDefault, wsdl.exe behaves as if the
> > > elementFormDefault is "unqualified", and the namespace is set to null.
> > > Is this a known bug in wsdl.exe - is there a fix available? I'd like to
> > > minimize the changes to the schema if I can, and I have an external
> > > requirement that no manual changes to the generated proxy class be needed.
> > >
> > > Thanks,
> > >
> > > --
> > > Cindy[/color][/color][/color]
