| Amit's profileAll about BizTalk Server...PhotosBlogLists | Help |
|
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:
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
i. if build fails executes this target like mail, do not label etc
i. if build succeeds execute this target like mail, label, increment build number, create label etc
Slave Build Files Some slave build files will be ( may vary according to your needs)
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 WizardTo 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
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.
Documentor for BizTalkIn 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
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:
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:
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:
http://wix.sourceforge.net/manual-wix2/wix_index.htm
Deployment
The process of deployment can be divided in two parts:
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 TripStill 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.
|
|
|