A common question in my mind is how to correctly refer to the various editions of Team System in a short form. Since the full name is so long:
Visual Studio Team System 2008 Database Edition
for example.
Gert Draper, the architect on the Team Database Edition team, suggests using VSDB for the Database edition and VSDE for the developer edition. However, he also uses VSTS-DB. Team Database Edition is used by the install program.
So using the names from the product page, let's create a naming convention list:
| Full Name | Short Name | Long Acronym | Short Acronym |
| Visual Studio Team System 2008 Team Suite | Team Suite | VSTS-STE | VSTS |
| Visual Studio Team System 2008 Architecture Edition | Team Architecture Edition | VSTS-AE | VSAE |
| Visual Studio Team System 2008 Developer Edition | Team Developer Edition | VSTS-DE | VSDE |
| Visual Studio Team System 2008 Database Edition | Team Database Edition | VSTS-DB | VSDB |
| Visual Studio Team System 2008 Test Edition | Team Test Edition | VSTS-TE | VSTE |
| Visual Studio Team System 2008 Team Foundation Server | Team Foundation Server | VSTS-TFS | TFS |
Any suggested alterations?
I'm creating an application service that manages multiple AppDomains for worker threads. You have to do this in just the right way to get it to work with Visual Studio Team Edition unit tests.
Summary:
Background:
When you manually create an AppDomain using AppDomain.CreateInstance the defaults for settings are the executable's values. This is fine for a normal application. However, for unit tests, your code is running in an AppDomain other than the executable's domain, so that all the DLLs etc. can be loaded (NUnit works the same way). When you create instances in the new AppDomain, the type resolver is suddenly looking in the folder of the unit test harness executable, rather than in your test assembly's folder. You fix the problem by creating an AppDomainSetup instance and setting the ApplicationBase path to your own AppDomain's value. If that AppDomain is going to access your configuration file, be sure to also set the ConfigurationFile property to your AppDomain's value, also. The example I saw on the Team Test forum also set the AppDomain's Evidence to match the current AppDomain's also.
Example:
AppDomain currentDomain = AppDomain.CurrentDomain;
AppDomainSetup currentInfo = currentDomain.SetupInformation;
string fiendlyName = "FriendlyName";
Evidence securityInfo = new Evidence(currentDomain.Evidence);
AppDomainSetup info = new AppDomainSetup();
info.ApplicationBase = currentInfo.ApplicationBase;
info.ConfigurationFile = currentInfo.ConfigurationFile;
AppDomain domain = AppDomain.CreateDomain(fiendlyName, securityInfo, info);
References: