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.
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.
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:
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:
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.
