Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
Windows Server

BizTalk Server 2006 : Starting a New BizTalk Project - Structuring and Integrating with Visual Studio

4/16/2013 6:24:19 PM

There is no standard way to structure a Visual Studio solution that has BizTalk projects included. Essentially, a properly defined naming convention will be applicable whether the solution is a complete .NET solution or a mix of .NET classes and BizTalk artifacts. The key decision to make is whether the entire application will be created as a single VS .NET solution or whether it will be broken down into multiple solutions. Another approach is to decide whether or not to have the Visual Studio solution file controlled under source control at all. In this scenario, each developer has a local solution file that is not under source control. The individual developer then adds the Visual Studio projects to his local solution that are required to complete the application being created.

How the Visual Studio solutions are structured will have many ramifications on howdevelopers will use the solution, how it will be built, and how it can be packaged and deployed. Additional things to consider are whether each developer will have the BizTalk development tools installed on their workstation. If a group of developers never code BizTalk artifacts and only create standard .NET classes, then these developers will get errors each time they load a BizTalk development project. A configuration like this will not work for a singlesolution scenario where every project is included in the solution and is loaded upon startup. In single-solution scenarios, it is necessary to break the solution up into multiple solutions that can be worked on either by BizTalk developers or by .NET-only developers.

In cases where multiple developers are working on isolated pieces of a solution, a separateintegration environment should be created. The purpose of this environment is to allow a common area for each build of the application to be placed. Additionally, the deployment process is developed and tested using this environment in order to minimize deployment errors when the solution is moved from the development environment into testing and finally production.

Since the BizTalk development model is isolated as described in the preceding section, it is crucial that the integration environment provide a place where unit testing can occur in a controlled environment. The integration environment configuration should closely match what will be used in the QA environment. The actual hardware that is used is not as important as the software. In many situations, given that most projects have limited resources, the integration environment is often a small, single-CPU server or spare developer workstation. Following are some things that should be considered when designing this environment:

  • BizTalk Server port configuration: Often on a developer's local workstation, requiredBizTalk ports will be simple transports such as the file adapter to facilitate easy testing. Also, port filter criteria may be simplified as the entire list of document filters and transformations may not be required. The integration environment should try to give the developer as controlled and realistic a configuration as possible.

  • Strong name key storage: When building BizTalk components that will be deployed tothe management database, it is necessary to implement a strategy for how to manage the strong name keys. Since BizTalk assemblies that are deployed need to be stored in the Global Assembly Cache (GAC), and all assemblies in the GAC need a strong name, this means that all BizTalk assemblies will need to use a strong name key. How this is managed often depends on the type of solution. If the solution will be a "for sale" commercial product, it is critically important to ensure that access to the strong name key is limited to key team members to ensure that the integrity of the application is maintained. In this case, developers are often given a test key file that is used to facilitate their building, deploying, and testing activities. Once the code is promoted, the build master then replaces the test key with a production key file.

  • Restricting code deployed: Only build and deploy code to the integration environmentif it is included in the formal build that will be sent to QA. This also helps to keep the integration environment a "managed" environment and not an isolated sandbox like the developer's local workstation.

  • BizTalk 2006 MSI exports: Starting in BizTalk 2006, applications can be exported usingWindows Installer technology to a Microsoft Installer (MSI) package. This MSI can be customized to include all required BizTalk Server artifacts and referenced assemblies and configuration. The integration environment is the ideal environment for exporting the MSI package to be used for installation in the QA and production environments.

The following sections discuss each of these approaches in turn.

Single Visual Studio Solution

For small- to medium-sized applications (less than 12 VS .NET projects), it is quite feasible tocontain all the required Visual Studio projects inside one solution. This one solution is then stored within Visual SourceSafe and is used by all developers, as depicted in Figure 1.

Figure 1. Visual Studio solution layout

The one solution shared by all developers is often referred to as the Master solution, and the solution is bound to the application root in SourceSafe. If the example application were structured as a single-solution configuration, it would most likely be named "ABC.FulFillment.sln" and would be bound to the ABC.FulFillment folder in Visual Source- Safe. This configuration has a number of advantages and disadvantages. First some of the advantages:

  • It is simple and easy to manage.

  • The entire solution namespace hierarchy is easy to see. Each project will contain only one set of namespaces that will compile to an assembly with the namespace of each class in the assembly equal to the assembly's physical name.

  • It allows the entire solution to be built and deployed as a whole without complex build scripts.

  • It allows for references between projects to be project references and not hard references to a built assembly. This will allow code changes in one project to be automatically reflected in any referenced project and helps to ease version conflict issues.

  • Developers will automatically see any checked-in changes from other developer team members. The only action required is to get the latest code check-ins from SourceSafe.

And now some disadvantages:

  • It requires the solution file be checked out from SourceSafe if any new projects are added. Each time a project is added to the solution, every developer will be prompted to connect to SourceSafe and get the latest copy of the newly added project.

  • Frequent updates to the file cause it to be locked in SourceSafe. Care will need to be taken to ensure that the .sln file in SourceSafe is not checked out for extended periods of time.

  • It isn't feasible for teams who don't have BizTalk installed on every development workstation.

  • It usually requires that all referenced projects be built along with the main project that is being built. This becomes time consuming as the number of projects increases.

  • Solution loading time increases as the number of projects increase. This becomes an issue as the number of BizTalk projects and artifacts within those projects starts to increase.

Multiple Visual Studio Solutions

For larger, more complex projects, it may become necessary to split an application into multiple Visual Studio solutions. In this scenario, there are multiple VS .NET .sln files checked into SourceSafe. Each solution would be logically related to a feature of the application that you are implementing. Each .sln file is bound to a directory in SourceSafe and contains the projects that are required to build the solution. This means that all projects within the solution are part of the solution, and referenced assemblies are referenced in the VS .NET project files as references to assemblies, not references to VS .NET project files.

One of the issues with this approach of carving an application into multiple Visual Studio solutions is how to include common project assemblies within each of the multiple solutions. Consider if there were three VS .NET solutions for each of the three subsystems defined in the earlier example. How would each of these solutions reference the Common Utilities project or the shared BizTalk Schemas project? It is possible to include these common projects within each of the solutions. To have each solution add the project that is needed, you choose the Add Project from Source Control option within the VS .NET solution, as demonstrated in Figure 2.

Figure 2. Adding a Visual Studio project from source control

The issue with adding the common VS .NET projects to each of the solutions becomes a matter of controlling who is allowed to edit and modify the shared source control. If a team of developers is specifically assigned to make additions and modifications to shared library assemblies, it is more advisable to have these assemblies included as references to the built DLL, rather than the VS .NET project file. The team responsible for these assemblies will deploy the correct version to the integration server and publish the correct build number. Each project that references the DLL must be updated to include the new assembly version number, or the reference must not include the version information and a new assembly is simply overwritten.

In a multiple solution configuration, a separate build-and-deploy process is necessary. Since the application is divided into separate VS .NET solutions, there are two approaches to building the solution:

  • Build and deploy each solution separately.

  • Create a Master VS .NET solution that includes all VS .NET projects from each solution. Build and deploy this Master solution as a single unit.

Advantages of the multiple-solutions approach include the following:

  • Only projects that are required to build the solution are loaded when the solution is opened in VS .NET. This can help decrease the amount of time required to load the solution.

  • Each solution file is based on a logical application subsystem or feature. The .sln file is then maintained and modified by the group that owns that feature.

  • Configuration allows application to be built and deployed as pieces. This allows teams to build and test their feature independent of others.

  • It allows the application to incorporate new features without having to dramatically change its layout in Visual SourceSafe.

  • Contention for Visual Studio .sln files within Visual SourceSafe will be decreased. Each feature team can add/remove VS .NET projects to their solution without affecting developers from other teams.

The list of advantages is long, but there are also a few disadvantages to the multiplesolutions approach:

  • It increases build-and-deploy complexity.

  • It increases the chances of versioning issues arising from referencing common components.

  • Increased management is needed. A formal build-and-deploy process becomes essential.

Developer-Independent Solutions

In some cases, it is possible to not have the VS .NET solution files checked into SourceSafe. In these situations, each developer has a local .sln file that he uses to add/remove projects as he needs; the .sln file is not used to organize the application into its appropriate features. This configuration works well for teams where the .NET assemblies they support are common to several different applications, and the VS .NET project file can be compiled on its own or with minimal references. The build process will need to take this into account by either creating custom build scripts or creating a master .sln file that is used deploy the solution to the integration environment.

Advantages of developer-independent solutions are as follows:

  • It is ideal for small teams or projects with very few independencies.

  • It is simple.

  • It is flexible and gives developers control over development environment.

As always, there are tradeoffs, this time in the form of the following:

  • It causes increased build-and-deploy complexity.

  • There is a potential loss of control for development leads.

  • It still requires a separate build process or Master solution file.

Other -----------------
- Deploying the Client for Microsoft Exchange Server 2007 : Planning Considerations and Best Practices, Preparing the Deployment
- Deploying the Client for Microsoft Exchange Server 2007 : Outlook 2007 Auto Account Setup, Understanding Deployment Options
- Microsoft Systems Management Server 2003 : Creating Packages for Distribution (part 6) - Package Distribution Process Flow
- Microsoft Systems Management Server 2003 : Creating Packages for Distribution (part 5) - Creating a Package from a Definition File
- Microsoft Systems Management Server 2003 : Creating Packages for Distribution (part 4) - Creating a Package from Scratch - Creating Programs
- Microsoft Systems Management Server 2003 : Creating Packages for Distribution (part 3) - Creating a Package from Scratch - Defining Distribution Points
- Microsoft Systems Management Server 2003 : Creating Packages for Distribution (part 2) - Creating a Package from Scratch - Defining Access Accounts
- Microsoft Systems Management Server 2003 : Creating Packages for Distribution (part 1) - Creating a Package from Scratch
- Microsoft Systems Management Server 2003 : Running Software Metering Reports
- Microsoft Dynamics GP 2010 : Improving performance by adjusting AutoComplete settings, Cleaning up Accounts Receivable with Paid Transaction Removal
- First look: Apple Watch

- 10 Amazing Tools You Should Be Using with Dropbox

- 3 Tips for Maintaining Your Cell Phone Battery (part 1)

- 3 Tips for Maintaining Your Cell Phone Battery (part 2)
- How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 1)

- How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 2)

- How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 3)
Popular tags
Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Biztalk Exchange Server Microsoft LynC Server Microsoft Dynamic Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 Adobe Indesign Adobe Flash Professional Dreamweaver Adobe Illustrator Adobe After Effects Adobe Photoshop Adobe Fireworks Adobe Flash Catalyst Corel Painter X CorelDRAW X5 CorelDraw 10 QuarkXPress 8 windows Phone 7 windows Phone 8 BlackBerry Android Ipad Iphone iOS
Popular keywords
HOW TO Swimlane in Visio Visio sort key Pen and Touch Creating groups in Windows Server Raid in Windows Server Exchange 2010 maintenance Exchange server mail enabled groups Debugging Tools Collaborating
Top 10
- Microsoft Excel : How to Use the VLookUp Function
- Fix and Tweak Graphics and Video (part 3) : How to Fix : My Screen Is Sluggish - Adjust Hardware Acceleration
- Fix and Tweak Graphics and Video (part 2) : How to Fix : Text on My Screen Is Too Small
- Fix and Tweak Graphics and Video (part 1) : How to Fix : Adjust the Resolution
- Windows Phone 8 Apps : Camera (part 4) - Adjusting Video Settings, Using the Video Light
- Windows Phone 8 Apps : Camera (part 3) - Using the Front Camera, Activating Video Mode
- Windows Phone 8 Apps : Camera (part 2) - Controlling the Camera’s Flash, Changing the Camera’s Behavior with Lenses
- Windows Phone 8 Apps : Camera (part 1) - Adjusting Photo Settings
- MDT's Client Wizard : Package Properties
- MDT's Client Wizard : Driver Properties
Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
2015 Camaro