KB815131 "BUG" never fixed - Web Services and Custom Objects

  • Thread starter Thread starter eric.olstad
  • Start date Start date
E

eric.olstad

Check out this knowledge base article:
http://support.microsoft.com/?kbid=815131

Quote from the article:
"Microsoft has confirmed that this is a bug in the Microsoft products
that are listed at the beginning of this article."

I can confirm that this bug does indeed exist, and I can also confirm
that this bug was NOT fixed in Visual Studio 2005.

This is indeed an annoying bug because it changes any "fixed" code back
to the "bug" code when you do an "Update Web Reference." For those
with the same problems, usually you can do a replace all on
System.Data.DataSet with your custom IXmlSerializable object. Just
make sure a reference to that object is available in the current
project.

For Microsoft, for shame! You knew about the bug and you still didn't
fix it! My disgust toward microsoft is never ending.
 
Check out this knowledge base article:
http://support.microsoft.com/?kbid=815131

Quote from the article:
"Microsoft has confirmed that this is a bug in the Microsoft products
that are listed at the beginning of this article."

I can confirm that this bug does indeed exist, and I can also confirm
that this bug was NOT fixed in Visual Studio 2005.

This is indeed an annoying bug because it changes any "fixed" code
back to the "bug" code when you do an "Update Web Reference." For
those with the same problems, usually you can do a replace all on
System.Data.DataSet with your custom IXmlSerializable object. Just
make sure a reference to that object is available in the current
project.

For Microsoft, for shame! You knew about the bug and you still didn't
fix it! My disgust toward microsoft is never ending.
Click to expand...

It was fixed, but not in a way most of us hoped it would be fixed
The fix everyone would have liked: simply transparent proper
investigation of the types, wasn't possible due to backwards
compatibility. So they cooked up a horrible scheme with schema
inspectors and other crap, which requires GAC and machine.config access
to get it working.

For a good overview of how it works in .NET 2.0, please check:
http://www.microsoft.com/belux/nl/msdn/community/columns/jdruyts/wsproxy
..mspx

FB

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
 
Well I appreciate the article, but for me right now a simple find and
replace on the proxy file does the trick. I don't have to deal with
all the BS of creating a SchemaImporterExtension and modifying the
machine.config file.

You're absolutely right. This is a horrible method for "fixing" that
"bug." I don't see how they classify this one as a bug fix either.
It's more like a bug workaround, and a rather complicated one at that.
If it was a bug fix, vs2005 would create the schema importer extension
for you automatically and modify the machine.config behind the scenes.
Plus, it would be documented in MSDN.

I guess I shouldn't complain. This is a very helpful feature. I just
wish that visual studio 2005 handled it better than 2003.
 
Well I appreciate the article, but for me right now a simple find and
replace on the proxy file does the trick. I don't have to deal with
all the BS of creating a SchemaImporterExtension and modifying the
machine.config file.

You're absolutely right. This is a horrible method for "fixing" that
"bug." I don't see how they classify this one as a bug fix either.
It's more like a bug workaround, and a rather complicated one at that.
If it was a bug fix, vs2005 would create the schema importer extension
for you automatically and modify the machine.config behind the scenes.
Plus, it would be documented in MSDN.

I guess I shouldn't complain. This is a very helpful feature. I just
wish that visual studio 2005 handled it better than 2003.
Click to expand...

It's a result of a big misconception of what webservices really are
and what their place is in modern software development. In VS.NET, they
seem to be like a normal tier and very easy to add to your app, even at
a low level, but that bypasses the idea of thinking in messages instead
of low level RPC with loads of data.

In WCF, this will be corrected somewhat, where it's more about
messages, contracts and the like, and not about how it's done now.

FB

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
 
Back
Top