No option to import from WSDL in designer

Topics: Service Factory Modeling Edition Forum
Dec 20, 2007 at 8:22 PM
I'm trying to use the import from WSDL feature of Service Factory Modeling Edition, but I don't have the option to Import from WSDL in the options menu when I right click on my service contract designer. The only option I have is Validate & Validate All. I've defined a service contract & data contract with the implementation technology as WCF. I've added DataContract, ServiceContract, & ServiceImplementation projects & defined their project mapping roles in the projectmapping.xml file. I've defined the project mapping table in both the service contract & data contract designers. I'm using Visual Studio 2005, however, I do have Visual Studio 2008 installed on the same machine. Is there any step I've left out or reason why this option wouldn't be visible in the designer?
Dec 20, 2007 at 11:28 PM
Well, I can say that the most likely reason is becasue that feature was "removed" from the final version (it was present in earlier pre release versions).
Now the option you have now is to use the XsdMessage element from the Service Contract model and point each message to the schema where you have defined your data contracts and related stuff.
Dec 21, 2007 at 5:44 PM

charlyfriend wrote:
Well, I can say that the most likely reason is becasue that feature was "removed" from the final version (it was present in earlier pre release versions).
Now the option you have now is to use the XsdMessage element from the Service Contract model and point each message to the schema where you have defined your data contracts and related stuff.

Thanks for the info! Just to clarify, if I have a WSDL from an existing service that I want to model, automatically importing the messages & data types into the designer is no longer a workflow that is covered by the latest release. I would have to manually create the operations & connect them to an XSD Message object. Will this feature ever be "re-added" into a later version? Maybe someone should update the title on the "import from WSDL video" to say that the feature is no longer available.

Dec 24, 2007 at 1:47 PM
As far as I know this feature won't be included unless someone in the community may want to share a feature like this so we can post it in this site.
Thanks for your feedback and suggestion about the link update.
Jan 24, 2008 at 1:46 PM
Please understand that Contract-First approach is very very important for the developers. I don't understand why such a good feature (which unreasonably lacks from SvcUtil.exe...) as "Import WSDL" has been removed.
Microsoft has made such huge efforts to guarantee interoperability, but then it falls way back compared to other vendors. BizTalk is the same: where is the tool that exctracts a Service implementation from a "platform-agnostic" WSDL ??? Bad... really bad.
Jan 24, 2008 at 3:43 PM
As far as I know, "Import WSDL" feature was removed for timing constraints in the projects but you still can do contract first using the XsdMessage element in SC model. You can still add a WSDL file to your solution (i.e to your Schemas folder) and reference the types from the XsdMessage element. I know it's not the same as the former import feature but it still let you model from an already created schema (included in your WSDL file) and generate code from types defined there..
Jan 25, 2008 at 10:03 AM
Hi, I'm doing as suggested, have created my service, operation and message contracts (as xsd messages). I then point them at the WSDL I have imported into the 'Schema's' folder.

When I generate a client though, and try to invoke the service, I get a fault exception suggesting that the request message instance was null.

I think this may be because I have had to set the services serialiser type to 'XMLSerialiser' instead of DataContractSerialiser. This is because VS complains that my WSDL is not DataContractSerialiser compliant.

Any ideas?
Jan 25, 2008 at 3:36 PM
Regardless of the serializer type, you should set the request message with an instance of that type on the client side and get that instance on your service side (add a breakpoint in the operation that receives that request). The different serializers are handled by WCF and should be 'transparent' to you client usage.
Feb 14, 2008 at 6:05 PM

charlyfriend wrote:
As far as I know, "Import WSDL" feature was removed for timing constraints in the projects but you still can do contract first using the XsdMessage element in SC model. You can still add a WSDL file to your solution (i.e to your Schemas folder) and reference the types from the XsdMessage element. I know it's not the same as the former import feature but it still let you model from an already created schema (included in your WSDL file) and generate code from types defined there..

Charly, could you please direct me to a tutorial on what steps are involved in doing this? Keep up the great work!
Feb 14, 2008 at 6:28 PM
You will find a sample in the "15 Minutes" demo solution included in the WSSF download. On the other hand, if you want to add somthing like an "Import.. something" feature on your model, you have an example on Ex#10 of the Extensibility Hands-on Lab.
Mar 3, 2008 at 9:34 AM
I can't begin to tell you how disappointed I am that this feature is not included.

Perhaps I should step out on a limb here and suggest that it is Microsoft's policy to not provide tools to assist in "Contract First" development of web services and that is why the feature was not released?

By making tools available that allow import of schemas from "Platform agnostic" (thanks tpernice) wsdl's, would put the choice of the implementation in the hands of the implementer.

As this choice has been effectively removed, we are now in the position of either having to develop all services with Microsoft tools, or generate the code manually, or not support WCF at all. The last choice is becoming increasingly appealing to me.

As for Steve Balmers promise of interoperability (, how can that get any credibility.

If anyone else is aware of products, open source or commercial that can generate WCF Services from WSDL's, including support for:
* extensions on types.
* ws-* standards including ws-policy and ws-security.

...I would love to hear from you. I am aware of Thinktecture's WSCF (Web services contract first) freeware tool.
Mar 3, 2008 at 9:34 AM
Edited Mar 3, 2008 at 9:34 AM
Removed - Duplicate post.
Mar 4, 2008 at 9:21 PM
I'll like to support gavinb statements, this is a setback for Enterprise projects here in Denmark, where lots of Government services is being developed and is going to be consumed in the private sector (finance an banking). The the financing agency I work for develops on a .Net platform and the Government controls the service contracts (WSDL).
It is annoying that competing agencies can move faster because they are running on a BEA platform.

/Jakob Røjel
Mar 11, 2008 at 4:34 AM
Sorry for ringing in so late on this topic, but hopefully I can add some clarity around this issue. First and foremost, the decision to remove the import WSDL feature had absolutely NOTHING to do with Microsoft's reluctance to provide help for contract-first scenarios. So gavinb, please climb down from that limb ... you're scaring me :) I'm a huge proponent of contract-first development - heck, Christain and I are practically brothers :) Sorry, it's late and I'm still in the office so you'll have to put up with me a little.

Ok, here's the deal. When we first introduced this feature in the Service Factory, we didn't have models. We generated code straight-away ... from WSDL to code ... just like svcutil. When it was time to implement it along with the models in this latest version, we ran into a roadblock ... and that roadblock is actually one of the FEATURES of the models. The feature I speak of is the level of abstraction the models provide over the code (and WSDL). The scenario we were trying to support is this:

  1. User generates a Service Contract Model and a Data Contract Model by importing an existing WSDL document
  2. User generates the service code from the models and hosts the generated services (IIS or Casini)
  3. The WSDL document exposed from the MEX endpoint of the service matches the initial WSDL document that was imported

There was just no way to implement this because the WSDLs actually contain more detailed metadata than the models are capable of holding. Given this, we could have made one of two decisions: add all of the necessary detail to the model and give up on providing an abstraction layer, or change the scenario/capability of the WSDL import feature.

Keep in mind, during all this, the team was still busy building factory infrastructure (project mapping, code generation strategies, extension properties, cross-model validation, etc). Also, we knew we were going to spend a lot of time helping users understand how they can modify the factory to meet their needs using a hands-on lab. In other words, we knew there would be import and export exercises in the extensibility hands-on lab. I'm actually quite surprised no one has built and shared this capability yet.

So, we can include this functionality in a future version (if no one has done it yet). But first, a question to you ... would you still want a WSDL import feature if it meant that the service generated from the model didn't emit the same WSDL you imported? Is a "starting point" good enough? Help me understand the scenario. Thanks a ton for the feedback guys! This is a great discussion, and very valuable for the team. Thanks.

Mar 11, 2008 at 3:30 PM
That a completely justified decision for removing this feature. I believe a "starting point" is definitely good enough. It would at least get you feedback about what others don't like about the implementation. It doesn't have to be perfect the first go around.
Mar 11, 2008 at 6:21 PM
A starting point would be great for me, as well. I would like it to work even for a complex set of WSDL and schemas. If necessary, it should translate an attribute-style schema into a data contract (and warn that it's doing so). It should also warn about anything else specified in the WSDL that it is unable to translate into the models.
Apr 17, 2008 at 10:36 AM
One step forward... and two steps back. Sorry to say I completely do not agree with any of the explanation that should justify the reason why automated WSDL Proxy-generation tools have disappeared. We had this functionalities back to old asmx and even WSE (WSDL.exe) but MS decided to remove that feature. Why? My guess is that MS does not like WSDLs to be generated in a software-agnostic environment.
The Web Service Factory introduced this feature that was very useful, but now decided to removed it because "the WSDLs actually contain more detailed metadata than the models are capable of holding". Well... than there's something truly wrong about those models.
Be aware that outside of MS there's a whole pletora of Vendors that support easily this features in many different ways, including open-source products...
Jun 15, 2008 at 11:03 PM
Thanks for the explanation. It makes sense..You asked if we would want a system where the emitted WSDL didnt match the imported WSDL. That could work in scenarios where we first agree the contract between the two parties to enable each to start development but allow for some integration time to tie the new consumer to the final WSDL. It wont work when one party has finished a "production" ready consumer with the WSDL deeply embedded in the proxy and where even small changes to the WSDL will cause the transmission to fail or when using industry standard WSDLs and schemas. So, yes, it would be useful to have the feature when the former scenario is being played out. 

Im still in the ASMX world and havent moved to WCF yet. My question is, in ASMX you could always turn off the WSDL emit feature and set the location of the predefined WSDL. is that not possible in WCF? Could the models not have some attribute somewhere to set this. The recipes could always include this as an optional attribute and if available use it when generating code.

I have also read about the "Conform to WSDL" feature in Orcas Team Architect edition. I dont know if the VSTA now uses DSL tools or something else, but could SF borrow something from there? (or have i misunderstood the WSDL Conformance feature? :-).

- benjy
Jun 27, 2008 at 8:19 AM

I'm sorry to say that this is a major dissapointment. I've encountered many scenarios where it has been a firm requirement that we implement at specific service interface (defined in a WSDL description), and I see it as more and more important to be able to do so.

Let me explain two typical scenarios:

SOA/Enterprise integration. Typically you will be specifying the services in advance, because you are also planning the integration and business processes. A very convenient way of sharing the specification is in a WSDL file. It is standards based, easy to exchange between parties, and in many cases it is easy for the implementation partner to use the WSDL as a basis for the implementation. Except if I'm using the latest and greatest from Microsoft (WCF and software factories), because then I'm reduced to labour intensive and ineffective ways of working.

Asyncroneous application integration. To avoid tying up the IIS with longrunning web service calls we typically use an asyncroneous protocol - if you call me, I'll call you back once I have the result. Clean and efficient. Except we need to agree on the protocol and the interfaces. Oh wait - if we use WSDL then we are technology independent and it is easy to ensure that we implemt the specified interface. Back to the comments above.

So does this mean that the software factory is useless - no of cause not! It is pretty cool. But not having a WSDL import/export is a serious mistake, and if the argument is that this can't be done because there is a model, then the model is not sufficient.

Are there ways to fix this - yes (for instance make it possible (but not mandatory) to annotate/expand the model with the missing information, or accept that some minor information (like location) is not passed through). Could I fix this myself - probably given time and ressources, but I'm not a tool developer and I really think that this is the responsibility of my tool vendor (Microsoft) - especially since WSDL is *the* standard for defining web services.

So back to the 'would I still want this if the resulting WSDL was not identical to the imported WSDL?' question. Yes I would - but only if the changes were insignificant when calling the service. Things like Operation names, SOAP Encoding, SOAP Action, document style, parts definitions, message definition XSD and so on must be preserved. 

Hopefully this will happen - and sooner rather than later :-)


Jun 27, 2008 at 11:28 AM
We have the import feature ready to test it here. Notice that the idea is to place it in a WSSF Contribution site but if you want to give it a try, then go for it and tell us what you think. Notice that it have its limitations (bascially stated above) but hopefully it might be of help.
Jun 30, 2008 at 6:44 AM
Thanks charlyfriend - I'll check it out as soon as possible (but first I'll have to download the source code for WSSF). I'll get back with feedback once I do a few testruns.
Jul 2, 2008 at 7:19 AM

I’ve looked at the WSDL import option from charlyfriend and after an initial ’this looks *very* cool’ experience I’m afraid that the conclusion is that I can’t use this as is. I’ve encountered some problems along the way, but the biggest hurdles have been that there is just too much information that gets lost from the original specification, and I believe that the problem is not so much in the WSDL import, but more fundamental to WSSF.


If I generate a WSSF service from a WSDL the differences when comparing the original WSDL with the service generated by WSSF includes different tag names for the request part (apparently WSSF only allows XSD *types* as messages in service contracts and not elements, and the tag name than becomes the name of the type). As a result I can’t create a client using the original WSDL and call the generated service successfully. The only way I’ve successfully generated a client and called the service is by using the generated WSDL.


So for me at least WSSF does not provide significant benefits (not even with this enhancement), which I think is a shame. The main disappointment comes from the fact that what I consider the most important usage scenario is not supported.


The ability to take a service contract – and WSDL is the king of service contracts – and implement a service implementation that fulfills that contract, is every bit as important as being able to implement a service consumer based on the service contract (see my previous post for examples). And I suspect that this is where the real problem lies – it does not seem that the developers of WSSF agree.  


I wonder why this is so – before I became a .NET proponent, I used to play for the Java team, and there were a number of tools that would let me create a service based on a WSDL. But contract-first development in .NET has always been an uphill battle, and I do not understand why this is. At least the old ‘wsdl.exe’ helped my towards that goal, but WSSF actually takes me further away.


So for me it’s back to the drawing board – perhaps a more complex WSDL import may help solve the issues, but I’m not overly optimistic. As I’ve said: as long as WSSF does not take contract first development using WSDL seriously, then my productivity using .NET is nowhere near as high as it should be – and since I make my living competing on (amongst other things) productivity that is a big problem.

Jul 2, 2008 at 5:37 PM
Hi Jacob, thanks for the feedback! Can you please provide further details regarding the input WSDL you used for this test and how did the ouput look like? This would help us towards to reproduce your scenario and analyze it better.