.Net

WCF Message Authentication Failure

Paul Petrov — Tue, 11 Aug 2009 14:59:57 GMT

Recently, while debugging desktop client - WCF service application I came across this error:

System.ServiceModel.Security.MessageSecurityException was caught
Message=”An unsecured or incorrectly secured fault was received from the other party. See the inner FaultException for the fault code and detail.”
Source=”mscorlib”
StackTrace:
Server stack trace:
at System.ServiceModel.Channels.SecurityChannelFactory`1.SecurityRequestChannel.ProcessReply(Message reply, SecurityProtocolCorrelationState correlationState, TimeSpan timeout)
at System.ServiceModel.Channels.SecurityChannelFactory`1.SecurityRequestChannel.Request(Message message, TimeSpan timeout)
at System.ServiceModel.Dispatcher.RequestChannelBinder.Request(Message message, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs)
at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)
Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)

InnerException: System.ServiceModel.FaultException
Message=”An error occurred when verifying security for the message.”

Client was connecting basic http binding with security mode TransportWithMessageCredential. All other desktop clients were able to successfully call WCF service but not this particular one. Thanks to this post the issue was quickly understood and resolved. Apparently, the client machine was a brand new netbook just out of the box and clock was way off. Interesting thing that Windows automatic clock synchronization did not work.

Storing BizTalk settings in custom configuration file using Enterprise Library

Paul Petrov — Wed, 11 Jun 2008 20:12:37 GMT

Choice of configuration settings storage is an important topic when it comes to enterprise BizTalk application planning. One of the many options is to use regular .Net configuration files. Some prefer this way over the Enterprise SSO database option for reasons of simplicity and familiarity. I wanted to show how it can be done with Microsoft Enterprise Library configuration application block.

In this case Enterprise Library configuration section is placed in the BTNTSvc.exe.config file while application settings are stored in a separate configuration file. The problem here is how do we make EntLib to load required settings file at runtime. Its done by simple helper class CustomSettings that looks up registry entry for the location and name of the application configuration file and creates FileConfigurationSource with it. The registry entry can be created by MSI installation package.

The initialization method of this static helper class looks like this (thread synchronization code omited for brevity):

          RegistryKey regKey = null;

          try
          {
             regKey = Registry.LocalMachine.OpenSubKey(@"Software\MyCompany\MyApplication");
             configurationFile = Path.Combine(
             (string)regKey.GetValue("ConfigDir"),
             (string)regKey.GetValue("ConfigFile"));

              ExeConfigurationFileMap fileMap = new ExeConfigurationFileMap();
              fileMap.ExeConfigFilename = configurationFile;
              configuration = ConfigurationManager.OpenMappedExeConfiguration(fileMap, ConfigurationUserLevel.None);
              configurationSource = new FileConfigurationSource(configurationFile);

              //- store configPath in the settings
              configuration.AppSettings.Settings.Add(
              new KeyValueConfigurationElement("configDir", (string)regKey.GetValue("ConfigDir")));
           }
           catch (Exception ex)
           {
              Debug.WriteLine("Exception while initializing Settings:" + ex.ToString());
              throw ex;
           }
           finally
           {
              if (regKey != null) regKey.Close();
           }

Then it has method to access properties by name:

        public static string GetValue(string name)
        {
            KeyValueConfigurationElement entry = Configuration.AppSettings.Settings[name];

            if (entry == null)
                throw new ConfigurationErrorsException("Key '" + name + "' is not found in the configuration file.");

            return Configuration.AppSettings.Settings[name].Value;
        }

Which is used as in:

string propertyValue = CustomSettings.GetValue("propertyName");

MSBuild Tasks for BizTalk Continuous Integration

Paul Petrov — Tue, 10 Jun 2008 01:04:19 GMT

If you store BizTalk application settings in Enterprise SSO database and adapt continuous integration you'll find this MS Build task useful. DeploySSOConfigStore task reads settings from XML configuration file and saves them to the SSO database. The XML can be created (exported) using Richard Seroter's SSO tool which I modified to support this operation. So, if you change your configuration settings, just update XML file in the source control and build process will pick it up and propagate changes to your target environment. Using this task is very simple, it accepts just one parameter - location of the XML settings file:

    <UsingTask AssemblyFile="CustomMSBuildTasks.BizTalk.dll" TaskName="CustomMSBuildTasks.BizTalk.DeploySSOConfigStore"/>

    <Target Name="DeploySSOConfigStore" DependsOnTargets="BizTalkDeploy">
        <CustomMSBuildTasks.BizTalk.DeploySSOConfigStore XmlConfigurationUrl="$(SolutionRoot)\$(BuildBranch)\Source\BizTalkSettings\BizTalk.Configuration.xml"/>
    </Target>

I also added another useful task for publishing WCF services: PublishBizTalkWcfServices. It's very simple but does all that stuff: setting up virtual directories (if needed), publishing contracts, creating receive locations. It has comprehensive logging that helps tracking down deployment issues quickly.

    public class PublishBizTalkWcfServices : Task
    {
        private string serviceDescriptionUrl;

        /// <summary>
        /// The URL to the description file.
        /// </summary>
        [Required]
        public string ServiceDescriptionUrl
        {
            get { return serviceDescriptionUrl; }
            set { serviceDescriptionUrl = value; }
        }

        /// <summary>
        /// Publishes BizTalk schemas as WCF services.
        /// </summary>
        /// <returns></returns>
        public override bool Execute()
        {
            WcfServiceDescription description = WcfServiceDescription.LoadXml(ServiceDescriptionUrl);

            Publisher publisher = new Publisher();
            publisher.BackgroundWorker = new System.ComponentModel.BackgroundWorker();
            publisher.BackgroundWorker.WorkerReportsProgress = true;
            publisher.BackgroundWorker.ProgressChanged += new System.ComponentModel.ProgressChangedEventHandler(BackgroundWorker_ProgressChanged);

            try
            {
                PublishingResults results = publisher.Publish(description);

                Log.LogMessage(results.Message);
            }
            catch (Exception ex)
            {
                Log.LogError(ex.ToString(), null);
                return false;
            }
            return true;
        }

        public void BackgroundWorker_ProgressChanged(object sender, System.ComponentModel.ProgressChangedEventArgs e)
        {
            Log.LogMessage(e.UserState.ToString(), null);
        }
    }

Complete Visual Studio project is available here.

Improved SSO Configuration Data Store Tool

Paul Petrov — Fri, 16 May 2008 20:54:34 GMT

Richard Seroter published useful utility to store/retrieve BizTalk configuration settings in Enterprise SSO database. I added some more functionality to it.

First, I added Export/Import functions allowing to actually save values in the external XML file (Richard's implementation allowed storing only field names, calling for extra work should you delete and restore SSO aplication). I kept file format the same but added values stored as text nodes:

<sso>
  <application name="eCommerce.BizTalk.Configuration">
    <description>Configuration storage for eCommerce BizTalk applications</description>
    <appUserAccount>BizTalk Application Users</appUserAccount>
    <appAdminAccount>BizTalk Server Administrators</appAdminAccount>
    <contactInfo>http://geekswithblogs.net/paulp</contactInfo>
    <field ordinal="0" label="App1.SiteId" masked="no">2</field>
    <field ordinal="1" label="App1.UserId" masked="no">8</field>
    <field ordinal="2" label="App2.Timeout" masked="no">5000</field>
    <flags configStoreApp="yes" allowLocalAccounts="yes" enableApp="yes" />
  </application>
</sso>

New usage scenarios:

1. Saving configuration:

1.1 Create application;
1.2 Save to XML;
1.3 Manage application - Retrieve settings;
1.4 Export to XML file created in (1.2).

2. Restoring previously saved configuration:

2.1 Create application;
2.2 Manage application - Import configuration from file created in (1.4) ;
2.3 Save Changes.

Accordingly, menu items Import/Export available when the Manage Application tab is selected only.

The code can be downloaded here.

COM error in custom pipeline component

Paul Petrov — Wed, 19 Dec 2007 00:58:06 GMT

If you receive error:

COM object that has been separated from its underlying RCW cannot be used.
The possible cause is invalid or malformed per instance configuration data.

You most likely ran into bug (or undocumented feature) of BizTalk SDK. The problem won't show up until you edit value of component custom properties during deployment configuration. The reason is described below.

When you create custom pipeline component with properties you will override ReadPropertyBag(Microsoft.BizTalk.Component.Interop.IPropertyBag pb, string propName) method of base component class (for example FFDasmComp). In your implementation you must call base.Load(IPropertyBag propertyBag, in errLog) method. The problem stems from implementation this method. It uses DisposableObjectWrapper declared in using{} scope to keep reference of IPropertyBag object. DisposableObjectWrapper is a simple wrapper to handle objects that have to be disposed. In it's own Dispose() method it will call Dispose() of it's member or if the member is a COM object it will call Marshal.ReleaseComObject(object obj). Look what happens if you implemented your ReadPropertyBag method like this:

private object ReadPropertyBag(IPropertyBag pb, string propName)
{  
  base.Load(pb, 0); //<- when this method returns reference to COM object will be lost
  object val = null;
  try
  {
    pb.Read(propName, out val, 0);//<- this line will throw COM Interop exception
  }
  catch (System.ArgumentException)
  {
    return val;
  }
}

To work around this issue just call base.Load() after all your calls to IPropertyBag. This will work fine:

pb.Read(propName, out val, 0);
base.Load(pb, 0)

Generic custom configuration elements collection based on ConfigurationElementCollection

Paul Petrov — Tue, 13 Nov 2007 19:32:37 GMT

Simple trick that saves me some time and coding when writing custom configuration objects is to define generic collection for them. Let's say I created several custom configuration elements derived from my CustomConfigElementBase which in turn inherits from System.Configuration.ConfigurationElement. Instead of defining strongly typed collections for each type I can simply define class:

public class GenericConfigElementCollection<T> : ConfigurationElementCollection

where T : CustomConfigElementBase, new()

{

public T this[int index]

{

get

{

return base.BaseGet(index) as T;

}

set

{

if (base.BaseGet(index) != null)

base.BaseRemoveAt(index);

base.BaseAdd(index, value);

}

protected override ConfigurationElement CreateNewElement()

{

return new T();

}

protected override object GetElementKey(ConfigurationElement element)

{

return ((T)element).ElementKey;

}

Note, that base custom configuration element has property ElementKey to satisfy GetElementKey method implementation. If your custom elements have different keys, you can override this property. It's possible to skip CustomConfigElementBase and define generic collection with ConfigurationElement type restriction. GetElementKey implementation would use reflection to retreive key property:

public class GenericConfigElementCollection<T> : ConfigurationElementCollection

where T : ConfigurationElement, new()

{

protected override object GetElementKey(ConfigurationElement element)

{

//- find and return property which is a key for a given type T using reflection

...

}

Now, when we define configuration section we just return generic collection of appropriate type:

public class MyCustomConfigSection : ConfigurationSection

{

[ConfigurationProperty("myCustomSettings", IsRequired = true)]

public GenericConfigElementCollection<MyCustomConfigElement> MyCustomSettings

{

get

{

return this["myCustomSettings"]

as GenericConfigElementCollection<MyCustomConfigElement>;

}

And then just use it in an application code:

GenericConfigElementCollection<MyCustomConfigElement> configCollection = configSection.MyCustomSettings;

MyCustomConfigSection configSection = (MyCustomConfigSection)ConfigurationManager.GetSection("mySection");

MS BizTalk Server 2006 certification passed

Paul Petrov — Wed, 19 Jul 2006 22:46:00 GMT

I passed new Microsoft Certified Technology Specialist (MCTS) exam 70-235: Developing Business Process and Integration Solutions using Microsoft® BizTalk® Server 2006. Fresh experience with BizTalk 2006 helped a lot as well as reading documentation, blogs. Interestingly, this exam stands aside of new Microsoft Certified Professional Developer (MCPD) path. It would make sense to include it as an elective option earning credit towards MCPD: Enterprise Application Developer. This exam with the combination of:

Exam 70–549: PRO: Designing and Developing Enterprise Applications by Using the Microsoft .NET Framework

Exam 70–536: TS: Microsoft .NET Framework 2.0 - Application Development Foundation

Exam 70–528: TS: Microsoft .NET Framework 2.0 - Web-Based Client Development

Exam 70–529: TS: Microsoft .NET Framework 2.0 - Distributed Application Development

would give well rounded Enterprise Application Developer skill set with emphasis on integration and business automation given that you've got to know all that stuff anyways to use BizTalk efficiently. I don't know what Microsoft planned this certification for but without skills listed above one can't develop a solid “Business Process and Integration Solutions”. So it does look like an orphan certification right now.

Precompiling BizTalk Web Service Endpoint

Paul Petrov — Wed, 19 Apr 2006 18:34:00 GMT

In a recent MSDN webcast given by Richard Seroter somebody asked about how to avoid “first hit latency” caused by JIT compiling web service code which is deployed not compiled by default. In my post about web project deployment I wrote about precompiling BizTalk web services using aspnet_compiler that will cure this problem. I just wanted to highlight some details.

First, the project can not be compiled in-place, otherwise files get overwritten. It's better to create separate folder for precompiled web artifacts and pass it as -targetDir to aspnet_compiler.exe.

Second, since you most likely use some script to add assemblies to the BizTalk application its good to use -fixednames option to get consistent file names and directory structure across builds.

Third, if you still want to have some source files updateable (let's say documentation aspx pages), you' can provide -u switch to the compiler.

And the last, it's always good to sign your assemblies with strong key so there are -keyfile, -delaysign, -aptca compiler switches to do that.

Setting relative path of the key file in Visual Studio 2005 project

Paul Petrov — Mon, 06 Feb 2006 23:08:00 GMT

If you like to keep solutions organized, keep common things together, store keys separately, and use automated builds you’d probably get frustrated by the new Signing tab of the Project Settings UI. Don’t get lured by the fancy look-n-feel of this dialog – it won’t let you set relative path of the strong key file. If you browse to the existing file, IDE will try to copy it into the project folder. Type things like “..\key.snk” and it just barks at you that such symbols are not allowed in the file name. It's odd, as this is very important when you manage and store keys separately and use them to sign multiple projects. This is vital in BizTalk development, when all bindings and mappings depend on strong names of artifacts and accidental change of signature can cause solution to break.

The hack is simple: open project file *.csproj or *.vbproj in notepad and find element <AssemblyOriginatorKeyFile>. Type in path of your choice something like: “..\..\Common\KeyFileName.snk..”, save and reload the project. You're set to run your favorite build script.