For the few MSMQ or NetMsmqBinding WCF users I’ve encountered, here is an error you may encounter in a highly secured environment.

0xC00E008F Binding to the forest root failed. This error usually indicates a problem in the DNS configuration. MQ_ERROR_DS_BIND_ROOT_FOREST

This is most likely another firewall problem. If port 3268 is not open, MSMQ cannot register or authenticate with the user’s certificate in AD. Here is the port description:

3268/TCP,UDP msft-gc, Microsoft Global Catalog (LDAP service which contains data from Active Directory forests)

Despite its pitiful adoption in the developer community, I am implementing Transactional NTFS (TxF) transactions using the Microsoft.KtmIntegration.TransactedFile class. This allows me to reap the benefits of TransactionScope and distributed transactions for file operations (e.g. creates, updates, deletes). This is the only missing piece for typical transactional business applications. With the “KTM” and “KtmRm for Distributed Transactions” services, available only on Vista, Windows 7, and Windows Server 2008, file operations will roll back if the TransactionScope is not completed.

There’s just one problem… Transactional NTFS does not work with file shares. I can’t remember the last time I put a “C:\FileStore” reference in a config file. A friendly share like “\\server\FileStore” is always preferred, especially since DFS came about. Attempting to use a share results in the following error message:

The remote server or share does not support transacted file operations

Don’t read this as “your remote server” or “your remote share”, but rather “all remote servers and shares”. As mentioned in this MSDN article, TxF is not supported by the CIFS/SMB protocols. The error was probably written with the expectation that one day some remote servers and shares would support TxF. I emailed Microsoft about it and received a response fairly quickly. The response was simply:

“We understand the need and have plans to eventually support TxF over SMB2, but we’re not there yet and are not ready to announce if or when this will be supported. When it is the documentation will be updated.”

I’m not getting my hopes up, but Windows Server 2011 looks to be our only hope before .NET changes beyond recognition and TxF is a distant memory. Until then, I wrapped up all of my TxF code in a WCF service and install that service on the server with the FileStore folder.

MSDN article – When to Use Transactional NTFS

      http://msdn.microsoft.com/en-us/library/aa365738(v=VS.85).aspx

TxF Sandbox – Sample Projects (including Microsoft.KtmIntegration.TransactedFile)

      TxFSandbox.zip

The sole 2010 offering in the USA of IDesign’s Architect’s Master Class conducted by the man himself, Juval Lowy, is only a few weeks away. I checked in at the IDesign web site, and found some updates the world needs to see.

• The IDesign C# Coding Standard – updated for .NET 4.0
• The IDesign WCF Coding Standard – updated for .NET 4.0
• The IDesign Code Library - updated for .NET 4.0, including Azure AppFabric Service Bus extensions and the Service Bus Explorer (priceless)

If you want to learn something new every day, start at the top of the IDesign Code Library and step through one example each day. Be careful, you might need to re-write every line of code you’ve ever written.

In a previous post, I discussed solutions to the dreaded “The flowed transaction could not be unmarshaled” error commonly experienced when using MSDTC transactions with WCF, SQL, TxF, etc. I have once again experienced the un-trusted domain scenario, and can now report with certainty that adding hosts file entries on both machines will correct the problem. Testing this solution with DTCPing.exe between the two machines proves that making only the hosts file change acquaints the client and server and allows distributed transactions to occur.

You will find many blog and forum post non-solutions. Adding the hosts file entry or the equivalent domain redirects are the only solutions when working with two machines in disparate, un-trusted domains. Some of the non-solutions you’ll find go so far as to say to change your SQL connection string to prevent current (ambient) transaction enlistment. Not quite a complete solution as your first rollback unit test will fail.

If you have a WCF service exposing endpoints with the NetMsmqBinding, you may come across my old pal, error code 0xc00e002f when you have web application clients. If you’ve already had your required interactive login on the web server with your AppPool’s service account and have already registered your AppPool service account’s user certificate for message queuing, then you should be ok.

If you are using IIS 7 or 7.5, there is one more piece to the puzzle. Go into Advanced Settings on your Application Pool, and find “Load User Profile” under the Process Model section. “Load User Profile” on these latest versions of IIS needs to be true to get your service account’s user certificate passed to MSMQ. I fought this for a while before finally finding it. And now… :)

I’ve been talking about Geneva for a long time. I got the basics down earlier in the year. I tried to come up with my own set of sample apps, but failed to get anywhere. With the official release, and renaming to Windows Identity Foundation (WIF), I have renewed inspiration.

I read Michele Leroux Bustamante’s MSDN magazine article, Claim-Based Authorization with WIF, last night. After reading the article, I was confident that I could get a claims-aware WCF service stood up with a custom STS in a matter of hours. Today I downloaded and installed WIF. I also installed the WIF SDK and all of the prerequisite hotfixes. I perused the readme files and looked through some of the samples code. Everything is layed out sensibly, the samples are commented sufficiently, and the samples include setup and cleanup batch scripts when necessary.

The samples include:

Quick Start

1. Simple Claims Aware Web Application
2. Simple Claims Aware Web Service
3. Simple Web Application With Information Card SignIn
4. Simple Web Application With Managed STS
5. Claims Aware Web Application in a Web Farm
6. Using Claims In IsInRole

End-to-end Scenario

1. Authentication Assurance
2. Federation For Web Services
3. Federation For Web Applications
4. Identity Delegation
5. Web Application With Multiple SignIn Methods
6. Federation Metadata

Extensibility

1. Claims Aware AJAX Application
2. Convert Claims To NT Token
3. Customizing Request Security Token
4. Customizing Token
5. WSTrustChannel
6. Claims-based Authorization

All of the samples I’ve run through so far are great. The only thing that I’m not in love with is all the XML required to wire this stuff up. Maybe some Juval-style extensions would make it less painful.

One more thing… it looks like all of the XP users will finally have to upgrade. WIF only works with Vista, Win7, and Win2008. I heard that Win2003 compatibility will arrive in December.

Download Windows Identity Foundation

Download Windows Identity Foundation SDK

Using the NetTcpBinding on a WCF service is secure by default. Unless you override the default settings, you will enjoy Transport Security using Windows authentication and the EncrpytAndSign protection level. When you create a new WCF service library, Visual Studio creates a config file with the following identity block:

If you wipe this config file clean like me to write a much cleaner and shorter config file, this identity block is the first thing to go. Sadly, most people also add a binding configuration with <security mode=”None”/>. I have done this too in an Intranet environment. The samples and book examples out there don’t show how to write an actual production environment service that cares for different machines in the same domain. While the default settings work when testing on your local machine, they don’t work in a simple Intranet environment.

Most of the difficulty I experienced when starting to work with WCF was getting security to work with the TCP binding. Everything worked so easily during development, but everything broke down once deployed to the development server. It didn’t help that the only errors I saw were timeout exceptions. If I had known about the Service Trace Viewer, I could have easily determine the cause and Googled (Bing wasn’t around then) for a solution. Instead, I chose the easier (and much less secure) way out… rely on my firewall and turn security off.

As mentioned before, the NetTcpBinding is secure by default with transport security using Windows authentication. The problem most experience when moving the service to a different machine is caused by NT authentication failing. If you use svcutil to generate your client config file and your host doesn’t have the identity block mentioned above, svcutil will not add a key piece of information to the client config file. The missing element is, you guessed it, the identity block. Without it, you will likely get an exception and see a stack trace similar to this:

[System.ServiceModel.Security.SecurityNegotiationException: A call to SSPI failed, see inner exception.]
...
[System.Security.Authentication.AuthenticationException: A call to SSPI failed, see inner exception.]
...
[System.ComponentModel.Win32Exception: The target principal name is incorrect.]
...

If you add tracing to your client, you will see that without specifying an identity block WCF will make the call with a DNS identity set to the name of the host. Notice the blue arrows.

You can see that the EndpointReference does not have an <Identity> block. Without that identity block, WCF cannot create a valid ServicePrincipalName. You can find this in Reflector, following this path:

• System.ServiceModel.Channels.WindowsStreamSecurityUpgradeProvider+WindowsStreamSecurityUpgradeInitiator.OnInitiateUpgrade() – This is where the SecurityNegociationException is being thrown.
• System.ServiceModel.Channels.WindowsStreamSecurityUpgradeProvider+WindowsStreamSecurityUpgradeInitiator.InitiateUpgradePrepare() – This method populates an EndpointIdentity and ServicePrincipalName to be used immediately after for NT authentication.

When the identity is not specified, it falls back to trying to create an SPN from the host address. I have seen this work on a machine that has two DNS names, using the DNS name that does not match the NETBIOS or AD name for the machine. I’m not exactly sure why that works.

Having any of the following identity blocks in your client config file will cause WCF to take the first path that successfully creates an SPN needed to perform NT authentication in the AuthenticateAsClient method called from OnInitiateUpgrade():

• <dns value=”serviceHostName”/>
• <dns/>
• <servicePrincipalName value=”domain\hostServiceUserAccount”/>
• <servicePrincipalName/>

Having these <Identity> settings in your client config file adds the appropriate <Identity> settings in the <EndpointReference> used when opening the channel.

Security seems more mysterious when going rogue and writing your own config files. If you go rogue, make sure you use the appropriate <Identity> blocks. With this mystery solved, <security mode=”None”/> is a thing of the past. Now we can keep our services secure in an Intranet environment.

I was privileged to attend the IDesign WCF Master Class last week. It only comes to the USA one time each year, and is presented by the one and only Juval Lowy. The class is held at the training center on the Microsoft Silicon Valley campus in Mountain View, CA. Five very intense days of WCF covering all aspects of WCF from essentials like the ABCs to the most intricate details about advanced topics like concurrency, security, transactions, and the service bus.

What we’ve been told sold about WCF from Microsoft is truly just the tip of the iceberg. Juval presents countless examples that prove WCF is not just about web services. WCF is the evolution of .NET, providing world-class features that no class should ever be without.

Demos, samples, and labs are presented using .NET 3.5 and 4.0 with an emphasis on the new features and functionality in 4.0. Discovery and announcements are the most underrated and unknown new features of WCF 4.0. After seeing Juval’s demos on discovery and announcement, I can’t imagine creating services without them.

More than all of the WCF content, the class gives you a lot to think about regarding architecture, the framework, and engineering principles. Juval’s mastery of .NET is evident in his ServiceModelEx library that extends almost all aspects of WCF and the service bus. His “one line of code” motto makes it possible for all of us to configure our WCF services with ease. The ServiceModelEx library is a good example for all developers to know and understand how to “do .NET” the right way. It exemplifies the best of what .NET and WCF have to offer.

Check out the IDesign website to get the WCF Resource CD (containing many of the examples and demos from the class). Also note the next class dates and sign up for the IDesign newsletter.

Thank you, Mikael Sand (and Bing)!

http://blogical.se/blogs/mikael_sand/archive/2009/08/28/configuring-ws-atomic-transaction-support-in-windows-7-64-bit.aspx

• PowerPoint slides
• Transaction Promotion Code Snippet
• Testing database backup
• Testing SQL script (query and cleanup between tests)
• IDesign ServiceModelEx Project (used by all included Solutions)
• Code Demo Solutions

Code Demos include:

Download the session files:
TransactionalWCF.zip (854 KB)

JaxDug is doing something different this year having all sponsorship proceeds benefiting Wolfson’s Children Hospital. In addition to the sponsorship surplus going to Wolfson’s, there will also be a silent auction at the after-party at Sneaker’s Sports Grille.

There is a great session lineup with eight tracks having five hour-long sessions in each track. I’ll be presenting one session on Transactional WCF Services. It’s guaranteed to be a good geeky time, and I hope it will have record attendance this year.

 Register now!

Important, proven, and universally-useful technologies like WCF and Mobile are still not well-known in the development community. Many believe there is another boom, similar to the 1992 Internet boom, on the horizon that will require skilled and knowledgeable developers to engineer the framework and associated connecting systems. Staying tech-current and adapting to our new world is an absolute necessity. Don’t become the COBOL programmer of the future. Knowing these great system-connecting technologies (WCF, Mobile, Cloud, etc.) will quickly become a requirement to compete in the software industry.

Check out the following interview with Richard Campbell (DotNetRocks, RunAs Radio) and Juval Lowy (IDesign) talking about the EnergyNet at the DevConnections conference. The growing hype about alternative energy and the EnergyNet is stunning. Technology has progressed far enough where we can start to tie together disparate systems to benefit producers and consumers alike.

http://video.google.com/videoplay?docid=4831440850220717845

It’s obvious that Mr. Franklin didn’t have to deal with bad data, bad code, or even the occasional hiccup. In the real world, there is “trouble” and we need to not only anticipate that trouble, but also worry about what may never happen. Simply “keeping in the sunlight” won’t maintain data or application state integrity. In the real world we need transactions!

Since .NET 2.0, we’ve had the privilege of using System.Transactions.TransactionScope to manage our transactions with very few headaches. One of the headaches that almost everyone experiences is MSDTC. One of the oldest and most elusive topics on the web. There are tons of blog and forum posts directing our fellow developers to check their firewall settings for every MSDTC problem. The latest MSDTC hiccup I have seen comes in the beautifully packaged error message:

The flowed transaction could not be unmarshaled. The following exception occurred: Communication with the underlying transaction manager has failed.

The what could not be what? You can read some MSDN documentation on the topic which will probably cause you more pain. If you are seeing this error message, there’s only a few things that may be wrong.

1. MSDTC Settings
   • Check the MSDTC settings on the machine that is initiating the transaction. If “Allow Outbound” is not checked, then it won’t allow the transaction in progress to be flowed to the next machine in the transaction chain. Check the box and restart MSDTC… it should work.
2. Un-Trusted Domains
   • I have seen this error when you are trying to flow transactions between machines that are in un-trusted domains. Machines in different domains that do not trust each other block the antiquated, yet necessary, WINS resolution between the two machines. MSDTC relies on WINS resolution. I have fixed this problem before by adding host file entries on both machines pointing to the other machine. I can’t guarantee that this will work in all cases. Both of those machines are no longer under my control.
3. Imaged Servers
   • The most recent, and most blogged about problem is surprisingly caused by two machines created from the same image. Cloning or imaging servers is quite common. Building a server from scratch is not a fun activity, so we build one, create an image, and put that image on every server we want to build after that. Once again, MSDTC is standing in our way because of the way it detects the sending and receiving application’s unique identifier. Each machine has a GUID in the registry that identifies it uniquely as a participant in an MSDTC transaction. Imaged machines have the same GUID. I’ll talk about the detection and resolution of this for the remainder of this post.

Running DtcPing.exe between the two machines will actually tell you that the machines are using the same GUID. Output window text from DtcPing shown below.

DTCping log file: C:\DTC Ping\THRESHER4160.log
Firewall Port Settings:
Port:5150-5250
RPC server is ready
Please Start Partner DTCping before pinging
WARNING:the CID values for both test machines are the same
Please send following LOG to Microsoft for analysis:
Partner LOG: SCORPION6128.log
My LOG: THRESHER4160.log

Tucked away in the last step of a Microsoft Knowledge Base article titled "How to troubleshoot MS DTC firewall issues" is a reference to this problem. Use regedit.exe to look at the registry on both machines. Locate the HKEY_CLASSES_ROOT\CID key in the registry.

Find the CID key that has a description value of “MSDTC”. If they are the same, the transaction cannot flow.

WARNING: Back up your registry before making any changes!

Solution 1 - Replace the offending CID keys/values on one of the machines: In this case, you will need to find all keys/values with GUID 28b81f1c-2afb-4ee2-ad85-5bc62dad1647 in your registry and replace it with a new GUID (using GuidGen). There is likely to be 3 places this GUID appears. It is also important to note that the offending GUID appears in the DtcPing log file generated during the ping test.

Solution 2 – Use msdtc command line tool to re-install MSDTC: The commands are simply:

msdtc -uninstall
msdtc -install

After making the registry changes or running the msdtc command line tool, you must restart your server for the changes to take effect.

Don't be so quick to blame the service or MSDTC when you see the error "Communication with the underlying transaction manager has failed."

Symptom:

An error message that reads something like:

System.Transactions.TransactionManagerCommunicationException: Communication with the underlying transaction manager has failed. ---> System.Runtime.InteropServices.COMException (0x80004005): Error HRESULT E_FAIL has been returned from a call to a COM component.

Solutions:

"Check your firewall settings" is what you will find in almost all forum posts and on MSDN. You need port 135 open bi-directionally for RPC's end point mapper (EPM). You also need ports 1024-5000 open bi-directionally if you have not specified your own port settings for RPC in the registry. If you have your own ports specified in the registry, then those need to be open bi-directionally.

WHAT ?!? It may also be your code causing the issue. If you are using TransactionScope, you have to be mindful of every method called within the using braces. Looking at the code below, you will see two service calls and a seemingly innocuous ShouldContinue() method checking to see if the second operation should be called.

using (TransactionScope scope = new TransactionScope())

using (MyServiceClient proxy = new MyServiceClient())

{

       proxy.DoOperationOne(someID);

      

       if (ShouldContinue()) // uh, oh! What if this has an ADO.NET connection that is opened and closed inside it?

       {

               proxy.DoOperationTwo(someOtherID);

       }

}

If ShouldContinue() opens and closes an SqlConnection, the TransactionScope object has no means by which to commit or rollback this part of the transaction. This will cause the error "Communication with the underlying transaction manager has failed."

1. If you do not need to results of DoOperationOne() to feed ShouldContinue(), then do that logic before the TransactionScope using block.

2. If you do need the result of DoOperationOne() to feed ShouldContinue(), then you can wrap the internals of ShouldContinue() with a TransactionScope using block specifying TransactionScopeOption.Suppress. This will not add the resource access contained within the block to the ambient transaction.

3. Use an intelligent data access library like Enterprise Library that manages your connections for you. It won't close the connection if enlisted in a transaction.

Look at your code before you involve your network dudes. This is more common when integrating legacy code with new service calls.

WCF never ceases to amaze me. Around every corner is another fascinating use for WCF, and much forethought on Microsoft's part to make it look and behave great. I wanted to expose my services to my AJAX functions on my web site. I did not want to change my class library because it is used by other clients. I could just add the service classes to this web site, but why re-do when you can re-use.

If you have an existing WCF Service Library, you will need to expose it with the AspNetCompatibilityRequirementsMode.Allowed attribute on the service class to make it visible to ASP.NET clients. To avoid changing your service library in any way, the easiest thing to do is to add a new class to your web site that inherits from your service class. In this example, my existing service library uses the JeepServices namespace. Notice there is no implementation in this class. It is simply a placeholder for the real service implementation with the compatibility attribute attached.

Now that I have a ASP.NET compatible service, I need to expose it to the web site clients. Create a service file (.svc), and change the Service and CodeBehind attributes to point to the .svc file. The last thing you need is the Factory attribute. This notifies WCF of this service, eliminating the need for a configuration file entry for the service endpoint. In fact, you don't even need the <system.servicemodel> in your configuration file at all. This is because it is only hosted as a web script, and cannot be called outside of the web site.

In your web page you will need a few things. First your will need a ScriptManager with a ServiceReference to the .svc file. You will then need the Javascript functions to make the call (DoJeepWork), handle the success message (OnJeepWorkSucceeded), and handle the failure message (OnJeepWorkFailed). Notice in DoJeepWork that you don't call the service by it's service name WebHttpService, you call it by the ServiceContract namespace and name. For this example, my interface has ServiceContract attributes Namespace = "JeepServices", and Name = "JeepServiceContract". Now you just wire up a ASP.NET control's OnClientClick or an input or anchor tag's onclick to DoJeepWork() and you are good to go.

Mission accomplished! Here you've seen how to expose an existing WCF service library without changing any code in the library itself. Adding two files allowed the service to be exposed to your AJAX clients. Best of all, there is no configuration file changes to make.

Useful Links:

• Exposing WCF Services to Client Script

Hosting an MSMQ service is a little bit different than the other bindings. Since WCF is using MSMQ as a transport mechanism, you must setup the queues, permissions, and bindingConfigurations to allow this to happen. Surprisingly, MSDN has a good sample article that goes into sufficient detail on how to set this up for the 3.5 WF-WCF-CardSpace samples.

I have read in other articles that the AppPool must have an interactive identity and that the queue names needed to match the name of the .svc file. I did not find this to be the case. I was able to use the NetworkService account for my AppPool after adding receive and peek permissions for NetworkService on my queue. Communication between client and WAS worked fine with my service file named WasServices.svc and my queue address as net.msmq://localhost/private/QueuedService1.

You can download my solution with the following link: WasServices.zip (78K)

Additional Info:

• MSMQ Activation (MSDN)
• IDesign Code Library - Look for the WAS Hosting download

It has taken me weeks to get WAS (Windows Activation Service) working. Finally, tonight, my long hours of research has paid off. After everything I tried, it turned out to be a general IIS7 issue caused by a stray http reservation that I probably entered months ago during some testing. As I primarily use the built-in development server for web development, I rarely crank up an IIS site on my development machine.

This post by Phil Haack helped me fix my IIS install:

http://haacked.com/archive/2007/05/21/the-iis-7-team-rocks.aspx

I have been cursing IIS7, Vista, and WAS for weeks. I should have been cursing my own lack of IIS7 knowledge all along. Now that it's working, I am a big fan of WAS. From the tone of recent forum responses and blog posts, very few people are using WAS. Maybe it is due to Windows Server 2008 being so new. Not many people have Vista workstations for development and all Windows Server 2008 servers to deploy to. Knowing how many problems I had, I can only assume others are experiencing the same thing. The only real info available right now is pre-release articles and MVP posts about the new features with a sneak peak example on how to get it to work. Even MSDN doesn't show how to use an existing WCF Service Library with WAS. They just walk through a WsHttpBinding example as a new WCF web site served up by WAS.

I'm posting the details so others will maybe see that it's really not that hard. For this example I want to expose this service with the NetTcpBinding to prove that it is not IIS hosting the service. I used the WCF Service Library project template for my WCF service, and named the project WasServices. So the lame Service1 service is all I have in the library. I made no changes to the project and built it in release mode to get the DLL. Some posts and articles out there say that the only way to get WAS to work is to have an HTTP-based WCF web site. This is simply not true. You just need to have an application set up in IIS.

Here is the steps to success:

1. Enable the required Windows Features to wake up IIS7 and WAS. You will find these in the helpful links below.

2. Configuration file C:\Windows\System32\inetsrv\config\applicationHost.config must be modified to enable the required protocols on your web site and application. You can modify the file yourself, or use command-line utilities.

To enable net.tcp on the web site, if it is not already:

%windir%\system32\inetsrv\appcmd.exe set site "Default Web Site" -+bindings.[protocol='net.tcp',bindingInformation='808:*']

To enable net.tcp on your application (my app is named WasServices) within that web site, if it is not already:

%windir%\system32\inetsrv\appcmd.exe set app "Default Web Site/WasServices" /enabledProtocols:http,net.tcp

Here is an exerpt from the applicationHost.config file showing the site and application settings:

  151             <sitename="Default Web Site" id="1" serverAutoStart="true">

  152                 <applicationpath="/">

  153                     <virtualDirectorypath="/" physicalPath="%SystemDrive%\inetpub\wwwroot" />

  154                 </application>

  155                 <applicationpath="/WasServices" applicationPool="WasHosting" enabledProtocols="http,net.tcp">

  156                     <virtualDirectorypath="/" physicalPath="C:\inetpub\wwwroot\WasServices" />

  157                 </application>

  158                 <bindings>

  159                     <bindingprotocol="net.tcp" bindingInformation="808:*" />

  160                     <bindingprotocol="net.pipe" bindingInformation="*" />

  161                     <bindingprotocol="net.msmq" bindingInformation="localhost" />

  162                     <bindingprotocol="msmq.formatname" bindingInformation="localhost" />

  163                     <bindingprotocol="http" bindingInformation="*:80:" />

  164                 </bindings>

  165             </site>

3. Prepare the application in your application folder (C:\inetpub\wwwroot\WasServices)

Create a service file (WasServices.svc) that points to your existing WCF service library:

    1 <%@ServiceHostService="WasServices.Service1"%>

 

Create a web.config file that specifies the service's endpoints:

    1 <?xmlversion="1.0" encoding="utf-8"?>

    2 <configuration>

    3     <system.serviceModel>

    4         <services>

    5             <servicename="WasServices.Service1"

    6                     behaviorConfiguration="MEX">

    7                 <endpointaddress="wsHttp"

    8                           binding="wsHttpBinding"

    9                           contract="WasServices.IService1"/>

   10                 <endpointaddress="netTcp"

   11                           binding="netTcpBinding"

   12                           bindingConfiguration="NetTcpBinding_Common"

   13                           contract="WasServices.IService1"/>

   14                 <endpointaddress="mex"

   15                           binding="mexHttpBinding"

   16                           contract="IMetadataExchange" />

   17             </service>

   18         </services>

   19         <behaviors>

   20             <serviceBehaviors>

   21                 <behaviorname="MEX">

   22                     <serviceMetadatahttpGetEnabled="true"/>

   23                 </behavior>

   24             </serviceBehaviors>

   25         </behaviors>

   26         <bindings>

   27             <netTcpBinding>

   28                 <bindingname="NetTcpBinding_Common">

   29                     <reliableSessionenabled="true"/>

   30                     <securitymode="None"/>

   31                 </binding>

   32             </netTcpBinding>

   33         </bindings>

   34     </system.serviceModel>

   35 </configuration>

 

Place the release-compiled DLL created from the WCF Service Library in a new folder named Bin.

4. At this point, you can browse and see the familiar "You have created a service." page for Service1.

5. Write your proxy file and config file.

WAS and IIS7 decide the address for your service, and it is not intuitive.

    1 <?xmlversion="1.0" encoding="utf-8" ?>

    2 <configuration>

    3     <system.serviceModel>

    4         <client>

    5             <endpointaddress="net.tcp://localhost/WasServices/WasServices.svc/netTcp"

    6                       binding="netTcpBinding"

    7                       bindingConfiguration="NetTcpBinding_IService1"

    8                       contract="WasServices.IService1"

    9                       name="NetTcpBinding_Common" />

   10         </client>

   11         <bindings>

   12             <netTcpBinding>

   13                 <bindingname="NetTcpBinding_Common">

   14                     <reliableSessionenabled="true" />

   15                     <securitymode="None" />

   16                 </binding>

   17             </netTcpBinding>

   18         </bindings>

   19     </system.serviceModel>

   20 </configuration>

 

The /netTcp at the end of the address is due to the address specified in the service's web.config file. The address was given there as simply netTcp. This is because IIS7 and WAS decide your address based on the available bindings and ports you specified in the applicationHost.config file using appcmd.exe. Since my enabled protocols are http and net.tcp and the only open tcp port is 808, you will not see a port number in the address. The same would go for my wsHttpBinding since the only allowable port is 80.

I'm proud to be the fourth, and maybe final, member of the "Got WAS to work" club. If anyone wants to join, and needs help to get in... please let me know.

Here are some helpful links for those of you having problems:

• Hosting a WCF Service using IIS7 and Windows Vista
• Host a WCF Service in IIS 7 & Windows 2008 - The right way
• Hosting WCF Services in Windows Activation Service

Why clutter your inbox with error messages? Why make special code provisions for users to receive error messages via email? Why not log your error messages and have users subscribe to receive them in their favorite RSS aggregator?

If you are logging your exceptions already, you may find it easier to provide a syndication service. The process is ridiculously simple, and starts by creating a new project using the "Syndication Service Library" template. This template creates everything for you. All you need to do now is fill the SyndicationFeed with SyndicationItem objects.

Add a new class file called Feeds.cs:

Modify the App.config file:

You will need to adjust your project's Debug options to have command arguments that look similar to the following to F5-debug your service.

"/client:iexplore.exe" "/clientArgs:http://localhost:8000/Feeds/Errors?env=Production&app=GeoTracker"

Press F5 to test it out.

Here is the IE7 RSS viewer:

Here is your RSS aggregator viewing the same feed:

You will, of course, want to add some additional information to the content of your SyndidationItem, a bogus phrase works for this example.

Also, it is unusual that you would care to keep your exception details around for a long period of time. Since this is a syndicated feed of application errors, you should make special arrangements to archive or delete your exception log on a regular basis. This will not only keep your insert and select times low, but will also alleviate the burden placed on a new subscriber when all of the exceptions from the database appear at once. An alternative would also be to modify the LINQ in the code above to only bring back exceptions from the last 7-60 days depending on your counts. I already archive my exceptions to a master exception repository for all environments by way of an ETL job. This way I can report on my errors without disturbing the live environments too.

Our friends at Microsoft may have slipped one in on us. After installing the 3.5 Framework Service Pack 1, it appears that you no longer need the [DataContract] or [DataMember] attributes on your DataContracts and DataMembers. I'm not sure what the motivation was for this "enhancement", but it caused some trouble for me the other day.

For this example I will be using the base project VS2008 gives you when you create a new WCF Service Library. I am simply adding a NestedType to the CompositeType given in the base project.

Before installing SP1, having code as it appears below would cause an error during Metadata Exchange that reads something like "Metadata contains a reference that cannot be resolved". Notice that CompositeType's NestedObject is marked as [DataMember] and also notice that the NestedType class is not marked as [DataContract] and has no [DataMember] attributes. Adding [DataContract] on NestedType and [DataMember] on IsVisible will clear this error and everything will work as expected. 

The same code in use after SP1 will not cause this error. WCF will interpret from CompositeType's [DataContract] attribute and NestedObject's [DataMember] attribute that you meant to put [DataContract] on NestedType. So what's the big deal, right? WCF is doing me a solid by guessing at what I meant to do. To me, this violates the repeated opt-in theme present in WCF. For every other important decision, the developer must write code to opt-in to a feature. For example, TransactionFlow defaults to false so we don't use the client's incoming transaction with explicitly writing code that says to do so.

This is clearly not on the same level as TransactionFlow. But why does it assume something about my objects? Why does it assume that every member of my object should be a DataMember?

I noticed this new "feature" when troubleshooting some code that had different namespace names specified in the DataContract attribute. Since the NestedType did not have a [DataContract] attribute, the namespace was using the original namespace name. The equivalent of CompositeType came through correctly, but the NestedObject had no value.

Juval Löwy mentioned the Microsoft Service Trace Viewer in a webcast today. If you ever wondered exactly what WCF does under all of those covers, check this out.

First things first. Enable tracing on the client and host applications using the WCF Configuration Editor. Enable the verbose trace level and check all of the listener settings. This will add all of the necessary <system.diagnostics> settings in your config file. The next time you start each of the applications, a .svclog file will be created that will be used by the Service Trace Viewer.

Start your host, start your client, run through the test cases that you want to analyze in the viewer. After your test run is complete, open the viewer, located at C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\SvcTraceViewer.exe. "Open" the host.svclog file, and then "Add" the client.svclog file. Both "Open" and "Add" are menu items under "File".

Start on the Activity tab, look through the host and client activities that occurred. Everything from ServiceHost construction through ServiceHost closing shows up. This is very cool, especially when analyzing the differences between different security, session, and reliability settings.

When you are done looking through the activities, check out the Graph tab. Here you can look at the interactions between the client and host, as well as looking at the details of each activity (at the top right). At the bottom right, you will also notice the formatted and xml details of this activity.

This is a very cool tool for both debugging and training. Below is my lame test projects, if you want to skip past the configuration and check out the tool. My .svclog files are located in the Client and Host folders.

SvtTest.zip (190.32 KB)

Enjoy! Thanks to Juval for the direction.

I was looking for guidance on this topic, and came up with nothing. I'm sure people are doing this, but can't find any info. For anyone looking like I was, here's how to do it.

It's much simpler than I imagined, thanks to WCF. You can programmatically create your endpoint, binding, and channel inside your service. This would require that the address be hard-coded and require a recompile to change the address or binding. As long as your host's app.config or web.config has a client endpoint specifying the contract, you don't have to go through all that work. Your service is simply a client of another service, so your code looks just like that of a client of your service. Furthermore, changing the address or binding is as simple as changing config file values.

Service code:

If you haven't heard me praise Juval Löwy's book Programming WCF Services or Michele Leroux Bustamante's book Learning WCF: A Hands-on Guide yet... these books are the best WCF books available. Every question I have had has been answered by these two books. In fact, most of the forum and newsgroup resolutions out there come from one or both of these books. If you haven't already, check out their IDesign Code Library and and the IDesign WCF Coding Standard at www.IDesign.net.

OK, problem and resolution of the day... how do I generate a proxy file with the same collection class as my service implementation. My service uses List<T>. WCF converts this to be a more interoperable array of T. When you generate the proxy, it is generated with T[]. To be able to enjoy the same collection features as the service, you only need a few more parameters on svcutil.

Example 1: Generate proxy with T[]

svcutil http://localhost:8080/EmailService /out:EmailServiceProxy.cs /noconfig

[System.ServiceModel.

OperationContractAttribute (Action= "http://tempuri.org/IEmailService/MyOperation2" , ReplyAction= "http://tempuri.org/IEmailService/MyOperation2Response" )]
string[] MyOperation2(string myValue);

Example 2: Generate proxy with List<T>

svcutil http://localhost:8080/EmailService /out:EmailServiceProxy.cs /noconfig /ct:System.Collections.Generic.List`1

[System.ServiceModel.OperationContractAttribute(Action="http://tempuri.org/IEmailService/MyOperation2", ReplyAction="http://tempuri.org/IEmailService/MyOperation2Response")]
System.Collections.Generic.List<string> MyOperation2(string myValue);

Before you try running a Console Application or Windows Service application that hosts a WCF service with basicHttpBinding or wsHttpBinding, see this MSDN article about "Configuring HTTP and HTTPS". If you are WAS-hosted or Web App-hosted, the urlacl entries are made on your behalf.

You can view the current entries with "netsh http show urlacl". To make the changes, you'll need to "Run as Administrator" when going into your Command Prompt.

I decided to use the following command:

netsh http add urlacl url=http://+:8080/ user=\Everyone

You should adjust the ports and/or path as necessary for your situation:

netsh http add urlacl url=http://+:8080/MyConsoleAppHostedService user=DOMAIN\user

netsh http add urlacl url=http://+:8091/MyWindowsServiceHostedService user=\SYSTEM

WCF is seamless, powerful, and (YES) interoperable. Here is a quick walkthrough detailing steps to call your legacy PHP web services from a WCF client. All of the binding types and security options are, of course, not available. But for those of you following the old "security through obscurity" model, this will work fine.

1. Create client proxy
2. Add client endpoint to your client config file
3. Write your proxy-consuming client code

Create the client proxy:

Nusoap provides a similar UI when navigating to your PHP web service to that provided by ASMX services. You can view the WSDL, and copy the URL for svcutil.exe.

From the Visual Studio 2005 Command Prompt, type:

svcutil <url> /out:<name>Proxy.cs /noconfig
svcutil http://gotjeep.net/services/ApproachAngleService.php?wsdl /out:ApproachAngleServiceProxy.cs /noconfig

This generates a file named ApproachAngleServiceProxy.cs.

Add client endpoint to your config file:

You have the option of letting svcutil create your config file or using "Generate Service Reference", but I prefer to avoid the extra 20+ lines of config file defaults included by svcutil. It's not hard to write it yourself, and it ensures a much more readable config file.

Write the client code:

    1 using System;
    2 
    3 namespace Client
    4 {
    5     classProgram
    6    
{
    7    
    staticvoid Main(string[]
args)
    8    
    {
    9    
        using (GotJeepApproachAngleCalculatorPortTypeClient proxy
=
   10        
        newGotJeepApproachAngleCalculatorPortTypeClient())
   11        
    {
   12        
        decimal result
= proxy.CalculateApproachAngle(25.6m, 33.2m, 17.75m);
   13        
        Console.WriteLine("decimal
result = proxy.CalculateApproachAngle(25.6m, 33.2m, 17.75m);");
   14        
        Console.WriteLine("result
= " + result.ToString("0.00"));
   15        
    }
   16        
}
   17     }
   18 }

Check it out:

A request-reply call between WCF and a Nusoap PHP web service.