There are some updates to the Deployment Framework and log4net story that I’ve been
meaning to release for quite some time. After this, I’ll focus my deployment efforts
on BizTalk 2006 (didn’t I say that last release?)

Below are a list of revisions. On this blog’s home page under “Downloads”,
you will find an updated full download (with sample), as well as updated
“Core” and “Tools” downloads.  “Core” contains only the deployment framework
itself and can be used for upgrades of existing projects.  “Tools” contains source
for all utilities used by the framework.  Be sure to put a fresh copy
of BizTalk.NAnt.Tasks.dll in your nant\bin directory.
 

  • Update to the log4net.Ext.Serializable library.  Note that the “Tools” download
    now has variants of this library for both log4net 1.2.0 and 1.2.9, though the sample
    is built against 1.2.9.  The important change here is that the original version
    of the library had a threading bug…as a result, the usage pattern for the library
    has changed somewhat.  Now, an instance of log4net.helpers.PropertiesCollectionEx
    is declared (as an orchestration variable), and an expression shape at the top of
    your orchestration will do something like below (notice logProps is passed to all logging
    calls so as to preserve context despite thread changes across dehydrations.) 
    See the sample for additional detail.

    logger = log4net.Ext.Serializable.SLogManager.
       GetLogger(@"BizTalkSample",log4net.helpers.CallersTypeName.Name);
    ...
    logProps.Set("InstanceId",TopLevelOrch(Microsoft.XLANGs.BaseTypes.InstanceId));
    logger.Debug(logProps,"Received top level request...");               
                   
  • Update to the SSOSettingsFileReader class to include an “Update” method. 
    Likewise, an additional custom NAnt task called “updatessoconfigitem” that allows
    you to add or update config items within an SSO affiliate application.  What
    is the use case for this?  Suppose you have a piece of information that you a)
    don’t want to store in SettingsFileGenerator.xls (perhaps because you can’t manage that
    file securely) and b) you need access to at run time.  (For instance, it
    might be an Oracle username/password.)  You could ask an operator/admin for this
    information at deployment time using SetEnvUI.exe/InstallWizard.xml (from the
    deployment framework) — and then in your project-specific NAnt file do this:

       <target name="customSSO" if="${property::exists('serverDeploy') and serverDeploy}">
          <updatessoconfigitem ssoitemname="databaseUserName" ssoitemvalue="${sys.env.databaseUserName}"/>
          <updatessoconfigitem ssoitemname="databasePassword" ssoitemvalue="${sys.env.databasePassword}"/>
       </target>            
          

    At runtime, you can simply use SSOSettingsFileReader to retrieve this information. 
    Note that this example checks for whether we are doing a server deployment – so in
    this case, we would have the development environment values in SettingsFileGenerator.xls. 

  • Added a small utility called SSONameValueDump to the tools download to view current
    name/value pairs of an SSO affiliate application (if you have appropriate permissions.)

  • Update to the <controlbiztalkports> custom NAnt task to allow Send Port Groups
    to be shared across projects.  That is, Send Port Groups will only be removed
    if they no longer contain Send Ports (and putting new Send Ports into an
    already-existing Send Port Group will happen automatically.)

  • XmlPreprocess will be run against log4net configuration files, if you are using log4net.
    This allows you to use SettingsFileGenerator.xls to control logging levels for different
    physical environments.

  • SetEnvUI.exe no longer defaults to “last directory” when doing a file browse, to avoid
    confusion between applications when managing multiple BizTalk application installs.

  • If you use ElementTunnel,
    you will find that the xpath file will be reversed automatically for unescape operations
    (thanks to Frank de Groot for that update!)

  • Fix: When deploying HTTP/SOAP infrastructure, file system permissions granted to the
    specified application pool account.

  • Fix: The “quick update” target (updateOrchestrations) now respects true/false properties
    for includeSchemas, includeTransforms, etc. (A menu option in Visual Studio is
    created for this target when you use the MakeBizTalkExternalTools script. The target
    updates orchestrations, components, schemas, and transforms (see Flanders’ post on
    this) Using this as part of your normal edit/run/debug cycle is a must for
    productivity…)

  • Fix: Handle multiple assemblies (of one artifact type) correctly in more cases, including
    where we are not deploying to the management database (i.e. gac deployment only.)

Download: Full
Sample, Framework
Core, Tools
Source