Collaborative Development of Office Solutions
Multiple developers can work on a Visual Studio Tools for Office project in the same way that they collaborate on other Visual Studio projects. Visual Studio correctly locates the Microsoft Office installation on each computer, even if Office is installed in different locations. However, there are some important considerations to be aware of.
Debug Properties Are Not Shared
Debug properties are not shared among multiple users under source control. Visual Basic and Visual C# projects store the debugging properties in a user-specific file (ProjectName.vbproj.user or ProjectName.csproj.user), and this file is not under source control. If more than one person is debugging, each person must enter debug properties manually.
If the project is housed on a network share instead of in source control, some extra steps must be taken to enable the collaborating developers to open the solution and test the assembly.
Source Control Requires Checking Out All Files
If you use source control for your projects, you should check out all of the files under a code file in Solution Explorer (such as the ThisDocument, ThisWorkbook, or ThisAddIn code files) every time you change the code file, even the files that are hidden by default. If you check out only the top-level code file, your changes might be lost.
After you make your changes, check all of the files back in. For more information about hidden code files in projects, see Office Project Templates.
Security for Informal Collaboration on a Network for Microsoft Office 2003
If a UNC path (such as \\Servername\Sharename) is used as the development location, the wizard presents a security warning. If the network location is not secure, another user can overwrite your assembly with a malicious assembly and compromise your computer. You can make the network location more secure by setting read-only access to the shared folder for everyone, and granting write permissions only to yourself and to people that require that level of permission.
You should not rely on the URL as evidence for trusting the assembly, but instead use a signature, publisher key, or other form of evidence to trust the assembly. For information about different forms of evidence, see Evidence.
The developers must be administrators on the network for Visual Studio to grant full trust automatically and run the project. If the developers are not administrators, an administrator must set the security policy to grant full trust to the assembly and document at the Machine level for each collaborating developer. For more information, see Office Solution Build Process Overview and Security Requirements to Run Office Solutions (2003 System).
Security for Informal Collaboration on a Network for the 2007 Microsoft Office System
For all document-level solutions that are in a network location (such as \\Servername\Sharename), the fully qualified location must be added to the trusted folder list in the Microsoft Office application that you are working with. Select the option to include the subdirectories under the main folder, or specifically add debug and build folders to the trusted folder list. For more information about how to do this, see Granting Trust to Documents (2007 System).
The temporary certificates that are automatically generated at build time are not secured by passwords. The certificates contain the developer's login name and other personal information. If you deploy customizations that are signed by temporary certificates, others might be able to access this information.
See Also
Tasks
How to: Deploy Office Solutions (2003 System)
Concepts
Creating Office Solutions in Visual Studio