BizTalk server relies on a config file to store certain application information. This config file is located in \Program Files\Microsoft BizTalk Server 2004 and is named BTSNTSvc.Exe.Config. View your file here (DO NOT CHANGE THIS FILE WITHOUT BACKING UP!!!).
Let’s say that you have some .NET components that you want to consume from your BizTalk solution. Let’s also assume that these components are possibly shared with another solution, and make use of a config file for things such as connection strings, directory locations, etc., a fairly common situation. Now, keep in mind when you call a component, and that component makes use of a config file, it uses the config file of the calling application (at least for EXE’s). So, we have a couple of options. We can take what’s in the shared components config file and paste it into the BTSNTSvc.Exe.Config file. But, this means we now have 2 places to maintain the information. What if we then have a multi server configuration, we now have 2 config files to maintain in more than one location. Not good. Wouldn’t it be nice if we could somehow have the BizTalk config file “point” to the components config file? Then, we could maintain the other applications config file as we normally would. Well, the good news is you can.!!!
Take a look at my sample config file to follow along. I’ll explain a couple of the sections. It is important to remember to always take a copy of you current BTSNTSvc.Exe.Config file before making any changes as changing it incorrectly will prevent BizTalk from running.
The key to making this work is the section. To make this section “available”, you will have to add the following under the section of your config file –
Now that we have this in the config file, we can add the section . I won’t copy it here to save space, so look at the example. This section is where all the magic happens. Some of the attributes like AssembliesPerDomain, etc you can find information about in the help documentation. The key sections to be aware of are the section, section, and the section.
This section defines a new domain for your particular situation to run in. *** define this a little better. You will give your domain a name, and then you will use this name later to correlate the calling piece of your BizTalk solution with the called components config file.
This section defines where the called components config file resides. You can use absolute paths, or I believe you can use relative paths also.
In this section you are going to link your AppDomain (which contains the ConfigurationFile section) to the part of you BizTalk solution that calls the shared component. Let me clarify “part of your BizTalk solution”. When you create your orchestrations, you give them a namespace. They probably run under the same namespace, or at least the same root namespace. So, in the example you see “Source.Test.Orchestrations.*” as the pattern assignment rule. What this is saying is that any orchestration that is under this namespace would be associated with that particular app domain, and would then be able to make use of the configuration file listed under that app domain.
Hopefully with the example and the explanation, this will make some sense. There is some information in the help file about adding the new sections, but they don’t go into much detail of how all the pieces fit together, and what the pattern assigment rule is really supposed to point to, etc.
DON’T FORGET…BACK UP YOUR CURRENT CONFIG FILE BEFORE MAKING CHANGES. This will save a lot of headaches.
One last point to remember…and I won’t go into a lot of detail, but remember that if you are calling components from BizTalk, they must be GAC’d. It is possible that the shared components you are calling didn’t require to be GAC’d prior to calling them from BizTalk. Now that they are in the GAC however, you will need to change your shared components config file slightly. When you are defining your section for that component, you will have to change the attributes a bit so that you are including the following –
<SECTION type=", Version=, Culture=, PublicKeyToken=” name=”” />
The values for component name, version, culture and token you can get out of .NET Framework Configuration admin tool. Just look for you component, and make note of the values listed. The only one that should change would be the version.