Development Methodology

WCF metadata error: cannot import wsdl:binding

Kent Brown — Fri, 15 Feb 2008 12:18:26 GMT

Grrr... Just wasted lots of time on a stupid mistake due to misleading error message. I hate it when that happens.

I usually do self-hosting for my WCF services, but on a project I am working on we wanted to host in IIS. I was focused on the security aspects - trying to get Integrated Windows security on a web site, using impersonation to call the service under the client's credentials, protecting the service with Integrated Windows Authentication and turning off anonymous access in IIS.

I was trying different bindings and settings in IIS and at some point I could no longer get client proxy generation to work on my service through svcutil or by making a service reference. When running svcutil I kept getting the following error:

svcutil.exe http://localhost/BowneService/PricingS
ervice.svc
Microsoft (R) Service Model Metadata Tool
[Microsoft (R) Windows (R) Communication Foundation, Version 3.0.4506.30]
Copyright (c) Microsoft Corporation. All rights reserved.

Attempting to download metadata from 'http://localhost/BowneService/PricingServi
ce.svc' using WS-Metadata Exchange or DISCO.
Error: Cannot import wsdl:portType
Detail: An exception was thrown while running a WSDL import extension: System.Se
rviceModel.Description.DataContractSerializerMessageContractImporter
Error: Schema with target namespace 'http://tempuri.org/' could not be found.
XPath to Error Source: //wsdl:definitions[@targetNamespace='http://tempuri.org/'
]/wsdl:portType[@name='IPricing']

Error: Cannot import wsdl:binding
Detail: There was an error importing a wsdl:portType that the wsdl:binding is de
pendent on.
XPath to wsdl:portType: //wsdl:definitions[@targetNamespace='http://tempuri.org/
']/wsdl:portType[@name='IPricing']
XPath to Error Source: //wsdl:definitions[@targetNamespace='http://tempuri.org/'
]/wsdl:binding[@name='PricingwsHttpEndpoint']

Error: Cannot import wsdl:port
Detail: There was an error importing a wsdl:binding that the wsdl:port is depend
ent on.
XPath to wsdl:binding: //wsdl:definitions[@targetNamespace='http://tempuri.org/'
]/wsdl:binding[@name='PricingwsHttpEndpoint']
XPath to Error Source: //wsdl:definitions[@targetNamespace='http://tempuri.org/'
]/wsdl:service[@name='Pricing']/wsdl:port[@name='PricingwsHttpEndpoint']

Generating files...
Warning: No code was generated.
If you were trying to generate a client, this could be because the metadata docu
ments did not contain any valid contracts or services
or because all contracts/services were discovered to exist in /reference assembl
ies. Verify that you passed all the metadata documents to the tool.

Warning: If you would like to generate data contracts from schemas make sure to
use the /dataContractOnly option.

It turns out, somewhere in the process of trying to get things to work, I changed the account the AppPool was running under from "Network Service" to a service account I'd created. That service account didn't have write permissions to the C:\Windows\Temp directory, so it couldn't do the code generation necessary to generate the datacontract schemas. Here is the blog entry I found that clued me in:

http://blogs.infosupport.com/raimondb/archive/2008/02/14/Unable-to-generate-a-WCF-proxy-using-svcutil-but-retreiving-the-wsdl-works_3F00_.aspx

I am mostly posting so others find it quicker in the search engine.

The other lesson is the classic TDD mantra: make changes one at a time and test between every step. You might go a little slower, but you move along much more predictably because when something breaks, you know what it was.

Is Remoting Dead?

Kent Brown — Tue, 23 May 2006 00:05:00 GMT

There have been a lot of threads lately on various discussion lists and blogs, such as this one, grappling with the future of Remoting with WCF coming down the pike.

To explain my position, I first have to tell you my rule of software projects - “Every project sucks, except the one you are about to start.” We usually start projects with enthusiasm, eager to learn new technologies, convinced that this time we'll get the methodology and project management right and and the project will be written up as a case study and many awards and bonuses will be handed out. Somewhere after a few weeks or months the honeymoon phase ends and we get bogged down in the reality that software development is real hard work and not always fun. But that next gig always shines brightly on the horizon.

When it comes to distributed computing technologies, the rule is “Every distributed computing technology sucks, except the one Microsoft is shipping next year.” COM/DCOM was the greatest thing known to man. That is until its replacement, .NET Remoting, was in the works. Since .NET Remoting was going to solve all our problems it was then OK to admit the warts on the old platform.

Now, just a few years later, we are being told that Remoting sucks and WCF will solve all the problems. Only a dufus would deploy something on .NET Remoting.

Well, I am usually an early adopter and I generally agree that progress is being made with each wave, so I'll be eating and breathing WCF when it releases and singing its praises too. But we just have to remember that in designing something as complex as a platform for distributed computing, lots of compromises have to be made. Depending on the system you are building, and to an extent on your personal style and value judgments, there will be things about WCF that we will all hate in a few years and I dare say some of us will long for the days of .NET Remoting. And in some future stack that Microsoft releases, there will be a mix of features from all preceding platforms mixed in with a new paradigm and a new set of compromises. And then it will be OK to admit that WCF sucks too.

NYC Connected Systems User Group

Kent Brown — Thu, 05 Jan 2006 11:50:00 GMT

For a while now several us have thought “there oughta be an Enterprise Integration-oriented user group in the NY/NJ area“. Luckily we've bumped into one another and “I oughta” has turned into “we're gonna“. The “we“ includes myself (leader of the NJ DotNet Architecture and Development User Group) and Andrew Brust, Stephen Forte, and Bill Zack, the moderators of the NY DotNet Developers Group, so we're not just whistling Dixie.

We've got strong support from Microsoft here in NYNJ and in Redmond. This will mean a meeting space at the NYC Microsoft office, occasionally speakers from the product teams in Redmond, and hopefully lots of SWAG. We are modelling the group after the Northwest Connected Systems User Group, which was started a few months ago in Seattle.

The topics of discussion will include platform-agnostic topics such as architecture and design principles, patterns and best practices, etc. Along the lines of the Enterprise Integration Patterns book. The focus will be broad enough to include SOA, EAI, B2B, and BPM.

When we get down to code and tools the focus will be on the Microsoft platform covering BizTalk Server, Windows Workflow Foundation, Windows Communication Framework, WSE, Host Integration Server, Commerce Server, in about that order of emphasis, depending on the interest of the group membership of course.

We are pushing to hold the first meeting by the end of February. Drop me a line if you are interested in participating in the group.