Walter Almeida's Blog

Running PowerShell Scripts for SharePoint

Still in the process of implementing the Fenomen Platform (www.fenomen.pro) and especially the capability to generate applications for SharePoint and deploy them to SharePoint, I am generating and running PowerShell Scripts aiming at configuring SharePoint. I had the following issue:

When I run my script from a command shell, every goes fine. However when I had one of my applications launch the script, I ran into the following exception:

dd-PSSnapin : No snap-ins have been registered for Windows PowerShell version 2.At C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\CONFIG\POWERSHELL\Registration\sharepoint.ps1

I did some research and found out that the issue was that the 32 bit of PowerShell was launched instead of the 64 bits. That said, my script specifically calls the 64 bit version of PowerShell! (C:\Windows\System32\WindowsPowerShell\v1.0\PowerShell.exe)

The issue was that my application was built targeting x86 processors and thus ran in 32 bits. And the call to the 64bits version of PowerShell was therefore automatically redirected by the OS to the 32 bits version of PowerShell (C:\Windows\SysWOW64\WindowsPowerShell\v1.0)

Solution was to change the build options of my application to target x64 processors!

 

IIS7 - Private Memory Limit Versus Virtual Memory Limit

In the process of implementing the Fenomen platform (www.fenomen.pro), I decided to configure IIS so that hosted applications on my server would not bring the machine down because of high and uncontrolled memory usage. It happened to me indeed that one my applications started to consume memory up to no limit, quickly using all the memory available and rendering the server unusable... 

To that purpose I did set the Private Memory Limit and Virtual Memory of my AppPools to 500M0 to make sure a flawed application won't bring the machine down. Indeed if either the Private Memory Limit or  Virtual Memory would go higher than 500Mo then the AppPool would automatically be recycled, the flawed process killed, and memory freed.

However, following this action, I had the following problem: my AppPools did recycle too often, almost at every single request, even though the memory usage was low!

After some research I found the cause of my trouble:

If you are on a 64bit platform (and I am), ASP.NET app's aggressively reserve virtual memory. It's also important to understand that on a 64bit platform, reserving large portions of virtual memory has zero performance impact. Therefore, the Virtual Memory Limit is reached very quickly, even thought the process is making low usage of private memory! This renders the AppPool Virtual Memory Limit useless on 64bit machines...

Therefore solution is:

Do not set any AppPool Virtual Memory Limit, just set the AppPool Physical Memory Limit.

Hope this can help others!

 

The new Golden-Egg : Model-Driven Business Platforms – Why big players aren’t there yet?

There is a big fuzz around model driven development and all the goodness about it, its promises of a high level of agility, cut down of prices, reduction of technical risks etc. etc. Many including myself (having created FENOMEN) think that the model-centric approach is the future of software development, and several companies are doing their business of it and build the next generation platforms and tools for creating agile business applications.  

So, why on earth is it that big ISV players like Microsoft, Sun, IBM did not clearly entered the game and just let emerging companies share the cake? If it is so much a golden egg, such big companies should have given it a try and invest a few million on it?

For information: I exclude here IBM MDA tools (Rational tools) from the discussion, as I am talking here about tools targeting business users, and functional modeling + generation of ready to use business applications. The Rational tools are modeling tools but targeting technical users. An example of a company building such business oriented model-driven platforms is FENOMEN.

Here are my own thoughts, and I would be very keen on having your comments and thoughts on the matter!

Why big ISV players do not use a Model-Driven approach for their own products development?

First of all, even though we have been hearing about model-driven development for many years now, a full model-driven / model-centric process is still quite a new approach and you see only a few companies largely adopting it. And main reason is we just start to having matured enough technologies and practices to enable a really efficient model-driven approach. And it is now that model-driven tool vendors of today are competing for being the big players of tomorrow!

Today’s big ISV players like Microsoft, IBM and Google are well-established companies, with a highly technical background and spirit and with well-established and efficient development processes and methodologies. A fully model-driven approach to software development is a huge paradigm shift from a classical development process, and why (and most important: How?) would you want  to apply such a big-bang on a company that has already performed well for so many years and knows how to do it well? Well change is good, and they will probably change, but they have a huge code base and millions of engineers to train, and change management is costly. So a fast and large move is not an option and too high risk. 

Well, actually they probably already do use some model-driven tools for their own internal use. At least tools and technics that help better the productivity of the developments. However these tools remain internal to their teams and used for very specific parts of their developments. For instance Microsoft built and uses a templating and code generation engine (T4 templates), extensively used as part of Visual Studio environment and used for instance to generate code for user interfaces and web services proxies. 

 

Why big ISV players did not create model-driven tools for their customers?

 As we already said: moving from a classical, code-centric approach toward a model-driven / model-centric approach to software development is a huge paradigm shift. If a company wants to build model-driven tools, they should already have applied these new concepts to themselves. A model-driven approach is not something you can theoretically lay down on a paper without previous concrete experience. While the basic concepts can appear as simple: you create a meaningful and extensive meta-model and you generate code from the model (or interpret the model), the practical application is not that easy and you have to learn the pitfalls and best practices by actually doing it yourself.

This is the “eat your own dog food principle”, so dear to Microsoft and so essential for our matter. So: big players will be in a position to develop model-driven platforms and tools for their customers when and only when they will have made the paradigm shift themselves and become experts on the matter. This is why IMHO, the leading model-driven tools of today are developed by emerging, new companies.  Leaving an option for big players to enter the game which is to buy one of these successful companies!

A word about OSLO: the Microsoft attempt to enter the Model-Driven game

A few years back, Microsoft announced their commitment to a new set of technologies: M and the OSLO platform. 

M is known as a declarative language that provides developers with an approachable, textual format for authoring models and domain-specific languages (DSLs) for those models. In other words: M is a language for creating custom, domain-specific languages.

OSLO was initially supposed to be a platform to model and host business application, with the support of M language and a SQL Server back-end. It was therefore supposed to be a full model-driven business platform.

OSLO was then renamed SQL Server Modeling Project, changing the focus of the platform from a generic model-driven business platform targeting any kind of end-user business application, to a SQL Server specific tool for modeling databases. The target user base therefore moved from business users to… architects and developers! That was the end of OSLO as a true model-driven business platform for building business applications! Why? In my opinion, probably partly because of the reasons explained above. And also because Microsoft first business is to sell server applications, SQL Server being on of their golden eggs. So they did not miss an opportunity to refocus OSLO as an extra layer on top of SQL Server, for the benefits of their SQL Server customers base.

End 2010: Microsoft cancelled the OSLO/SQL Server Modeling project, driver for cancelling being: low anticipated market demand. My own guess being that the refocus of OSLO killed OSLO: OSLO primary goal really was to build a model-driven platform for building business applications. The refocus was maybe done because of an internal failure of implementing the full model-driven platform (reasons above). However the refocus was done on a business need that was not primarily identified as such… 

Remains: M as a language. Which is fair enough: It is part of Microsoft business to build languages and they already are successful on this market with their range of Microsoft.NET languages. So we can conclude that it is not an easy task, even for big players, to try to extend their business model to new areas…

Any comments are most welcome!

[EDIT] : I posted the same discussion on the Model Driven Software network, you can see the full discussion and many comments/feedback there:

http://www.modeldrivensoftware.net/forum/topics/the-new-goldenegg-modeldriven

And also another interesting discussion on the matter:

http://www.modeldrivensoftware.net/forum/topics/agile-business-application

Season's Greatings - FENOMEN 2010 Achievements

2010 is almost over now. It is time for us to wish all the best to all our friends, family, customers and partners. May 2011 bring your health, happiness, success and harmony in your personal and professional life!

via blog.fenomen.pro

Introducing my favorite ORM Tool: LLBLGEN - Part 2

Ok, time to write again about LLBLGen, my favorite ORM tool. It has been my favorite ORM for years now and I did write a post on the subject several years ago: http://blog.walteralmeida.com/2008/09/introducing-my-favorite-orm-tool-llblgen.html - So this is why I call this post "Introducing my favorite ORM Tool: LLBLGEN - Part 2" :)

For information, I will talk only about the new features that were of higher interest to me. There's much more, so check out Llblgen web site for more info: http://www.llblgen.com

So here we go: Llblgen is now more than never still my favorite tool: since version v3.0; the tools supports several well-known ORM frameworks: Entity Framework, Linq to SQL, NHibernate and of course the Llblgen framework. You now have to a single designer that let you build a data access layer using the ORM framework of your choice. For information, I am still using the Llblgen framework, can’t help it…

And IMHO, the most amazing new feature of all is… the support of model-first development! This was a must have. In the previous version, you had to start from an existing database schema to build your entity model and data access layer on top of it. It is no more the case: you gain in abstraction and can actually start from your entity model! The tool will generate for you the database schema on the target database of your choice, all based on your model. The tool is even capable of generating for you update scripts to integrate your entity model changes to the database: modification, creation and deletion scripts.

Important also to realize that you don’t lose the database first feature: shall you want to build on top of an existing database, or keep full control of your database schema: you still can start from your existing database. And… you can actually mix both and build a part of the data layer in a model first approach and build the rest following a database first approach, which could be a great option if you want to extend an existing database or keep control of mission critical sections of the database schema. You can also start database first and switch later to model first or the other way round. Let’s say: it is very flexible and implemented in a very loose coupled way making all these scenarios possible. I guess this will keep everybody happy and give the option to big believers of one or the other of the approaches to give a try to the other one!

Ok just one word about my view: I am a big believer of the model first approach, in a general way, that is: not only for the data layer, but for full enterprise application. I was therefore very happy when Llblgen V3 came to life!

What else could I say… Oh yes: you now have a graphical designer (called model views) allowing you to build entity models in a very user friendly way. It is also a must have to share with business people on the design of your business model.

What’s more? Full XML project file, which proves very useful to properly integrate Llblgen into your development lifecycle. Indeed, if you follow a model first approach, you then have to consider the model (here the Llblgen project file) as a first class citizen artifact of your project and therefore you should be able to compare versions of your models between several iteration. This is mandatory for proper design reviews. Well no problem to use your standard tooling on top of the Llblgen XML file!

In terms of code and product quality, no need to say that it is top quality, anyone who knows Frans Bouma will understand what I am saying:) No comment: great code, both the generated code and the code base. Nice and neat and effective and bug-free. Well there is no bug-free code, but this code could be considered bug-free when comparing to many other small and big companies. Even the V3 Beta 1 version was already of high quality. And this is essential for a tool that generates code and is targeted at developers. And if you manage to point out a bug: you'll get great first support and have a fix pretty soon available! To be honest: I was much more happy with Llblgen Support than with IBM support... 

Ok now my favorite: extensibility. Llblgen Pro is highly extensible in many ways. And extensions can be written by building on top of the Llblgen SDK. BTW this is actually where you get an even more clear idea of the quality of the underlying Llblgen code. And this is essential for today’s software applications to have this extensibility capability because this is how an eco-system can be built around. In that context, as part of FENOMEN Project (www.fenomen.pro), we have been building for the last two years innovative products that allow the modeling and generation of full enterprise, business applications. And we built on top of Llblgen Pro which is our core ORM framework and entity model designer. This use of Llblgen was essential to quick-start our research and development efforts and build products that really add value to existing market solutions. Indeed why creating what’s already there and took years and years of work to others to master? We are big believers of the “compose and reuse” paradigm: never create what’s already out there: reuse and compose the best of what’s on the market today, and build only what does not exist yet! So stay tuned, you’ll hear about FENOMEN the year to come and will see a great example of the potential of Lllblgen extensibility. And for all whom already now, use and love LLBLGEN, you’ll get a great opportunity to go much further than your best expectations when using LLBLGEN with FENOMEN extensions. Curious? More information in 2011!

 

 

 

 

 

 

SilverLight 4.0 + WCF: How to bubble service error messages to client

Developing with SilverLight 4.0 and WCF for the service side, I wanted to do the following:

1- For known/expected service side exception, I want the user to have a clear feedback with the error message shown to him

2- For all exceptions, and for development scenarios, I want the full exception message displayed back to the user.

I used to do that very easily with rich client (WPF) + WCF service. You indeed just need to add the following behavior, server side, to your service:

 

  
<behavior name="metadataAndDebug">
   <serviceDebug includeExceptionDetailInFaults="true"/>
</behavior>

 

Using SilverLight however, this is not enough. Even with the behavior set, you get the following error message at the client level

the server returned an error :  not found

Not very useful... After some research I found out this is due to a limitation of web browsers and the HTTP stack: By default, WCF services return fault messages with an HTTP 500 response code. Due to limitations in the browser networking stack, the bodies of these messages are inaccessible within Silverlight, and consequently the fault messages cannot be read by the client.

This source from Microsoft explains two workarounds to the issue:

http://msdn.microsoft.com/en-us/library/ee844556(VS.95).aspx

The one I used is the following:

Modify the HTTP status code: You can modify your service to return SOAP faults with an HTTP status code of 200, Silverlight 4 so that faults will be processed successfully. How to do this is outlined below. Note that this will make the service non-compliant with the SOAP protocol, because SOAP requires a response code in the 400 or 500 range for faults. If the service is a WCF service, you can create an endpoint behavior that plugs in a message inspector that changes the status code to 200. Then you can create an endpoint specifically for Silverlight consumption, and apply the behavior there. Your other endpoints will still remain SOAP-compliant. 

This is done by create the following behavior extension:

 

  
public class SilverlightFaultBehavior : BehaviorExtensionElement, IEndpointBehavior
    {         
        public void ApplyDispatchBehavior(ServiceEndpoint endpoint, EndpointDispatcher endpointDispatcher)
        {
            SilverlightFaultMessageInspector inspector = new SilverlightFaultMessageInspector();
            endpointDispatcher.DispatchRuntime.MessageInspectors.Add(inspector);
        }
        public class SilverlightFaultMessageInspector : IDispatchMessageInspector
        {     
            public void BeforeSendReply(ref Message reply, object correlationState)
            {
                if (reply.IsFault)
                {
                    HttpResponseMessageProperty property = new HttpResponseMessageProperty();

                    // Here the response code is changed to 200.
                    property.StatusCode = System.Net.HttpStatusCode.OK;

                    reply.Properties[HttpResponseMessageProperty.Name] = property;
                }
            }

            public object AfterReceiveRequest(ref Message request, IClientChannel channel, InstanceContext instanceContext)
            {
                // Do nothing to the incoming message.
                return null;
            }
        }

        // The following methods are stubs and not relevant. 
        public void AddBindingParameters(ServiceEndpoint endpoint, BindingParameterCollection bindingParameters)
        {
        }

        public void ApplyClientBehavior(ServiceEndpoint endpoint, ClientRuntime clientRuntime)
        {
        }

        public void Validate(ServiceEndpoint endpoint)
        {
        }

        public override System.Type BehaviorType
        {
            get { return typeof(SilverlightFaultBehavior); }
        }

        protected override object CreateBehavior()
        {
            return new SilverlightFaultBehavior();
        }

    }

 

And registering server side this way:

 

  
<system.serviceModel>
    <extensions>
      <behaviorExtensions>
        <add name=”silverlightFaults” 
             type=”Microsoft.Silverlight.Samples.SilverlightFaultBehavior, 
             SilverlightFaultBehavior, 
             Version=1.0.0.0, 
             Culture=neutral, 
             PublicKeyToken=null”/>
      </behaviorExtensions>
    </extensions>
    <behaviors>
        <endpointBehaviors>
          <behavior name=”SilverlightFaultBehavior”>
            <silverlightFaults/>
          </behavior>
        </endpointBehaviors>
    </behaviors>
    <services>
        <service name=”Calculator.Web.Service”>
            <endpoint address=”” 
                      binding=”basicHttpBinding” 
                      contract=”Calculator.Web.Service” 
                      behaviorConfiguration=”SilverlightFaultBehavior” />
        </service>
    </services>
</system.serviceModel> 

 

Warning: There was an issue in SilverLight 3.0 which is still not fixed in SilverLight 4.0:

The Type for the extension has to be specified in one line, with the correct number of white spaces... type definition is checked as string comparison rather that Type comparison... Be aware of that!

 

 

DataContract Serializer and IsReference property

Today I ran into the issue sending object graphs that contain reference cycles through WCF. I then got the following exception:

Object graph for type contains cycles and cannot be serialized if reference tracking is disabled

The default WCF serializer can't serialize object graphs with cycles. After some research on how to solve the issue, I found the following blog post:

 http://zamd.net/2008/05/20/datacontract-serializer-and-isreference-property/

Basically, In .net Framework 3.5 SP1, DataContractSerializer supports by-ref object graph serialization by using the standard xsd:ID/xsd:IDREF attributes. 

You can set the IsReference=true on your DataContract definition and serializer will generate XML elements with IDs/IDREFs attributes and will link them together rather embedding them inside each other(default behavior). 

Also if you examine the XSD generated by WCF as part of the metadata export, it will also contain the standard ID/IDREF xml schema attributes. Because of this, xml can be correctly parsed and understood by any framework in a standard way. 

This change will enable serialization of object graphs having circular references (which wasn’t possible previously – at least not without writing custom code) and will also reduce the size of the serialized xml. 

That solved my issue, Great thing to know!

CG2011 Coming! + Feedback from Code Generation Conference 2009

The next year Code Generation conference (CG2011) is being prepared. Will be help in Cambridge from May 25th-27th 2011

You will find more by following this link:

http://www.codegeneration.net/cg2011/

The Code Generation conference is recognised as the leading event on the practical applications of Model-Driven Software Development and is a must for those interested in the subject. I have been attending the last two years an will go again in 2011!

I have just read a feedback I wrote about the 2009 Conference with some reflexions about the final discussion panel. After reading back, I am realizing that the content is quite sensible, and especially for me while being in crucial phase of FENOMEN Development (www.fenomen.pro). So here is the copy of this talk:

Hi all!

It was my first time at the code generation conference and I must say it was a great experience! This is why I want to drop a few lines on the subject.

I am a very big believer of the model driven development approach. Actually, I have always been looking for and experimenting ways to improve software development productivity, quality and reusability in any form that would prove useful. And the picture I have in mind today is that MDSD and its derivatives are an excellent direction to follow in that respect. And it is just a direction because for me the MDSD approach is a set of concepts and a guide to follow to finally reach the (one) proper solution for a specific (any ideally many specific) problem to solve. My view is that nobody should be too dogmatic and preach for THE solution and THE principles to follow.

Many sessions were very interesting and it was for me a way to meet new people, hear great ideas, and extend my perspectives and viewpoints on software development and specifically model driven development, and I was relieved to see that no: I am not alone out there thinking about crazy things that nobody wants to hear nor understand. We are not that many but hey!! Who wants to be like everyone? I want to be special and different, and researching and developing around MDSD approach makes me different! The D day when MDSD will be common widely appreciated and used approach with all required tools available, I will just go my way and find something new and different to investigate on and promote.

I want to say a final word about some sentences I would qualify as almost philosophical as compared to all the technical stuff we talked about during this conference. These were words said by Steve Cook that I found extremely interesting and with great potential for those ready to hear them and put them into practice for better efficiency. But first of all: the final panel was a great mixture of ideas and perspectives and a good conclusion to the conference, I loved it!

I will rephrase the sentences since I don’t have the precise words in memory and hope I will not derive too much from the original words. First sentence was that “People only understand solutions to problems they have”, and second one was: “People will continue doing things the way they do because this is the way people are”. For me these two sentences put on the table the extra card of the human being and the fact that 90% of the people will just don’t see things like us, will be less open to new ideas and even less open to the problems of the community and very selfish and concentrated on their own immediate business need and daily problems…

Hey guys! We are doing great innovative and exciting stuff, but we should not forget that it will be not easy to generalize these ideas and have them adopted by the vast majority for the reasons explained above. Markus Volter would say (final panel): I don’t care if I can myself have access to the right tools and keep providing service to my clients the way I think is best for them. Well, I cannot agree more somehow, however the wide adoption of a concept by the majority is probably also the best way to make it grow and evolve and promote competition and investments to really go a big step further and also mandatory to convince companies that this is the way, or at least one serious and reliable way to go.

So my conclusion on Steve’s words is that we should never forget that: no matter how great and fantastic and promising tools or approaches one might develop and foster, if it is not presented the right way and through the right angle to the world , it will then just die. So when presenting a product, a tool or an approach to your customer, or boss, or colleague, forget about the 10 thousand wonderful features and promises it has because no-one cares and no-one understands if not directly related to their own and immediate needs and problems. And when I say “no-one” I want to say the mere mortal, the Mr. X who represents 90% of the persons you will ever to talk to.

So just target your presentation and speech and show to the people what they want to hear, what can really help them now and just now in their very specific and important (for them at least) case! And talk different and go deeper if you feel there is response and understanding on the other side. Seems very obvious but is actually not at all!

And related to the second sentence is the human tendency to be reluctant to changes: people will not easily change the way they work or the tools they use! So the changes have to be simple, guided and straightforward which is obviously not easy if your objective is to introduce a paradigm shift to software development. So my belief is that a major shift of the industry toward Model Driven Software Development will only happen if the proper tools are available to help and guide the shift, because most of the people won’t do a sole mental shift with the existing tools, that’s much too difficult. The sole mental shift is possible as MDSD is an approach that can be followed with the existing tools, but require a very big investment and will to do so.

Well that was my last word and conclusion on CG2009! Thanks a lot to everyone for contribution, great share of ideas and thanks a lot to the great organization: that’s was a wonderful welcoming. And… see you next year; I hope I will have great new stuff to share with all of you!

 

 

Patch for Unity 2.0 with Interception of generic classes with interface constraints

This article relates to Unity 2.0 (April 2010 release) and Microsoft Enterprise Library 5.0 (April 2010 release)

When using Unity with Interception and Virtual method based interception, there is an exception thrown when trying to intercept a generic class with interface constraints on the generic type(s).

Example of such a generic class that will cause an exception when intercepted:

public MyClass<T> where T : IMyInterfaceConstraint
{
}

The exception thrown is:

FailedSystem.ArgumentException: Cannot set parent to an interface

Looking at the Unity source code, we can find that the bug is thrown from method DefineGenericArguments of the InterceptingClassGenerator, line 17:

 private static void DefineGenericArguments(TypeBuilder typeBuilder, Type baseClass)
 {
 if (!baseClass.IsGenericType) return;

 Type[] genericArguments = baseClass.GetGenericArguments();

 GenericTypeParameterBuilder[] genericTypes = typeBuilder.DefineGenericParameters(
 genericArguments.Select(t => t.Name).ToArray());

 for (int i = 0; i < genericArguments.Length; ++i)
 {
 genericTypes[i].SetGenericParameterAttributes(genericArguments[i].GenericParameterAttributes);


 foreach (Type constraint in genericArguments[i].GetGenericParameterConstraints())
 {
 genericTypes[i].SetBaseTypeConstraint(constraint);
 }
 }
 }

This code has to be changed for the following:

 private static void DefineGenericArguments(TypeBuilder typeBuilder, Type baseClass)
 {
 if (!baseClass.IsGenericType) return;

 Type[] genericArguments = baseClass.GetGenericArguments();

 GenericTypeParameterBuilder[] genericTypes = typeBuilder.DefineGenericParameters(
 genericArguments.Select(t => t.Name).ToArray());

 for (int i = 0; i < genericArguments.Length; ++i)
 {
 genericTypes[i].SetGenericParameterAttributes(genericArguments[i].GenericParameterAttributes);

 List<type> interfaceConstraintList = null;

 foreach (Type constraint in genericArguments[i].GetGenericParameterConstraints())
 {
 if (constraint.IsClass)
 genericTypes[i].SetBaseTypeConstraint(constraint);
 else
 {
 if (interfaceConstraintList == null)
 interfaceConstraintList = new List<type>();

 interfaceConstraintList.Add(constraint);
 }

 }

 if (interfaceConstraintList != null)
 genericTypes[i].SetInterfaceConstraints(interfaceConstraintList.ToArray());
 }
 }

The Unity Dlls then have to be rebuilt, and all the Enterprise Library DLLs having reference to the Unity DLLs (because after rebuilding Unity, the assembly is no more strongly typed since we obviously don't have the Microsoft private key).

That's it, problem solved. Just hope this will be solved in a future release of Unity.

WCF tips and tricks: share types between server and client

This is an interesting and essential trick for WCF and sharing types between server and client.

Here is the scenario: at the server service implementation: you define types, essentially data structures, that you will return through service methods:

Let say you define the following data type (don't forget the DataContract and DataMember attributes since this type will be passed through the WCF service)

namespace MyTypes
{
 [DataContract]
 public class MyDataTransfertObject
 {
 [DataMember]
 public int Value1 { get; set; }

 [DataMember]
 public string Value2 { get; set; }
 }
}

And the following service interface:

namespace MyService
{
 [ServiceContract]
 [ServiceKnownType(typeof(MyDataTransfertObject))]
 public interface IMyService
 {
 [OperationContract]
 MyDataTransfertObject GetDataTransfertObject();

 [OperationContract]
 void SaveDataTransfertObject(MyDataTransfertObject dataTransfertObjectToSave);
 }
}

Next step if to implement your service, by creating a class implementing your IMyService interface, and then deploy your service.

You can now create a client application, and add a reference to your service, in order to consume your service methods. If you do so without any extra step, Visual studio will create for you a proxy and as part of the proxy, it will generate data structures to represent your data contracts, including your custom MyDataTransfertObject:

Here is your generate proxy;

[System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "4.0.0.0")]

 [System.ServiceModel.ServiceContractAttribute(ConfigurationName="MyServiceReference.IMyService")]
public interface IMyService 
{
 [System.ServiceModel.OperationContractAttribute(Action="http://tempuri.org/IMyService/GetDataTransfertObject",ReplyAction="http://tempuri.org/IMyService/GetDataTransfertObjectResponse")]
 MyTypes.MyServiceReference.MyDataTransfertObject GetDataTransfertObject();
 
 [System.ServiceModel.OperationContractAttribute(Action="http://tempuri.org/IMyService/SaveDataTransfertObject", ReplyAction="http://tempuri.org/IMyService/SaveDataTransfertObjectResponse")]
 void SaveDataTransfertObject(MyTypes.MyServiceReference.MyDataTransfertObject dataTransfertObjectToSave);
 }

You see that Visual studio has generated for you a data type: MyTypes.MyServiceReference.MyDataTransfertObject, to represent the data structure you created on the service side. This is the proper behaviour since in a SOA world, your client should be independent from your service: no shared types should be involved (you could have a client that does not understand the service side technology. Example: a java client consuming a .NET Service).

However, in pure .NET environments (client and service being implemented in .NET), it can be very convenient to share data type between client and service. For instance if your create at service side a data structure that include behaviour (example: self-tracking entities), it will be essential that you can share this implementation with your clients. Here is the trick to do so with the Visual Studio wizard to add references to services:

First, it will be convenient to define your data structures you want to share in a separate assembly than the service implementation. This is to make sure you won't have to share your entire service implementation with your clients! Your service will therefore reference the assembly containing your data structures.

Then, in your client project, add a reference to your assembly containing your data structures BEFORE adding a reference to your service.

When you now add your service reference, no new types will be created, the data structures defined in your assembly are used and therefore properly shared between you service and client. Here is the generated proxy:

 
 [System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "4.0.0.0")]
 [System.ServiceModel.ServiceContractAttribute(ConfigurationName="MyServiceReference.IMyService")]
 public interface IMyService {
 
 [System.ServiceModel.OperationContractAttribute(Action="http://tempuri.org/IMyService/GetDataTransfertObject", ReplyAction="http://tempuri.org/IMyService/GetDataTransfertObjectResponse")]
 MyTypes.MyDataTransfertObject GetDataTransfertObject();
 
 [System.ServiceModel.OperationContractAttribute(Action="http://tempuri.org/IMyService/SaveDataTransfertObject", ReplyAction="http://tempuri.org/IMyService/SaveDataTransfertObjectResponse")]
 void SaveDataTransfertObject(MyTypes.MyDataTransfertObject dataTransfertObjectToSave);
 }

You see that your own MyTypes.MyDataTransfertObject data structure is used instead of the generated MyTypes.MyServiceReference.MyDataTransfertObject

For more information about what happens under the hood: in the "add service reference" wizard windows, click on the "Advanced..." button. The following window is then displayed:

 

You see that by default, Visual Studio uses types defined in referenced assemblies.

That's it!  Download here the full test project, Visual Studio 2010