Amit's profileAll about BizTalk Server...PhotosBlogLists Tools Help

Blog


    October 18

    Daily Builds for BizTalk Projects

     

    Daily builds are considered to be one of the best practices while managing large projects. There are various tools in which we can write our custom Build scripts

    1.      NAnt script

    2.      Bat files

    Of the above two, NAnt scripts are considered to be

    ·         More generic,

    ·         User friendly,

    ·         Easier to maintain.

    ·         Dependencies are well maintained in these scripts

    ·         NAnt is Xml based

    In NAnt scripts the commands are executed as various tasks which are stored in configuration files (These configuration files are Xml based).

    So in all NAnt contains various tasks objects, which we can use in some configuration Xml files. (Instead of executing those shell or DOS commands)

    Here are some good links on NAnt:

     http://nant.sourceforge.net/release/latest/help/

    Through initially it will take some time to get custom to various tasks and various syntax of NAnt, but after that the hard work definitely pays. J

    NAnt also contains various tasks depending on the Source Control you are using (VSS/ CC etc) like Check In /out, label etc

    Use NAntContrib        http://nantcontrib.sourceforge.net/release/latest/help/tasks/index.html

     Build Files

     Strongly consider dividing your build files in two groups:

    1. Master Build File
    2. Slave Build File

                                                     Master Build File

                                                              |

                 ___________________________________________________   

              |                                               |                                     |

    Slave Build File1                         Slave Build File2                   Slave Build File3

       (Solution1)                                (Solution2)                          (Solution3)

     Master Build File

     It’s the core NAnt build file which will then internally call the slave build files (one for each solution) depending on the target specified. (Build.All / Build.BizTalk / Build.WebApplication etc)    

     Functions performed by Master Build File:

     Sets the task to be executed on build failure and success

      1. nant.onfailure

                                                                  i.      if build fails executes this target like mail, do not label etc

      1. nant.onsuccess

                                                                  i.      if build succeeds execute this target like mail, label, increment build number, create label  etc

    1. Specify Mail Properties, if you want to mail the build log after the build
    2. Create properties to determine the log file names. This will contain the log of your build process
    3. Calls the slave Build file to build each solution
    4. If the build succeeds, mark a label with the current version number.

     Slave Build Files

     Some slave build files will be ( may vary according to your needs)

    • One Slave build file per solution
    • A build file containing common properties
    • A build file containing  file actions like zipping source code etc, after build succeeded
    • You can also have custom C# scripts functions, NAnt will execute these functions like (Generating New GUID, read/write file containing version number
    • Two files for maintaining version information

    1.      Slave Build File per solution

                       a.      This Build file will be called by the Master build File which will then build the whole solution or if your solution contains dependencies some times you have to build projects

                       b.      Steps in a typical slave build file

                                                                 i.      Clean : Cleans the Projects/bin/{Release|Debug} directory

                                                                ii.      GetLatest : Gets the latest source code from the Source Control

                                                               iii.      Set version : Increase the version number

                                                              iv.      Build : Build the solution

                                            1.      either use vbc or csc NAnt task

                                            2.      For BizTalk projects use devenv.exe

                                                                v.      build.msi : Build the MSI (use Wix/Set up project etc)

                                                               vi.      copy.buildoutput : Copy the dll to a location

                                                               vii.      cleanup : clean any Temp directory

    2.      Common Properties file

                       a.      This file can contain information like

                                                                  i.      Path to

                                           1.      location where various zipped code will be stored

                                           2.      Path of devenv.exe

                                                                ii.      Various other properties which are common to all the build files like

                                           1.      Name of the Project

                                           2.      Branch Name

                                           3.      Release

                                                              iii.      Name and Path of both the version files

    3.      File Actions build file can do the following things

                       a.      Zip all build output i.e. All dll to a archive folder

                       b.      Zip full source code

                       c.      Zip all MSI

                      Zip all these and store them in an Archive folder

    4.      Custom C# script functions for ex.

                      a.      To create new GUID

                      b.      Read write the version files

    5.      Two version files

                      a.      First File to maintain [AssemblyVersion/AssemblyFileVersion]

                          Format

                  [MajorVersion].[MinorVersion].[MM][DD].DailyBuildNumber      

                    Ex   1        .     0        . 10  17 .18 

                 

                      b.      Second file to maintain directory version

                 Format

                   [MajorVersion].[MinorVersion].[YY][MM][DD].DailyBuildNumber      

                     Ex   1      .     0        . 06  10  17 .18 

     Assembly versioning for BizTalk Artifacts

     Unlike simple .Net projects where assembly version information is stored in AssemblyInfo.cs in BizTalk projects Assembly version is stored in *.btproj files. So to change the version number you have to change it in  *.btproj file.

    BizTalk projects may contain AssemblyInfo.cs file but if you set the assembly version in AssemblyInfo.cs file, then the Assemblies which are generated are not of the version which you have specified in AssemblyInfo.cs file but

    ·         The assemblies will be of the version specified in *.btproj file

    ·         If *.btproj and AssemblyInfo.cs contains contradictory version information, after build “AssemblyInfo.cs” file will be updated with the version information from *.btprj file

    So in all if you want to change Assembly information of BizTalk artifacts change it from *.btproj files.

     Not a good idea to change assembly version of BizTalk assemblies with daily builds

     In BizTalk, projects are highly dependent on Assembly versioning. Also because of the following reasons the Assembly version of BizTalk Artifacts should not be changed with daily builds:

    1.      If you are changing the version number of assemblies, you have to change the port binding files regularly

    2.      Also projects are highly dependent on the version number of assemblies, so you have to change it in *.btproj files

    3.      Also one can easily identify various dlls by there AssemblyFileversion unless we are deploying side by side.

    Changing AssemblyFileversion will not break BizTalk dependencies.

     So what to do.

    Change the AssemblyFileVersion in *.btproj (From Stephen W. Thomas and Scott Colestock)

     How to do it

    1.      Change it in *.btproj file using XmlPoke NAnt task

    http://nant.sourceforge.net/release/latest/help/tasks/xmlpoke.html

    2.      Do a find and replace using Copy NAnt task

    http://nant.sourceforge.net/release/latest/help/tasks/copy.html

    October 16

    BTS Pipeline Component Wizard

    To create custom Pipeline Components one has to get into details of various interfaces which he has to implement while creating it. This can get very tedious some times.

    There is a very handy tool for developing Pipeline Components. It hides the complexity from the developer by a simple wizard.

     

    You can get the installer at

    http://www.gotdotnet.com/Workspaces/Workspace.aspx?id=1d4f7d6b-7d27-4f05-a8ee-48cfcd5abf4a

     

    Download it and install.

    This will add a new option in the New BizTalk Projects option "BizTalk Server Pipeline Component Project"

     

    The wizard collects information like

    • ClassName
    • Namespace
    • Type of Component  Send/Receive
    • Place in the Pipeline Encoder/AssemblingSerialezer/Decoder/Validate etc depending on the type of the component(Send/Receive)
    • Component Name
    • Version
    • Description
    • Public property exposed by the component

    After this wizard, a class file is created with a skeleton code ready with all the necessary implementation of needed interfaces.

     

    Also read this article if your project has Custom Pipeline Components.

    http://geekswithblogs.net/sthomas/archive/2006/09/27/92513.aspx

    October 12

    Viewing Assemblies with the BizTalk Assembly Viewer

     

    This nifty little tool is a Windows Shell extension for examining deployed BizTalk assemblies and assembly types and lets you see references and view the XML code for various types including schemas, maps, orchestrations and pipelines.

     

    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/BTS06CoreDocs/html/9831eb88-84bc-4d18-8174-43c3baab83fe.asp

    Documentor for BizTalk

    In every project we need the documentation of the Deployed BizTalk artifacts. I tried two of available BizTalk Documentors:

    1.      BizTalk Documentor from Eric

    http://blogs.msdn.com/ebattalio/archive/2006/03/26/561422.aspx

    2.      UK SDC BizTalk 2006 Documenter

    http://www.gotdotnet.com//codegallery/releases/checkForDownload.aspx?id=0690616f-838c-4583-a4c5-cecc5ac04dac&releaseid=67c9ba64-277a-49e1-897e-2297afad8915

     

    I am presently using the later one.

    October 11

    BDF BizTalk Deployment Framework

     

     

    I am presently experimenting on BDF, a great thing to have for deployment of BizTalk artifacts both for BTS 2004 and 2006.

     

    But Must to have for deployments of BTS 2004 artifacts.

     

    BTS 2006 comes with a great MSI feature, still we can use BDF from Scott Colestock. See this

    http://blogs.msdn.com/biztalk_server_team_blog/archive/2006/07/11/661812.aspx

     

    Advantages:

    1. Uses NAnt script (XMLJ getting popular day by day)
    2. One has to maintain only one binding file for different environment.
    3. Ease of deployment while moving BizTalk artifacts from one environment to another to another, and so on, because for each environment you have to maintain just one excel sheet with one column each for one environment.
    4. Uses WiX for making MSI
    5. We can add those custom Post/ Pre Deployment/Un Deployment scripts easily in NAnt.
    6. If we haven't changed any of the ports in our orchestration, we can simply replace the orchestration assembly in the GAC and bounce the service.
    7. Provides various other features like:
      1. Scripts to start/stop various hosts
      2. Create various Virtual dirs
      3. Creating App pools
      4. App pools settings
      5. IIS Reset
      6. Deploying BizTalk rule engine vocabularies and rules
      7. We can specify send port groups, send ports, and receive locations that should NOT be started when ports are started
      8. We can also specify Orchestrations that should not be started or stopped
      9. We can also specify the dependencies for deploying and undeploying, which in turn decides the over all order of deployment.
      10.   Import Port Bindings File etc

    To see details see the following links, Scott has some good documentation for BDF.

     

    http://www.traceofthought.net/PermaLink,guid,687edf39-57aa-4776-9aea-8c0f769320c1.aspx

     

    http://nodtonothing.blogspot.com/2005/11/i-geek-therefore-i-am-biztalk.html

     

    BDF can be divided into two parts:

    1. Creation of MSI
    2. Deployment

     

     

     

    Creation of MSI

    For this BDF comes with WiX, Candle, light and some other handy tools, which helps creation of MSI files.

    BDF provides “GenericBizTalkMSI.wxs”, generic wxs file for creation of MSI.

    This .wxs file is used by two NAnt files

    ·         [ProjectName].WiXSetup.build

    ·         [ProjectName].WiXSetup.nant [Core MSI Script file]

    We can also modify these custom NAnt scripts.

    The process of creating a MSI is:

    1. The scripts first create a redist folder, which actually contains all the artifacts which will be dumped to deployment server.
    2. The script then calls candle. Candle is responsible for preprocessing the input .wxs files into valid well-formed XML documents against the WiX schema, wix.xsd. Then, each post-processed source file is compiled into a .wixobj file.
    3. Then light is responsible for processing one or more .wixobj files, retrieving metadata from various external files and creating a Windows Installer database (MSI or MSM).      

     

    http://wix.sourceforge.net/manual-wix2/wix_index.htm

     

    Deployment

     

    The process of deployment can be divided in two parts:

    • Deployment on Developer Machine
    • Deployment on Server Machine

     

    Developer Machine

     

    BDF comes with a script which adds the following options in VS environment.

    ·         Deploy BizTalk Solution

    ·         UnDeploy BizTalk Solution

    ·         Update Orchestrations

    ·         Bounce BizTalk

    ·         Gac It

    ·         HAT

     

    So over all above processes reduces a number of steps which a developer has to do manually. Over all the efficiency of a developer is increased.

     

    Server Machine

     

        The deployment of the MSI to the production server is a two phase deployment. In the first phase, all the BizTalk artifacts are copied on to the server, but not deployed. In the second phase the user can deploy using the option in the start->Programs Files-> Project Name-> Deploy Project, which actually deploys the solution to BizTalk.

     

    Deployments on a server can often require additional information beyond what is provided in the NAnt script.  This information can be divided into three broad categories:

    1)     Information that has to be gathered from the person doing the installation (i.e. account names, passwords, etc.)  We call this “Install-time configuration.” This is gathered through “InstallWizard.xml

    2)     Information that is specific to the environment you are installing in (i.e. development, QA, integration/staging, or production.)  We call this “Environment-relative configuration.” Information Stored in “EnvironmentSettings.xls” and then exported to xml files, one for each environment. User can select one of which while deploying the solution.

    3)     The port setting which we can gather through the Binding files. For this we need a Port Binding File

     

    All these features are available in BDF.

     

    Any way all these above feature makes it a very good framework to use. So go ahead and just try it.

     

    Because of hands on NAnt script (used in BDF), presently working on build scripts L. But Struggling with CC tasks in NAnt. Any help will be appreciated

     

    Matheran Trip

    Still wondering in the greenery of Matheran, quite a good trip after a long time J. Every one needed a break, got at last. (After lots of planning and pleasing everyone). Enjoyed a lot.

    Even the day before our trip to Matheran, we went to some party, did some bowling, Chinese food (not enjoyed L) etc. so was late to bed, still was confident of waking up early in the morning.

    The day started early 4 in the morning, then we met at Dadar (still missed the first trainL).

    We hired a taxi from Neral to Matheran. The journey from Neral to Matheran was a good one took only about 30 or so minutes, but was really exciting, those u turns.

     

    Then we went to the first point “Panorama Point”, was a good one, took some snaps there. We also had a screaming competition, guess who won J.

    Some one from us was missing N??????.

    After getting down we had some snacks off course with Monkeys.

    After a good refreshment we headed to our second destination “Garbet Point “.

    In our way we met some school going children, we did spent some time with them, took some snaps. One of us even raced against them. He won but he has to give his 150% to overcome those 10-15 year childrenJ.

    We also had a stone throwing competition. Guess who wonJ.

    One of us went in her childhood with those children. She really enjoyed with them. She really needed a good break after those long hours working for Projects.

    One of us A???  was really excited, using flowers to impress somebody. Guess? J 

    At last we reached Garbet point, no words for that, simply superb, Nature at its best.

    We spent some time there, took some snaps. But our photographers really lacked experience.

    Then we decided to have a heavy lunch, as every one was getting really hungry (after about 15 km of walk). But to have our lunch we have to walk again about 10 km to Matheran station. We walked along the toy train’s rail. Some one from us ( A??? not  me) was supposed to take us to some very good hotel, at last he realized that there does not exists any hotel of that kind there. Really must have dreamt about that a day before.

    We all had a good lunch, except our beloved S?????. She was in real trouble after that play with children. She took some medicines, did not took any food. Because of our Madam, we all decided to drop our future plans to see other points and decided to take some rest there at the garden.

    But the real moment of our whole trip was just about to come. “THE MONKEY BUSINESS”. Just joking J.

    After our rest at garden, both the females then took a horse each up to Matheran taxi stand. 

    Then started the boring moments, “discussion on marriage” really bored me. Bored me so much that at last I told them to stop that discussion, But all in vain. L  

    Over all a good trip.

    Some missed some good opportunities to express there heart out. J

    Planning for our next trip with V???? and A???, others are also invitedJ.