What if you need to undelete a file or bunch of files that at some point have been deleted from TFS? Naive option would be to get the content of the file, copy it, create a new file, and paste the copied content to just created file. Of course, this is not a good option because history of changes to the file(s) will be lost.
Tag Archive for 'visual studio'
If you have never used RockScroll you are probably most comfortable with standard scrollbar Visual Studio offers. I guarantee you, however, that the moment you install RockScroll and work with it for a while, you will miss it a lot if you switch to Visual Studio that’s not extended with it. I’ve experienced that many times when kneeled at a teammate’s desk trying to help him move on with their task. This is probably best moment when you will realize that Visual Studio misses a thing without RockScroll
Here are most important pros that make me think RockScroll is must-have plugin for Visual Studio:
This was not an easy one… I was trying to run a unit test with MSTest but I was always getting the following error:
Unit Test Adapter threw exception: Type is not resolved for member ‘XXX,XXX Version=184.108.40.206, Culture=neutral, PublicKeyToken=null’
As usual in such case – a message which does not really say what’s wrong. I googled the problem but there was not much about it on the web. The best resource I found was post titled VSTS Unit Test ‘Type is not resolved’ exception. It describes how VSTestHost process runs the test and explains what the possible problem might be in this case.
The author suggests that data required for test (e.g. a dll file) is not found in base directory for AppDomain (i.e. unit test ‘Out’ directory) because it’s already switched back to directory that holds VSTestHost.exe. There are two links to MSDN given where Microsoft admits this is a known bug and provides a hack to work around the problem – supply VSTestHost with copies of required artifacts (again, this is described in details in above mentioned post).
Unfortunately that didn’t work with my case. I’ve found the root cause though…
Visual Studio provides solid support for unit testing. One of the features are VSMDI files – test meta data file. The file is not much readable but Visual Studio comes with easy to use GUI for managing tests (grouping them in test lists, filtering, etc.).
All in all, VSMDI files are really helpful but…
- After a while there are several VSMDI files (MySolutionName1.vsmdi, MySolutionName2.vsmdi, MySolutionName3.vsmdi, …) in your project although only one is in use (and therefore added to source control). This is a known bug discovered in Visual Studio 2005. More information can be found there.
- Painful merging. Merging can be smooth or really painful. It is the latter with VSMDI. Sorry, with VSMDI there’s no such thing like merging. If you discover someone else has changed and checked in VSMDI file (conflict), just replace your local changes with server version and repeat your changes.
The reason for the mess here is each test is given ID which is a GUID which tends to change once in a while.
- Not runnable tests. This doesn’t happen too often but I’ve experienced it several times already. When you try to run some tests you are told they are not runnable because there are multiple tests with the same ID (again, IDs…) – see below. Of course you haven’t played with IDs…
At least this is an easy one (but not when you see that for the first time). Just refresh the whole test list view – select List of Tests in Test List Editor window and click refresh.
Ok, so that’s my list. Any points to add here?
It happened to me after connection to TFS was dropped. and I was moved to offline work mode. Default VSTS settings say whenever you start editing a file it will be automatically checked out and it will appear on Pending Changes window. However, after those connection problems I no longer experienced that behavior.
First of all it’s worth checking VSTS Source Control related settings according to this article. In my case everything was fine there.
The problem on my side was somewhere else. After I had gone offline I had to go online again (what a surprise?!). I was expecting that to happen after reconnecting to TFS, but that is not entirely true. What I had to do as well was use ‘Go online’ button at the top of solution explorer. Once pressed it listed all the files I had modified while in offline mode and VSTS started working as before.
Note: I assume you can rebuild the program you are having problems with because changes in its configuration settings are required.
If you are struggling with this problem you are probably running 64bit OS and executing 64bit exe that loads 32bit dll, or the other way – 32bit OS on which 32bit exe tries loading 64bit dll. For the sake of this post, let’s assume this is the former matter.
You need to assure that 32bit dll is loaded by the program with the same bittness, even if it’s running on 64bit platform.
In order to achieve that you need to change the configuration settings of the project whose outcome is that exe so that platform target is always x86, disregarding configuration platform. Let’s assume that program is written in C#.
Open project’s properties, go to Build tab and make change as below:
Update, 2010-10-23 Note: After reading discussion on Martin Hinshelwood’s blog, I’ve decided to state clear I’m writing here about TFS 2008. Some of the points might not be relevant to TFS 2010.
I’ve been using both Subversion and Team Foundation Server (TFS). Because I first used Subversion and started using TFS afterwards, I had to get used to TFS flavors. I think TFS is great but to be honest there were a few things I missed from Subversion and a few things that really annoyed me when I started using TFS.
So, this is a list of strong and weak points of TFS from the perspective of a developer who switched to it after using Subversion.
Note: What is described below applies to Windows Vista x64 (at least I used such OS). I’m not going to describe what to do with a mini dump – how to analyze it in a debugger (e.g. in Visual Studio); such information can be found in a very good article at CodeProject. What I’m going to present here is how to set up Windows Vista so that mini dumps are created when an application crashes, and enforce they are stored locally on the machine on which that happened.
I believe every developer uses debugger while product creation. However it’s also possible to debug the application after it’s delivered to the client. One of such techniques is postmortem debugging – the act of debugging the memory dump of a process, which is stored in a special file (not human readable).
Microsoft has created a special service – Windows Error Reporting. Prior to Vista, Dr. Watson was default Windows application debugger that created crash dumps. Starting with Vista, Microsoft has replaced Dr. Watson with a new, improved mechanism. In short (supposing Windows Error Reporting is enabled), if an application crashes a mini dump (representation of the state of the process) is created. Mini dump is much smaller but still provides plenty of needed information. Depending on settings, a mini dump can be sent to Microsoft for further analysis. This is default behavior which, at least in my case, resulted in no mini dumps stored locally on the machine where the crash took place.
I had a load test that used a coded web test. At some point the coded web test changed, i.e. this line was added:
Outcome = Outcome.Fail;.
After this change the test stopped working – it always ended with error message: ‘User aborted test run’. Apart from that each iteration of the web test produced MethodAccessException: Microsoft.VisualStudio.TestTools.WebTesting.WebTest.set_Outcome(Microsoft.VisualStudio.TestTools.WebTesting.Outcome).
The reason for the problem was I was using Visual Studio TS 2008 without SP1. Once I installed the SP1, which must have updated mstest, the test started running successfully again.
The key point here is before SP1 Outcome was read-only property, which I learned there.
I wanted to change a load test so that it works similar to what Gabriel Szlechtman described in his blog. Additionally, I followed MSDN instruction on how to create a Load Test Plug-In.
So I created a new project with a plug-in class, added a reference to it from load test project and wanted to hook the plug-in with the test. However, when I was doing the last step I was getting the following error:
The fix is quite simple. When I added a new class for the plug-in, it was defined without the access modifier (and therefore it was
internal), which made the class accessible from other classes only in the same assembly. Adding
public access modifier for the plug-in class solved the problem.