Recently I was in a situation (on my local machine) where I could not create new users or do any admin related stuff on my SQLEXPRESS 2012 instance. After search around I came across this blog that showed how you can add an existing windows administrator to SQL and give it admin rights.
Microsoft also has a link about this process at http://msdn.microsoft.com/en-us/library/dd207004.aspx. However the blog (mentioned above) had pictures and seemed easier to follow! ;)
Recently I created a custom check-in policy that had to be distributed across all developers. There are multiple options of doing it (using an installer that all developers would use to install it, using TFS power tools or by using a “push” technique that would roll out the policies). Here the company already had an infrastructure setup for pushing files to end user machines and executing remote commands (using Windows PowerShell or just the regular MSDOS command line). Weighing We decided to utilize this infrastructure to roll out our custom policy rather than ask every developer to install (or copy and register) the policy manually.
We started by staging the policy on a NAS location that can be accessed by all developer machines. Using the registry key values (as mentioned in this article), the version of Visual Studio was detected.
1: reg query "HKEY_CLASSES_ROOT\VisualStudio.DTE.11.0"
2: IF ERRORLEVEL 0 (
3: REM Visual Studio 2012 is installed.
Since the registry path for a check-in policy are different for a 64-bit machine, compared to a 32 bit machine, it was important to detect if the machine was a 64-bit or 32 bit. I have used the simple approach of checking if the “ProgramFiles(x86)” environment variable exists. If it does then the machine is a 64 bit, if not it is a 32 bit machine. Microsoft has another approach, if you prefer and it is shown here – http://support.microsoft.com/kb/556009
1: IF DEFINED ProgramFiles(x86) (
2: REM This is a 64 bit machine
Now using the “reg add” command the check-in policy is registered. More information on the reg command is located here
1: reg add "%FullRegPath%" /v "%RegKey%" /t REG_SZ /d "%RegValue%" /f
The batch script is executed remotely on every developer machine any updates are pushed out using the existing infrastructure. Till now this process has worked for us. Hopefully Microsoft will come out with a easier, inbuilt approach to installing/registering check-in policies on all developer machines.
While working on a new check-in policy (for Visual Studio 2010) I came across an interesting issue. I had registered the policy under “HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\10.0\TeamFoundation\SourceControl\Checkin Policies” (for Windows 7, 64-bit OS). I had this policy setup with the name being different from the assembly name. The first time I added the policy everything seemed to work fine. However when I went back to view/change the policy I kept getting the error similar to the message below.
From searching online it seemed like the policy was not registered! How was this possible since I setup the policy from the same machine I am now trying to modify it…if it could find it initially why can it not find it now???
Turns out that the name (in the registry) should be the same as the assembly name and the data be the full path of where the assembly is stored. Since I had the name different from the assembly name, I kept getting this error. Once I changed it to be exactly as the assembly name, everything started working correctly.
Hope this helps others who are having this issue.
Recently we started noticing that out TFS database started growing rapidly (nearly 100 GB per month). On further investigation we found that the tests that were executed as part of a CI build had some big files that were being uploaded to TFS.
Grant Holliday has a good blog on using the test attachment cleaner to remove these big attachments – http://blogs.msdn.com/b/granth/archive/2011/02/12/tfs2010-test-attachment-cleaner-and-why-you-should-be-using-it.aspx
We used the tool to clean up a lot of database space. For preventing further growth of the database we also installed the hotfix (http://support.microsoft.com/kb/2608743) on all our build boxes.
TFS alerts that are sent to web services provided us with an option to extend TFS for out business needs. I created a web service and set up an alert in TFS to call my web service. However the web service was not getting any alerts. On doing some online searching, I found two very useful blogs that helped me to debug the TFS alerts issue -
Grant Holliday’s blog on SOAP subscriptions – http://blogs.msdn.com/b/granth/archive/2009/10/28/tfs2010-diagnosing-email-and-soap-subscription-failures.aspx and Chris Sidi’s blog on the Job Agent overview – http://blogs.msdn.com/b/chrisid/archive/2010/02/15/introducing-the-tfs-background-job-agent-and-service.aspx
Following their advice I was quickly able to determine the cause of the alerts not “reaching” my web service and fix the issue.
I also created a power shell script for changing the logging value
# Load client assembly.
[Reflection.Assembly]::Load(“Microsoft.TeamFoundation.Client, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a”);
# Set the TFS URL
$collectionBaseUrl = “http://myServerName:8080/tfs/myCollection/”;
# Connect to TFS Server
$tfs = [Microsoft.TeamFoundation.Client.TeamFoundationServerFactory]::GetServer($collectionBaseUrl);
$collectionHive = $tfs.GetService([Microsoft.TeamFoundation.Framework.Client.ITeamFoundationRegistry]);
# Get the logging level setting stored the collection hive.
# Set the logging level setting in the collection hive.
Many times users may want to send a URL of a work item, rather than the work item number, to another person. The recipient can then just click the link to view the work item details on the browser – something non-technical users would prefer to opening an IDE (Visual Studio or eclipse). There are two simple ways to achieve this – via outlook or by retrieving the URL for the work item.
Send the work item summary via Outlook (only from Visual Studio)
If you have Visual Studio you can select the work item and right click on it. You will notice the an option called “Send Selection to Microsoft Outlook” in the menu that pops up. Click on that option and a new email window will be created with the work item details inserted into the email body.
Get the URL of the work item
If you do not have Microsoft Outlook, you can still get the URL link (from the IDE). Both options are shown below -
If you are using Visual Studio, you will need to install “Microsoft Team Foundation Server Power Tools”. Once you have installed the same, you can right click on a work item and select “Copy Work Item Shortcut”. This will copy the URL to clipboard and then you can paste it a email/document and send it over to another user.
If you are using eclipse (with the Team Foundation Sever plugin installed) you can also get the URL for the Work item. From the list of work items (obtained using a query), right click the one’s whose link you want. From the menu that shows up select “Copy Work Item to Clipboard”. You now have a link to the work item that you can send to anther user.
Alternatively you can also open the work item in a browser and then copy the URL from the address bar.
Recently we came across an issue where a user could not open a work item in excel (using the “Open Work Item in Microsoft Excel” button in Visual Studio 2010). After a delay they are prompted with an error like the one below…
The user had the integration working fine till sometime back and suddenly one day this error popped up. The “Team” tab was also missing in Excel’s ribbon bar. It turns out that the TFS add-in for excel was disabled and had to be reactivated.
The following steps were followed to resolve the issue –
- Open the “Excel Options” dialog by clicking on the office logo on the top left hand corner and then click on the “Excel" Option” button on the menu that pops up.
- If everything is working fine, you should see the “Team Foundation Add-in” name appear in the “Active Application Add-ins” or the “Inactive Application Add-ins” section. The reason the add-in shows up in the “Inactive Application Add-ins” section is because the “Team” tab was not click to activate the add-in.
- If “Team Foundation Add-in” shows up in the “Disabled Applications Add-in” section, then from the drop down (next to the ‘Manage’ label in the screen shot above) select “Disabled Items” option and click on the “Go” button.
- In the “Disabled Items” dialog that appears, select the TFS add-in and then click the “enable’” button.
- You can also load (or enable) the add-in by selecting the “COM Add-ins” drop down option (as shown in the screenshot above) and clicking the “Go” button.
- Verify that the “Team Foundation Add-In” shows up and is pointing to the correct path. If not click on the “Add” button to add the plugin.
- Check the check box next to the add-in. Click the “Ok” button to close the dialog and you should be able to see the “Team” tab in excel.