|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
KB815131 "BUG" never fixed - Web Services and Custom Objectshttp://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. eric.ols***@gmail.com wrote:
Show quote > Check out this knowledge base article: It was fixed, but not in a way most of us hoped it would be fixed> 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. 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. eric.ols***@gmail.com wrote:
Show quote > Well I appreciate the article, but for me right now a simple find and It's a result of a big misconception of what webservices really are> 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. 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#) ------------------------------------------------------------------------  |
|||||||||||||||||||||||
Other interesting topics