After installing VS 2008 and Team Explorer, a colleague of mine asked why she couldn’t see the “Send Selection in Mail” feature as the rest of us could. Here is why.
1) First, you need VS 2008 SP1. SP1 is key here.
2) Second, you need Power Tools.
3) Third, you need to make sure “.NET Programmability Support” is configured.
If you do 1-2, but not three, you’ll get an error that says “TF242403: To send a query or work items, you must install Outlook 2002 or later” even if you’re running Outlook 2003 or Outlook 2007.
Tuesday, March 30, 2010
Enabling the “Send Selection in Mail”
Posted by Mac Noland at 9:15 AM 1 comments
Tuesday, March 23, 2010
“A version of Microsoft Visual Studio that is incompatible with this one”
A trusted colleague of mine recently tried to open a VS 2008 solution on his machine. When going to File – Source Control – Open from Source Control and double clicking on the Solution File, he got the message "the project [solution name] cannot be opened from source control because it was created by a version of Microsoft Visual Studio that is incompatible with this one."
We first though it was that he didn’t have VS 2008 SP1 installed. (I have SP1 installed and it worked fine for me.) However, even after installing VS 2008 SP1 he continued to have the problem.
We’re not sure what was corrupted, but after deleting his workspace and recreating it, the error went away. So it must have been a corrupted workspace, or something along those lines, that caused the issue.
It’s funny in technology how often, when in doubt, nuke and pave works.
Posted by Mac Noland at 2:25 PM 2 comments
Wednesday, March 17, 2010
Visual Studio 2008 SP1 with Team Explorer Hanging
I’m not sure when it started, but my Visual Studio 2008 SP1 has been hanging on my lately. Looking in Task Manager, I see devenv.exe*32 is consuming 99% of my CPU. My life has been within Java lately (via Teamprise’s Eclipse Plug-in) so I haven’t opened VS much, however, winds are changing a bit and so I have it open more often now than before. And the hanging has been getting on my nerves.
I’m not 100% sure of the cause, by I think it might be the Team Members (working….) that I see sporadically on a few of the ~24 Team Projects I have on my list. My guess is that is causing some issues.
I don’t use the Team Members feature of TFS so I’ve disabled it following these instructions. I just did the first step and it seems to have stopped the hanging for now.
So far so good, so hopefully I’m not speaking too soon ;)
Posted by Mac Noland at 10:00 AM 1 comments
Tuesday, March 16, 2010
Connecting Visual Studio 2008 SP1 to TFS 2010 RC
After my colleague installed TFS 2010 RC to our DEV system, I mustered up the courage to try and connect via Visual Studio 2008 SP1. Not much luck starting out.
I don’t remember the exact error, but it was something in regards to "Unable To Connect." Thanks for letting me know.
After reading through a few blogs and discussion boards (most of them referenced the need for Visual Studio 2008 SP1 which I already had), I came across this one which at the bottom shows you a registry edit you can make to add the TFS 2010 to your VS 2008 SP1 server list. After trying this, I got a bit farther and finally a meaningfully error message.
When trying to connect, we got "You Must Update Your Client with the Forward Compatibility Update.." I couldn't copy/paste the link in the dialog window (sigh), so I got out my pencil and paper to write it down. Here it is for you so you don't have to repeat the same archaic steps.
After installing this package, I was able to connect by putting in http://$server-name:8080/tfs/$collection-name
Posted by Mac Noland at 8:37 AM 3 comments
Labels: 2010
Friday, March 12, 2010
Out of Memory Exceptions in Ant
While trying to get some new build machines cooking, a colleague of mind forced me to notice that Java 1.6 on Windows must default it’s heap size to 64 megs. When running an Ant job, he was getting and Out of Memory Exception when trying to compile JUnit reports via the JUnitReport Task.
I figured out the default heap size by opening JConsol and checking Max setting on the Memory Tab. Sure enough, without any Max Setting it was 64m.
What got this whole thing confused was that we were setting a larger heap (1.6gig) on the JUnit execution. That is, when JUnit forked out for its own VM to run on, it used 1.6 gigs which turns out to be more than enough. However, the Ant process was running at 64m (the default remember) and giving us fits when Ant’s JUnitReport, which does not fork itself, was trying to compile the HTML reports.
To fix this, we simply upped Ant’s Max Heap Size to something larger (e.g. –Xmx512m) by setting ANT_OPTS=–Xmx512m as an Environment variable on the server. (As a side note, remember you need to refresh the environment of any tooling needing to use this new variable. Examples are recycling a process like Team Build or closing and restarting your command prompt). Once we did this all was better.
Free coffee is coming my way!
Posted by Mac Noland at 9:46 AM 0 comments