You probably noticed, that Visual Studio creates new files in your solution folder whether you like it or not. One of those files is the Solution User Options file with the .suo extension, which contains settings specific to the given developer machine. You can delete it, but it will quickly grow back.
You have to be careful with these per-developer or per-machine setting files, especially because you should not add them to source control. Not a coincidence that *.suo is the first item in the .gitignore file recommended for Visual Studio projects.
Unfortunately .suo is not the only file like that, you can see many of these polluting your project root when you are using different project types. It would be much cleaner if all those files would live in a single folder!
Thankfully it is already solved in Visual Studio 2015, and the IDE puts them into a separate directory which is called .vs similarly to other development environments:
The .vs is a hidden folder so you have to enable the Show hidden files, folders, and drives option in Windows Explorer if you want to peek into it (but why would you?). Currently (Visual Studio 2015 CTP6) the .suo file and the Visual Basic/C# IntelliSense database files are living in this folder and its subfolders, but in the future releases more and more files will be moved here, and hopefully this practice will be followed by add-in developers as well. If you are upgrading an existing solution, the old files will not be deleted automatically, so your settings are not lost if you open the project later with an earlier version of Visual Studio.
The best thing in this feature is that this folder was not invented by the Visual Studio developer team. It is there because I asked for it. I and 2822 other Visual Studio users on the Visual Studio UserVoice page. The IDE team looked at it, thought it through, accepted it and implemented it.
It feels so good, when developers listen to the end-users.
Technorati Tags: Visual Studio
You installed the Productivity Power Tools extension because you wanted to have nice vertical column guides in Visual Studio, but before you could set one they appeared everywhere?
What’s more you cannot get rid of them, because even if you click exactly the line the Remove Guideline option in the context menu remains disabled?
Here is the solution: turn off not the Column Guides, but instead the Structure Visualizer in the Options dialog:
With that you will lose some tooltip features as well, but at least now it is totally up to you where you want to display column guides.
Technorati-címkék: Visual Studio
I’ve received the following error message in Visual Studio right after I’ve tried to add a new service reference:
Unable to check out the current file. The file may be read-only or locked, or you may need to check the file out manually.
The message was really strange because the Add Service Reference dialog seemed to recognize the service perfectly, and although the project was under source control, we have Git on the server so “check out” did not seem to be the right term here.
The sad truth is that the above error message is completely wrong and the issue has nothing to do with source control. The solution is to click the Advanced button in the Add Service Reference dialog, then click the Add Web Reference button and use the old Add Web Reference dialog to add that particular service to your project even if the URL points to a .svc file.
if you ever wrote a unit test in Visual Studio you probably heard of the [TestClass] and [TestMethod] attributes, that you can use to annotate classes and methods which contain tests. You can use similar attributes to decorate methods, which should run before and after the tests:
Methods decorated with the TestInitialize and TestCleanup attributes are executed before and after each and every test.
Methods decorated with the ClassInitialize and ClassCleanup attributes are executed before the first test and after the last test in the current class.
Methods decorated with the AssemblyInitialize and AssemblyCleanup attributes are executed before the first test and after the last test in the current assembly.
The last two can be particularly useful if you do Continuous Integration.
Occasionally you may want to move your Team Foundation Server database to another server, because for example:
- You want to upgrade the underlying hardware or software infrastructure.
- You want to split the project collection between multiple servers.
- You want a copy of your live data in your test environment.
The process is fairly simple:
- Ensure that the target server has the same or newer SQL Server version than the source environment. It is important, because you cannot restore a SQL backup which was created with a newer SQL Server.
- Ensure that you have exactly the same version of TFS in both environments. Not only service packs, but also minor hotfixes matter!
- In your source server:
- Click Stop Collection in the TFS Admin Console.
- Click Detach Collection in the TFS Admin Console.
- Start SQL Server Management Studio and create a full backup of the database of the project collection.
- Copy the SQL backup to your target SQL Server.
- In your target server:
- Use SQL Server Management Studio to restore the database backup to a new database.
- Use Attach Collection in the TFS Admin Console.
- Update the SharePoint and Report Server settings according to your needs.
It may happen that when you try to attach the project collection TFS cannot find the restored database and you receive the following error message:
TF254078: No attachable databases were found on the following instance of SQL Server: MyServer. Verify that both the name of the server and the name of the instance are correct and that the database was properly detached using the detach command in the Team Foundation Administration Console.
The error message is really correct, so you can check the following:
- Verify that you can connect to the SQL Server instance and the database in it with the TFS service account.
- Verify that you have exactly the same TFS version in both environments.
- Verify that you have not skipped Step 3b and correctly detached the project collection from TFS.
TFS verifies the second and the third criteria by querying the list of databases in the SQL Server and then executing the following query in each of them:
SELECT name, value
WHERE name LIKE 'TFS_%'
This query returns the custom properties of the databases which start with “TFS_”. You can do the same in your target environment, and you will get something similar for your Configuration database:
This is for an attached database:
And finally you will get something like this for a correctly detached database:
If you cannot see the TFS_SNAPSHOT_STATE property with the Complete value, than you have a fair good chance that you forgot to detach the project collection in the TFS Admin Console before created the SQL backup.
If you don’t need the data of a project any more, you can choose among various tools to delete it from the Team Foundation Server:
- There is a Delete button on the Team Projects tab in the TFS Administration Console.
- You can run the tf.exe with the delete switch, which runs fast, but it only sets a flag to mark deleted files, so you can restore them later using the undelete command.
- The destroy switch of tf.exe permanently deletes the items, so you cannot restore them later. Unfortunately it can only delete items from the version control database.
- The TFSDeleteProject.exe is another command line tool which can delete not only from the TFS database, but also from the reporting and SharePoint databases.
Whichever method you choose, you may notice that the size of the database is not reduced immediately right after you deleted large amount of data. This is because all of the above methods leave some orphan data behind, which is deleted later by a job ran by the TFS Background Job Agent. However this job runs only once a day!
If you don’t want to wait that much, you can run tf destroy with the /startcleanup switch which immediately kicks off the cleanup job.
Another option is to dive deep into the database, and run the cleanup stored procedures manually. If your Content table is large:
EXEC prc_DeleteUnusedContent 1
If your Files table is large:
EXEC prc_DeleteUnusedFiles 1, 0, 1000
This second sproc may run for a long time, that’s why it has the third parameter which defines the batch size. You should run this sprocs multiple times, or if it completes quickly, you can increase the chunk size.
Obviously, this is not supported, but worked on my machine.
One of the best features of TFS is that the changes of the source code are documented not only by the changeset comments, but you can bind all changes to work items. TFS provides several work item types out of the box, however they are sometimes not perfectly suit our needs and require some customization.
Traditionally you can use the witadmin.exe command line tool to manage work item types. You can export their XML definitions and import them back to the server after you modified them. The benefit of this approach is that you can add the modified XML files to your source control to track the changes.
If you prefer GUI tools, you can install the TFS Power Tools which adds a Process Editor item to the Tools menu, which you can use to open the work item definition directly from the server:
In the next step you have to select which work item type you want to edit:
And you instantly get the list of the properties of the work item type:
If you don’t like that by default the Assigned To field shows all users of your server, then you can select this field from the and click the Edit button to modify it. In the second, Rules tab of the popup edit dialog you can see the reason of that behavior:
The problem is the VALIDUSER entry which refers to the Team Foundation Server Valid Users group. You can remove that and add the ALLOWEDVALUES rule instead, which allows you to configure the selectable list items. If you want to add user groups, you can refer to server-level groups in the [Global]\groupname form, and to the groups of the current project in [Project]\groupname form. For example:
You can find the detailed documentation of the available rules in the Rule Type dialog on the All FIELD XML elements reference MSDN page.
When you click Save the changes are directly committed to the server, and you may need to click Refresh in the Team Explorer window to let the Visual Studio client updated.