If you want to know more, check out these 2 new blogs that we launched:

• Intellipad Team Blog
• MLanguage Team blog
  

DataContract types are uniquely identified using a namespace qualified name (namespace uri and a name). This namespace uri is used as the targetNamespace in XSD schemas created for that DataContract.

If a namespace uri is not specified when a DataContract is created, one is automatically created based on the CLR namespace of the type and using the prefix "http://schemas.datacontract.org/2004/07/". (If you do not place your types in a CLR namespace then just the prefix is used).

To keep generated code as clean as possible, the client code generator doesn't generate an explicit namespace declaration if it doesn't have to. The problem with this approach is that VB.NET projects can affect the namespace of types using a root namespace. In the abscence of an explicit namespace uri declaration, changing a types namespace will also change it's schema which will affect it's wire representation.

As Ali pointed out, using the /namespace option with svcutil will fix the issue because the types namespace no longer maps directly to the auto-generated namespace and the code generator will have to explicitly define the namespace uri. Another way to make sure this doesn't happen is to define a namespace uri explicitly on the server. This should also cause the client to generate an explicit namespace uri definition.

You can also work around this by not not using a root namespace in your poject.

Note: This issue does not apply to service contracts because the default namespace does not affect wire communications.

How do you restore the default .zip file association in Windowx XP or Vista? It wasn't as simple as right clicking and selecting "Open with.." which is what I tried for about 5 minutes. turns out you can restore it this way though:

cmd /c assoc .zip=CompressedFolder

Thanks goes to Ramesh Srinivasan for pointing out how to do this: http://windowsxp.mvps.org/zipfldr.htm

http://www.xbox.com/en-US/live/marketplace/moviestv/default.htm

Renting movies from Blockbuster was nice.
Renting movies from Netflix was even better for my lazy but.
Renting movies without ever having to leave the couch is priceless...

http://www.netfx3.com/blogs/news_and_announcements/archive/2006/11/06/.NET-Framework-3.0-has-been-released_2100_.aspx

It's a great feeling.

/reference can have multiple meanings/behaviors depending on the what you're trying to do. A lot of thought was given to changing the parameter to make things clearer but adding yet another flag to svcutil seemed like it would be just as confusing.

In almost all modes, the /reference option can be used to help svcutil.exe locate assemblies that it might need to load. When passed an executable assembly, svcutil may also load the config file associated with that assembly (if one exists). If there are types referenced from config that are not in the GAC and svcutil needs to load and svcutil needs to load them, the assemblies may need to be provided via the /reference option.These types could be extensions, service behaviors, or service implementations in library dlls. I think of this /reference behavior as being similar to the csc.exe /lib option.

During client code generation, the /reference option can be used to avoid generating types that already exist on the client machine. svcutil will examine the assemblies passed to it for contract types (DataContract and ServiceContract but not MessageContract in v1). Whenever it encounters a type in metadata that it thinks is the same as an existing type it found it will reference the existing type instead of creating a new one. This can be useful if multiple services share the same DataContracts or implement the same ServiceContract. In this mode it's actually acting to provide svcutil with a list of existing contract types. I think of this /reference behavior as being somewhat similar to the csc.exe /reference option.

The /excludeType option complements the /reference option by allowing individual types to be excluded from  the collection svcutil loads. consider the following command line:

svcutil myServiceHost.exe /serviceName:myServiceName

Since the serviceName attribute is referring to the configuration name of the service, It's completely valid to have 2 services with the same configuration name (using the ConfigurationName property on the ServiceBehavior attribute. If this were the case, the excludeType option could be used to indicate which type should not be loaded thereby clearing up the ambiguity. Similarly, when reflecting over an assembly to generate a list of existing types, there could be 2 CLR types that represent (or seem to represent) the exact same DataContract. Again to resolve the ambiguity we can use the /excludeType option to prevent one of the types from being loaded.

/excludeType has one more use. Even without the /reference flag, the /exclude type can be used to prevent Service Contract types from being loaded. When exporting service contracts from an assembly like this:

svcutil myAssembly.dll

Ordinarily the command-line above would export all contracts in the service but the use of the /excludeType option can be used to limit the set of contracts that are exported.

I hope this explanation clears up the /reference flag a little bit. If there are any other svcutil pain points you want to me to blog about let me know.

When using Duplex Channels it's often the case that you want to receive callbacks on a separate thread. For example, If you're waiting on some notification message from the server and would like to use a ManualResetEvent to block on receiving this message you'll find that in the default configuration your callback method never gets called. Over simplified versions of the 2 contracts in question are shown below:

[ServiceContract(CallbackContract = typeof(CallbackContract))]
public interface ServiceContract
{
    [OperationContract(IsOneWay=true)]
    void Register();
}
public interface CallbackContract
{
    [OperationContract(IsOneWay=true)]
    void Notification();
}

Assuming the following server implementation of the Register method

public void Register()
{
    OperationContext.Current.GetCallbackChannel<ICallbackContract>().Notify();
}

Given these 2 contracts one might expect to be able to write a button click event-handler in a WinForms client like this:

public partial class Client : Form, ICallbackContract
{
    static ManualResetEvent mre = new ManualResetEvent(false);

    public Client(string[] args)
    {
        InitializeComponent();
    } 

    private void button1_Click(object sender, EventArgs e)
    {
        IServiceContract service = DuplexChannelFactory<IServiceContract>.CreateChannel(this, "callback");

        service.Register();

        /*
         *
         * Do some other stuff here
         *
         */

        mre.WaitOne();

        /*
         *
         * Work that cannot be done until we receive a 
         * notification from the server.
         *
         */
    }

    void ICallbackContract.Notification()
    {
        Client.mre.Set();
    }
}

Unfortunately, the code in the Notification method above will never get called on the client side. This is because the default threading behavior of WCF causes callbacks to all run in the same SynchronizationContext. Since there is another thread in that synchronization context blocked waiting for notification to get called you effectively have deadlock.

Solution: Disable the use of synchronization contexts on your callback by applying a CallbackBehavior attribute to your callback implementation.

[CallbackBehavior(UseSynchronizationContext = false)]

Applying the attribute above to the class implementing your callback will allow you to receive callbacks while in a wait or while some other thread is executing in the WinForms SynchronizationContext. 

An alternative is to use the Background worker when making calls to the service. This will run outside the WinForms Synchronization context and allow incoming calls to run without blocking. Either way, you will need to be careful about calling Winforms methods from your callback methods since they won't run on the  UI thread. I like the first approach a little better especially if you set things up in the Form's Load method.

I don't know a whole lot about the SynchronizationContext class. I learned a bit from a post on Matt Dotson's blog and Stephen Toub talks about it a bit in a .Net Matters article. Hopefully someone on the WCF team will blog about this in a bit more detail.

Update: When I *nudged* Michael, he pointed out that I should just put the code I needed running after the postback all in the callback method. for a lot of cases this is indeed a better option. If you don't absolutely have to (and you rarely do) don't put a Wait in the UI thread. It's ugly and results i na bad user experience.

In our particular case we should have popped up a progress dialog with a spinning icon or other whiz-bang thing-ama-jig and used the background thread to wait. that way we could add a cancel dialog as well. However this was a port of exisitng code and refactoring the application wasn't an option.