Enumerating BizTalk 2016 Features for a Command-Line Installation

As with previous versions of BizTalk Server, you can perform the installation using the GUI or a command-line. To use the command-line installation, you’ll need the list of features that can be installed to add to the /AddLocal command-line. The available documentation for a silent installation of BizTalk Server at https://msdn.microsoft.com/en-us/library/jj248690.aspx relate to BizTalk Server 2013 and 2013 R2 (see https://msdn.microsoft.com/en-us/library/mt743078.aspx for ‘BizTalk Server 2016: What’s new, and installation’, then follow the link Appendix A: Silent installation near the bottom of the navigation menu at the left to get to the above page); there’s nothing that I’ve found so far that provides the setup.exe command line switches, or a list of features for use in a silent installation specifically for BizTalk Server 2016. Note that blindly following the previous guidance and using certain specific /AddLocal features results in an installation failure!

Getting hold of the command-line parameters for setup.exe is, of course, simple. Just run setup.exe with the ‘/?’ switch from a command prompt to get the following:

Command Description
/help or /? or /h Help and quick reference option.
/s <Configuration XML file> Silent Installation of features found in Configuration file.
/passive Passive Installation. Only progress bar will be displayed.
/norestart Supress restart.
/forcerestart Always restart after installation.
/promptrestart Prompts before restarting. This option cannot be used with the /quiet option.
/x or /uninstall Uninstalls the product.
/L <Logfile> Writes logging information into a logfile at the specified path. Always uses verbose MSI logging and appends to existing file.
/IGNOREDEPENDENCIES Bypass checks for downloadable prerequisites.
/INSTALLDIR <Install path> Specify the full path to product install location.
/COMPANYNAME <companyname> Sets the company name.
/USERNAME <User name> Sets the user name.
/ADDLOCAL ALL Install all features.
/REMOVE ALL Remove all features.
/REPAIR ALL Repair installation.
/CABPATH <cabfile> Specify a local path to a redistributable CAB file.
/CEIP Opt in to BizTalk Server Customer Experience Improvement Program.

These commands correspond to those listed on the silent installation page for BizTalk 2013 mentioned above with the exception that the final two commands listed on the web page appear to be missing from the above list generated by BizTalk Server 2016.

The /AddLocal command-line parameter details the features that will be installed. On the silent installation web page, there is a link to follow to the list of features (at http://go.microsoft.com/fwlink/p/?LinkID=189319), however if you browse to that page, you’ll notice that it is marked as the features for BizTalk Server 2010. There are issues using some of the parameters for the installation of BizTalk Server 2016, so it seemed worthwhile attempting to enumerate the parameters that are available to a BizTalk Server 2016 installation.

The installation MSI for BizTalk Server 2016 can be opened using Orca (Orca.exe is a database table editor for creating and editing Windows Installer packages and merge modules – see https://msdn.microsoft.com/en-us/library/windows/desktop/aa370557(v=vs.85).aspx for acquisition and installation instructions) to get the list of features. The screen shot below shows a partial view of the ‘Feature’ table from the ‘Microsoft BizTalk Server64.msi’ file:

Orca Features Table for BizTalk Server 2016 MSI

The information in the ‘Feature’ table, along with information gleaned by running the installer, ticking specific single components and then examining the setup log file can be reorganised to give the following:

Feature AddLocal Command
Portal Components BizTalk, WMI, InfoWorkerApps
      Business Activity Monitoring BAMPortal
Developer Tools and SDK BizTalk, WMI, AdapterImportWizard, BizTalkExplorer, BizTalkExtensions, DeploymentWizard, Designer, Development, Migration, MsEDIMigration, MsEDISchemaExtension, MsEDISDK, OrchestrationDesigner, PipelineDesigner, SDK, TrackingProfileEditor, VSTools, WCFDevTools, XMLTools
Documentation Documentation
Server Runtime BizTalk, WMI, Engine, MOT, MSMQ, Runtime
      BizTalk EDI/AS2 Runtime MsEDIAS2, MsEDIAS2StatusReporting
      Windows Communication Foundation Adapter WCFAdapter
Administration Tools and Monitoring BizTalk, WMI, AdminAndMonitoring, AdminTools, BAMTools, BizTalkAdminSnapIn, HealthActivityClient, MonitoringAndTracking, PAM
      Windows Communication Foundation Administration Tools WcfAdapterAdminTools
Additional Software BizTalk, WMI, AdditionalApps
      Enterprise Single Sign-On Administration Module SSOAdmin
      Enterprise Single Sign-On Master Secret Server SSOServer
      Business Rules Components RulesEngine
      MQSeries Agent MQSeriesAgent
      BAM Alert Provider OLAPNS
      BAM CLient FBAMCLIENT
      BAM-Eventing BAMEVENTAPI
      Project Build Component ProjectBuildComponent

Notes:

  • The ‘BizTalk’ and ‘WMI’ feature are specified in numerous places in the table above. You only need to specify each of these items once.
  • The parameters are case sensitive. Specifying a parameter incorrectly, e.g. OlapNs rather than OLAPNS will result in a silent installation failure.
  • When adding the parameters to the command line, it is important that there is no space between the items. Including a space (e.g. ‘BizTalk, WMI, AdditionalApps’ rather than ‘BizTalk,WMI,AdditionalApps’) will result in a silent installation failure.
  • One of the features, ‘SDKScenarios’, is never mentioned in the setup log file. It is assumed that this feature is automatically installed if required by the parent feature (SDK), however including it within the AddLocal command line parameter list doesn’t seem to cause any issues.

Custom Pipeline Components Not Updating

I’m sure many BizTalk developers who create custom pipeline components will have run into this problem. You create a custom pipeline component, deploy it, and something doesn’t quite work. Back into Visual Studio and make some code fixes, looks good and redeploy. Test your fix only to find your changes don’t appear to have come across. Ok, rebuild everything and try again. Still no joy? You then start ripping out your solution, removing assemblies from the GAC, restarting Visual Studio etc. until it eventually seems to deploy, but you have no idea which step it was that solved the issue.  

The answer to the problem is Visual Studio is trying to be to helpful. When you add your custom pipeline components into the toolbox on the pipeline editor Visual Studio caches that version. Therefore simply restarting Visual Studio will not work no matter how many times you remove the old assemblies from the GAC. You need to remove the custom pipeline component from the toolbar. Restart Visual Studio and add the component back into the toolbar. Alas the component has been updated.

BizTalk – Generating schemas from classes with TargetNamespace

BizTalk provides a us a way of generating schemas from c# classes by using the xsd.exe tool which comes with the BizTalk SDK. The tool also allows us to generate c# classes from a schema and as an option we can specify the runtime namespace for the generated types. What would be nice is if we could specify the target namespace for the schemas when we generate them from our classes. As a BizTalk developer this can cause major headaches as you need to remember to add this manually every time you need to regenerate your schemas. After much investigate it turns out there is a way to get the target namespace into our schemas.

So for example we have our C#’ class which may look something like this:

using System.Xml.Serialization;   namespace ServiceBusDemo.Model {
     public class TodoItem
     {
         public int ID { get; set; }
         public string Title { get; set; }
         public string Description { get; set; }
         public bool IsDone { get; set; }
     } }

We run it though the xsd.exe tool and it generates us a schemas which looks like this:

  <?xml version=”1.0″ encoding=”utf-16″ ?>
<xs:schema xmlns:b=”http://schemas.microsoft.com/BizTalk/2003 elementFormDefault=”qualified xmlns:xs=”http://www.w3.org/2001/XMLSchema>
  <xs:element name=”TodoItem nillable=”true type=”TodoItem />
<xs:complexType name=”TodoItem>
<xs:sequence>
  <xs:element minOccurs=”1 maxOccurs=”1 name=”ID type=”xs:int />
  <xs:element minOccurs=”0 maxOccurs=”1 name=”Title type=”xs:string />
  <xs:element minOccurs=”0 maxOccurs=”1 name=”Description type=”xs:string />
  <xs:element minOccurs=”1 maxOccurs=”1 name=”IsDone type=”xs:boolean />
  </xs:sequence>
  </xs:complexType>
  </xs:schema>

So normally at this point I would go in and manually add the targetnamespace, I probably misspell it, deploy my BizTalk solution and spend half a day wondering why my message are not being routed correctly.

The solution to this is to simply add a reference to the System.Xml.Serialization namespace (Notice how on the msdn help page for the xsd.exe tool it states that the tool uses the System.Xml.Serialization.XmlSerializer) and add the XmlType and XmlRoot (for root elements) Attributes

to your c# classes.

using System.Xml.Serialization;   namespace ServiceBusDemo.Model {
     [XmlType(TypeName = "TodoItem", Namespace = "http://schemas.datacontract.org/2004/07/ServiceBusDemo.Model.TodoItem")]
     [
XmlRoot(ElementName = "TodoItem", Namespace = "http://schemas.datacontract.org/2004/07/ServiceBusDemo.Model.TodoItem")]
     public class TodoItem
     {
         public int ID { get; set; }
         public string Title { get; set; }
         public string Description { get; set; }
         public bool IsDone { get; set; }
     } }

Once we have defined the namespace we want to use, rerun the xsd.exe tool and this time all the work is done for us Smile

<?xml version=”1.0″ encoding=”utf-16″ ?>
<xs:schema xmlns:b=”http://schemas.microsoft.com/BizTalk/2003 xmlns:tns=”http://schemas.datacontract.org/2004/07/ServiceBusDemo.Model.TodoItem elementFormDefault=”qualified targetNamespace=”http://schemas.datacontract.org/2004/07/ServiceBusDemo.Model.TodoItem xmlns:xs=”http://www.w3.org/2001/XMLSchema>
  <xs:element name=”TodoItem nillable=”true type=”tns:TodoItem />
<xs:complexType name=”TodoItem>
<xs:sequence>
  <xs:element minOccurs=”1 maxOccurs=”1 name=”ID type=”xs:int />
  <xs:element minOccurs=”0 maxOccurs=”1 name=”Title type=”xs:string />
  <xs:element minOccurs=”0 maxOccurs=”1 name=”Description type=”xs:string />
  <xs:element minOccurs=”1 maxOccurs=”1 name=”IsDone type=”xs:boolean />
  </xs:sequence>
  </xs:complexType>
  </xs:schema>
 
 

BlackMarble SOA/BizTalk Event

Thanks to everyone who sat and listened to my presentations on BizTalk RFID, ESB and ISB. I hope that you found them useful.

As promised here are the links:

Biztalk RFID : http://www.microsoft.com/biztalk/en/us/rfid.aspx

Blue C Sushi : http://www.microsoft.com/casestudies/casestudy.aspx?casestudyid=201405

ESB Guidance : http://msdn.microsoft.com/en-us/library/cc487894.aspx

Robert’s Blog on installing ESB: ESB Guidance Setup Walk through (DRAFT)

Biztalk Services/ISB: http://biztalk.net/

Oslo in a nutshell

What is Oslo all about? According to Microsoft’s Burley Kawasaki at Architect Insight, Oslo is a new way to build connected applications where services are extended from client to cloud and models become the mainstream part of development. Oslo is not a product but a way of working. http://www.microsoft.com/soa/products/oslo.aspx.

Other things of interest from Architect Insight include the ConfigWeb sample (from Stock Trader) for configuring enterprise web applications (http://msdn.microsoft.com/en-us/netframework/bb499684.aspx). The Internet Service bus and biztalk services (http://biztalk.net/Default.aspx).