WSDL.EXE Problem in .NET 2.0

I wanted to play with the Amazon Alexa Web Search Platform (AWS) web service, so I fired up Visual Studio 2005 and created a new Windows Forms project. I then tried to add a web reference to the AWS url. The GUI interface to wsdl.exe threw up all over it, so I tried it manually after running the trusty sdkvars.bat to make sure my environment variables were set. Here's the result (not pretty):

c:\>wsdl /o:test.cs
Microsoft (R) Web Services Description Language Utility
[Microsoft (R) .NET Framework, Version 2.0.50727.42]
Copyright (C) Microsoft Corporation. All rights reserved.
Error: There was an error processing ''.
- The document at the url was not recognized as a known document type.

The error message from each known type may help you fix the problem:
- Report from 'DISCO Document' is 'Discovery document at the URL could not be found.'.
- The document format is not recognized.
- Report from 'WSDL Document' is 'There is an error in XML document (140, 3).'.
- The element was not expected in this context: ... Expected elements:,,,,,,,,,, Report from 'XML Schema' is 'The root element of a W3C XML Schema should be and its namespace should be ''.'.

If you would like more help, please type "wsdl /?".

So I wondered how VS .NET 2003 would do with Amazon's WSDL. Changed directories to make sure I was running 1.1 of wsdl.exe and ran the same command line. It ran flawlessly. Here's the output:

c:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\Bin>wsdl /o:test.cs
Microsoft (R) Web Services Description Language Utility
[Microsoft (R) .NET Framework, Version 1.1.4322.573]
Copyright (C) Microsoft Corporation 1998-2002. All rights reserved.

Writing file 'test.cs'.

Opened VS .NET 2003 and created a little test project and it created the proxy just fine. I noticed that the WSDL file it created in the project was slightly different from the one downloaded directly from the Amazon URL. Specifically, the nodes with no namespace designation such as <definitions> and <types> now had a namespace prefix <wsdl:definitions> and <wsdl:types> along with the namespace declaration in the <definitions> node changed from xmlns="" to xmlns:wsdl="".

I closed VS .NET 2003 and opened VS 2005. Now I used the "Add Web Reference" and referenced the local AlexaWebSearchPlatform.wsdl file that VS .NET 2003 had created. Now I have a proxy that at least compiles, but of course it does not reference the Amazon URL directly so update web reference will not work.

I'll start testing using the 2003 to 2005 proxy generated class and report back tomorrow on how well it worked. Meantime, if anyone can tell me how to get the wsdl.exe for .NET 2.0 to behave, I'd appreciate it.

DotNetNuke 4.0 Go To Definition

I spent a few hours this week exploring DNN 4.0 and the team's effort to transform the successful 3.x version into the ASP.NET 2.0 mold. I congratulate the team. They had a lot of work to do and I found the installation and setup easy and the module template is a joy.

Of course, I wish they had chosen C# but that's my own bias. The beauty is that you can add a C# module using the module template right into the DNN web application. Everything seems to work as advertised, EXCEPT...

Open the C# module code generated by the template and right-click on an class name that's part of the DNN source code and select the "Go to Definition" menu option. Hey, where did the code go. I get a C# [meta data] file just like I would with a BCL class rather than the object browser. EXCEPT there is really code available but it's VB.NET.

So I have my first complaint about VS 2005. I'm hoping a reader can help me find the solution. In a mixed language solution, why doesn't the real code open up? Is this a bug or am I missing some configuration thing? First person to help me find the solution get's a $20 Amazon gift certificate, unless I post the solution here first.

One way or the other, I like DNN 4.0 a lot. Sure there's more comprehensive portal and content management systems available, but definitely not for the price. I'm sure I'll run into more trouble as I roll down the .NET 2.0 road, but so far, it's been a lot of fun. Here's to more of it.