When doing development with SharePoint, it is pretty well-known that because you develop directly against the object model that the environment must have SharePoint present. However, at a client this morning I was helping to build some test and development environments and for some reason the error:
“the local SharePoint server is not available”
kept bubbling up, when clearly there was a local SharePoint instance present. This error can occur after a variety of actions, such as invoking SharePoint Explorer or in visual studio deployment steps.
The quickest way to resolve the error make sure that the account being used to run Visual Studio is a db_owner on the SharePoint config and SharePoint admin databases.
Check-in policies within mature development environments are imperative, allowing the construction of code, to police checking in of code. Policies within TFS aid in enforcing restrictions and limitations whenever files are checked into TFS VC. TFS supplies a multitude of pre-existing check-in policies for actions like checking that unit tests are implemented, executing static code analysis to check for standards, and a bunch of others.
Unfortunately, there are some limitations however which I ran into recently with a current client of mine. The long and short of it is check-in policies cannot be included in process templates. However, there are custom development avenues you can use by building some managed code against the TFS API to execute this, the objects and methods that are used are fairly self explanatory. Consider the following that shows getting a collection of the current policies, and then setting the policies.
Firstly, getting an appropriate reference to the desired project:
TeamFoundationServer tfs = new TeamFoundationServer(http://tfs:8080);
VersionControlServer vcs = (VersionControlServer) tfs.GetService(typeof(VersionControlServer));
TeamProject tp = vcs.GetTeamProject(“Project”);
Off the TeamProject object instance, you can following call the GetCheckinPolicies method, which will allow you to return a Microsoft.TeamFoundation.VersionControl.Client.PolicyEnvelope array type. Essentially this is what we can refer to as the policy instance, representing the applied policy’s of type IPolicyDefinition. Since you have an active array, you can do push the array into a typed collection of PolicyEnvelope objects using List.AddRange
This particular error can be a pain in the ass to track down, and it will cause Team Build to be unable to create the drop directory. But there are only really two causes for it.
1) You will generally start seeing this error after a problem occurs with a build machine that causes you to recreate the drop location (meaning, it’s the only time I have seen it). Or something dealing with you remaking the drop location.
2) It can also come up with cross-domain development environments.
If you think you are experiencing problem #1
1) check whether the same same build agent for all the builds
2) check whether instead of an alias to refer to the machine you can use the IP
If you think you are experiencing problem #2
1) 9 times out of 10 this is a domain trust problem. Simply put, a TFS user domain doesn’t trust the TFSService account, thus when users are added the TFSService account doesn’t have the read permission on the domain controller. So you can either implement the domain trust or change the TFSService account to use the other domain.