Windows Communication Foundation

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 BizTalk Dead?

Kent Brown — Tue, 06 Nov 2007 20:20:36 GMT

Ok, so I have a theme going and thought I might as well run with it. I promise this is the last "Is x Dead?" post.

Of course BizTalk isn't dead. But it is going to change in the next couple of years. What I am talking about here is "Oslo", the recently announced, next-generation distributed computing vision from Microsoft.

Oslo takes SOA to the Internet

I was out at the SOA conference last week where Microsoft first publicly shared the vision that they are code-naming Oslo. There is a great story here and I can tell you from meeting with people on the product team that this is real - there are large numbers of people in the Connected Systems division at Microsoft already working on various products to support this vision. However, it will take some time, roughly two years, before significant portions of this will be ready for release. In the meantime, it is important as always to understand where things are going in order to make good decisions with the technology available today. The following is my current impression of the vision, the components, and the impact of Oslo on BizTalk Server.

The Vision of Oslo
Oslo is first of all a vision about the future of distributed application development and hosting. If Windows DNA was about realizing the vision of distributed computing through Microsoft technology, and .NET Connected Systems was about extending this vision to the entire enterprise by embracing interoperability standards, Oslo is about extending the vision one more time out to the breadth of the internet.

This vision had been previously announced at the MIX conference and termed "Software + Services". Software + Services, or S+S, is a subtle but meaningful variation on the currently popular Service-Oriented Architecture (SOA) and Software as a Service (SaaS) themes. The best way to explain it is to compare and contrast it with the current buzzwords.

Whereas SOA is largely used to describe the architecture within the enterprise, S+S creates a world in which services inside and outside the enterprise are tied together seamlessly to build a new breed of applications - "Composite Applications". While the Enterprise Service Bus (ESB) is currently all the rage, Microsoft wants to take it up a step and build the Internet Service Bus (ISB).

And while SOA is primarily targeted toward Corporate IT as an enabler for controlling quality and consistency within an organization, S+S actually encourages and facilitates the building of "opportunistic application development" by power users. These users will be more tech-savvy than ever before (having grown up with video games and blogs and iPods) and will not want to wait on the Corporate IT group to create the applications they need to be more productive. Think of the wild and crazy days of the PC revolution. But the advantage is that it will be easier for Corporate IT to adopt these renegade applications and officially support them when they gain critical mass because they will be built in a service-oriented fashion.

Software as a Service (SaaS) is best exemplified by SalesForce.com, which is an immensely successful CRM system that is completely hosted externally and consumed by subscribing companies. However, SaaS so far has only been successful when an entire application is hosted externally. The vision of S+S is that services will be hosted externally and applications within the enterprise will be built consuming services from within and without the enterprise security boundaries. The crux of this an availability of services built on interoperable web service standards, tools for building composite applications, and a federated security model that allows enterprise applications to trust externally hosted services.

The Components of Oslo

1. Continued emphasis on and evolution of core Service-Oriented programming technologies (WCF, WF). This will become ".NET Framework 4.0".

2. A first class Repository for storing, discovering, and governing services.

3. Simplified developer experience for building distributed applications through better modeling tools. This will of course be realized in a new version of Visual Studio.

4. Federated security model (InfoCard).

5. Leveraging of Groove techniques for getting around firewall barriers to collaboration between services.

6. Evolution of BizTalk -

o Adapters migrating out from BizTalk-specific realm to general .NET availability. This has already begun through the WCF Adapter framework and the WCF Adapter Pack.

o Other BizTalk tools, such as the schema editor and mapper become more mainstream as part of the .NET Framework.

o Orchestration will be done using WF as the XLANG/S engine is deprecated (this has been public knowledge for over a year)

o A new in-memory pub/sub engine will make persistence/durability of messages optional, making BizTalk more suitable for low-latency applications.

o BizTalk as a server product may be primarily about the hosting model and look something like the old AppCenter.

7. Potential for Microsoft (and others) to host useful services "in the cloud" that will be subscribed to by enterprise clients to reuse in their composite applications. There is a CTP version of some utility services already hosted at http://biztalk.net/Default.aspx.

What it means for the future of BizTalk

Eventually BizTalk as we know it will be dead in the sense that it will be deprecated and replaced by a shiny new technology. But I see it just like the change from COM to .NET. COM as a technology was dead, while the core concepts of component-based programming and interoperability between components lived on bigger and better than ever in .NET. And in hindsight, COM was a quirky technology and most of us are glad to be freed from GUIDs and the registry and vTables, etc.

In the same way, I expect that the architectural principals that BizTalk made real (interoperability, pub/sub, legacy integration, web service orchestration, long running transactions, massive scalability, model-driven development, etc.) will live on, in fact be magnified, in Oslo. But some of the specific implementation details that we may have grown sentimentally attached to (the MessageBox, XLANG/S, etc), will go away. And while we'll moan and fret as this transition happens, we'll eventually embrace the new and be happy we did.

In fact, Oslo represents an expansion of the role BizTalk plays in the entire Microsoft platform. While today BizTalk development is a niche are that a relatively small number of developers have braved, in Oslo, the tools will become more mainstream.

In the meantime, while we wait for the next version of BizTalk and the other tools that will make up Oslo, we have to make decisions about the applications we need to build today. This will be the topic of many blogs and white papers to come (in fact I have a white paper in the works regarding choosing between BizTalk and WF). For now I will summarize my view like this:

Oslo confirms Microsoft's commitment to Service-Oriented Architecture and development. So keep moving in that direction. Embrace WCF. Use WF where appropriate. And use BizTalk where appropriate.
You have to build your applications today on the available technology. Oslo is really too far away to significantly impact your development plans today. If you need what BizTalk Server provides, you should use it. Maybe when a Beta 2 or RC version is out with firm RTM dates, then you might want to delay a project to use the new technology.
Microsoft cannot make promises about upgrade paths at this point in the product cycle, but I feel there is no way they will fail to provide a way to upgrade orchestrations built on BizTalk 2006 R2 to run in the next WF-based orchestration engine. First of all, WF's roots are in XLANG/S so it isn't that hard to translate most features/constructs. Secondly, BizTalk is just too important and has too many mission-critical enterprise applications running on it for Microsoft to leave it hanging.
Finally, although the current BizTalk engine will be deprecated, it will still be available and supported for a long time to come.

Is BizTalk Dead?

Kent Brown — Tue, 06 Nov 2007 20:12:56 GMT

Ok, so I have a theme going and thought I might as well run with it. I promise this is the last "Is x Dead?" post.

Oslo takes SOA to the Internet

The Components of Oslo

1. Continued emphasis on and evolution of core Service-Oriented programming technologies (WCF, WF). This will become ".NET Framework 4.0".

2. A first class Repository for storing, discovering, and governing services.

3. Simplified developer experience for building distributed applications through better modeling tools. This will of course be realized in a new version of Visual Studio.

4. Federated security model (InfoCard).

5. Leveraging of Groove techniques for getting around firewall barriers to collaboration between services.

6. Evolution of BizTalk -

o Adapters migrating out from BizTalk-specific realm to general .NET availability. This has already begun through the WCF Adapter framework and the WCF Adapter Pack.

o Other BizTalk tools, such as the schema editor and mapper become more mainstream as part of the .NET Framework.

o Orchestration will be done using WF as the XLANG/S engine is deprecated (this has been public knowledge for over a year)

o A new in-memory pub/sub engine will make persistence/durability of messages optional, making BizTalk more suitable for low-latency applications.

o BizTalk as a server product may be primarily about the hosting model and look something like the old AppCenter.

What it means for the future of BizTalk

Oslo confirms Microsoft's commitment to Service-Oriented Architecture and development. So keep moving in that direction. Embrace WCF. Use WF was appropriate. And use BizTalk where appropriate.
You have to build your applications today on the available technology. Oslo is really too far away to significantly impact your development plans today. If you need what BizTalk Server provides, you should use it. Maybe when a Beta 2 or RC version is out with firm RTM dates, then you might want to delay a project to use the new technology.
Microsoft cannot make promises about upgrade paths at this point in the product cycle, but I feel there is no way they will fail to provide a way to upgrade orchestrations built on BizTalk 2006 R2 to run in the next WF-based orchestration engine. First of all, WF's roots are in XLANG/S so it isn't that hard to translate most features/constructs. Secondly, BizTalk is just too important and has too many mission-critical enterprise applications running on it for Microsoft to leave it hanging.
Finally, although the current BizTalk engine will be deprecated, it will still be available and supported for a long time to come.

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.

Great introductory article on WCF

Kent Brown — Mon, 06 Feb 2006 13:25:00 GMT

I'm a little late to the WCF bandwagon. In a past job as instructor and architectural consultant, I used to be the Beta Hound, sniffing out the latest cool technology coming out of Microsoft, downloading it, “playing” with it, then writing or teaching about it. After a few years of that, especially with the release of .NET, I missed being in the trenches and felt the need to get back to writing some production code. So I got involved in designing and building into some large, multi-year .NET projects to dig out that true knowledge that only comes from using a technology on a large, complicated real-life application.

I find that when I am immersed in writing production code to meet deadlines, I slip out of Beta Hound mode into Old Dog mode (can't teach him new tricks). It's hard to focus on vaporware, no matter how cool and imminent it is, if it isn't going to help me deliver on time.

I am now back in a position that affords me a little more time for forward thinking and tinkering with new technology. With my main interests being distributed computing, integration, and interoperability, Indigo is the coolest thing to happen in a while and its one of the main technologies I am crunching to catch up on. Especially since it isn't far from release. Although a huge step forward, I am finding WCF fairly easy to learn as it builds on or has similarities with all my favorite technologies - .NET Remoting, MSMQ, BizTalk Server, ASP.NET web services, etc. In fact, the goal is to unify and simplify all these things into a unified whole, and so far I like what WCF does.

All that to say that the MSDN latest article by Aaron Skonnard is an excellent place to start learning WCF: http://msdn.microsoft.com/msdnmag/issues/06/02/WindowsCommunicationFoundation/default.aspx.