Source Control Explorer is disabled, grayed out

If your Source Control Explorer menu link is disabled (grayed out), you need to be sure the default source control plug-in for Visual Studio is set to Team Foundation Server.

This is usually just a simple oversight for those of us that use TFS quite often. But since this has happened to me more than once and I don’t seem to remember the fix as quickly as I would like, I have noted it here for easy recall and for anyone else.

  1. Open Visual Studio
  2. Select the menu: Tools > Options
  3. In the Options dialog select: Source Control > Plug-In Selections
  4. Select Visual Studio Team Foundation Server

Maybe the action of posting this will be enough to help me remember.  :)

Editing JavaScript Using Visual Studio .NET

Mark Wagner
Castle Rock Software, LLC

December 22, 2004

Summary: Use the Visual Studio .NET development environment as your JavaScript editor.

Technologies and Tools

  • JavaScript
  • Visual Studio .NET

As a .NET developer, I have become very comfortable with the Visual Studio .NET development environment.  As a result of my profession I spend most of my time working with this application.  I have recently increased my use of JavaScript and wanted an easy-to-use editor that wouldn’t take long for me to become productive using.  I have debugged JavaScript with .NET on and off for a while now, but never did I really need to work solely with JavaScript.  Usually, I am working within the context of an ASP.NET sever-side project.

The purpose of a scripting language such as JavaScript, is to provide a flexible, forgiving language to accomplish relatively simple code logic.  My primary intent was simply to use Visual Studio .NET as my JavaScript editor in order to take advantage of the built-in Intellisense and debugging it provides; and I am very comfortable with VS .NET and liked the idea of having a single development environment.  A significant portion of my testing and debugging will take place within the browser (Internet Explorer, Netscape, and others), but Visual Studio does have a few nice tools that can be used to debug such as the watch window.

Creating a new JavaScript ProjectI begin by creating a new “JavaScript” project by selecting the File > New > Project menu option.  I happen to use C# when I code, so I selected the C# Projects folder; however, you could just as easily select the Visual Basic Projects.  Once you have selected your folder, select the Empty Web Project icon and then specify the name of your project.  In the sample below my project name is MyJavaScriptProject.  This will create a simple web project with no files in it.


Next, I add a new HTML page to my project.  Below is a sample of my simple completed HTML page.  When you add your HTML page, it will be empty compared to my example below.  As you inspect the HTML code below you will find it is a very simple HTML page with mostly javascript code contained within script tags.  Keep in mind, you can edit javascript (.js files) files as well.  However, since javascript files do not have a context by themselves, you will not get the full Intellisense available.  This is because the JavaScript code in the .js files is not within the context of an HTML document.  For example, you will not get the document object within your Intellisense.  Although you can still code using the document object, I like having the Intellisense available.  At least for now.


Quick NoteMake sure you allow (enable/disable) the JavaScript debugging in your Internet Explorer options.  These are usually in the Advanced section.  This will allow any JavaScript errors that occur while you test in your Internet Explorer browser to attach to your Visual Studio .NET debugging environment.

IntellisenseThe Visual Studio .NET HTML editor will provide Intellisense.  The use of Intellisense plays a major factor in my productivity.  Without it, I find myself digging through online help and books much more than I would like.  Even better, Visual Studio .NET provides Intellisense for the browser you want.  You do this by setting the targetSchema property of the HTML document in the properties dialog.  Below you can see the available schemas to chose from.  I find myself switching between Internet Explorer 5.0 and Netscape Navigator 4.0 options.  This allows me to easily use Intellisense when creating browser specific javascript code. 

Changing this targetSchema property tells the Visual Studio .NET editor what browser I would like my Intellisense to be compatible with.  When testing javascript code specific to Netscape I select the Netscape Navigator 4.0 option.  Then for example, when I type the javascript keyword/object document followed by the usual dot (period), I get the Intellisense populated with all the Netscape Navigator 4.0 compliant properties and methods.  The same is true when I select the Internet Explorer 5.0 option.

An important point to remember is that JavaScript is not strongly typed.  Because of this, the Visual Studio .NET editor cannot provide Intellisense for your JavaScript variables and functions.  However, your declared var-iables will appear, which is kinda nice.  I am not familiar with any of the other more popular JavaScript editors.  I expect they may try to perform some sort of design-time variable typing via reflection.  That would be purely a guess on the editors part, yet while keeping this point in mind, any help an editor provides is of benefit to the developer.


Testing My JavaScriptI can test my “JavaScript” project using the Start Without Debugging menu option, or Ctrl+F5.  This may be more of a convenience than a necessity.  Alternatively, I could simply open my test browser (IE, NS, Firefox, etc.) and point the url to my local project.  I typically just press the Ctrl+F5 keys.  Also, don’t forget to set the default page for your project to your HTML page first.



My appreciation for JavaScript continues to grow.  This is especially true as the standardization and functionality continues to improve between Internet Explorer, Netscape Navigator, and now Firefox.  I will admit that Visual Studio .NET is probably not the best JavaScript editor available.  However, it is much better than using a simple text editor, which is often done.  I have not taken the time to look into editors and debuggers for JavaScript.  I expect they provide more for the JavaScript developer since that is what they are specifically designed for.  I have personally not felt the need to dedicate time in learning the “best of’s” for each JavaScript editor available.  However, I would appreciate recommendations or suggestions you may have.

Broken Trophy (social remedy for the build buster)

by Mark Wagner

February 29, 2004

I was asked this last Friday to bring my Broken Trophy to work.  The Broken Trophy has been very effective at improving the productivity of the development team in the past.  If you work on a project with a team of developers, this is a must-have item.

I am currently working on a project of 12 developers.  Each new development cycle typically translates into the code base changing quite rapidly from day to day, or even hour by hour at times.  This usually (and should) diminish as the development cycle progresses.  Of course, we often need to get the latest version of the code base to continue developing or unit testing our code.  Nothing can be more frustrating when you’re coding away, or "in the groove" as I say, and you get the latest code base only to realize your project now fails to compile.  Usually somebody failed to completely check in their code, or their code simply does not compile!  This can be very frustrating, especially during tight development time frame – is there any other kind.

Yes, we have all been in this situation, and dare we admit we have even been the one causing this problem for others.  No developer wants to be at either end of breaking the build.  For this, I suggest to you the Broken Trophy.  The broken trophy is exactly what it sounds like – the most hideous, obnoxious, large broken trophy you can find.  Again, the larger, the better.  This should not be easy to hide or tuck away in a corner.

I found this to be the most effective way of reducing the frequency at which developers break the build for others.  Of course, nobody wants this trophy, and you will find some developers resistant to this idea.  However, I have experienced that even those who are opposed to the Broken Trophy soon ease into accepting it once they begin to reap the benefits of its presents.

The Broken Trophy does wonders in many ways, all of which are often what you or your teammates either want to do or are doing in less productive ways, recognize it, vent it, and forget it.  I have seen this bring a team together.  After all, we are all human and we will make mistakes.  The idea is to reduce the frequency of these mistakes that hinder the productivity of others.  Everyone will eventually get the trophy.  It may take a little longer for some than others, but I have always seen it even out in the end.  When the trophy is awarded, we usually have a quick announcement and chuckle that lasts about 30 seconds.  Nothing more.

Rules for winning the Broken Trophy:

  • The code in the source control database does not successfully compile.  The trophy goes to the person who broke the build by checking in code preventing the code from compiling successfully. 
  • The last person to win the Broken Trophy retains possession until the next person earns it.  This may be a matter of hours or minutes; or it may be a matter of days or weeks.
  • Falsely accusing someone of breaking the build.  They may announce they think the build is broken, but not absolutely place ownership on someone.  Doing so will earn the false accuser the trophy, if in fact the build is not broken.  This has its benefits as you will see below.

Here are things that do not win the Broken Trophy:

  • The code does not have to function correctly or even function at all, as long as it compiles.  This may sound odd, but functional or bug-free code has nothing to do with this award.  Allowing the code to compile, allows other developers to continue developing and testing their code.  That is what matters – productivity.
  • If someone is in the middle of checking code in to the source control management database (SC).

There may be situations where there is a disagreement as to whether someone has earned the trophy or not.  The rules above are clear and will usually determine the answer.  If not, a simple majority vote will solve the problem.  However, this has rarely been needed.  If you lose the vote and are awarded the trophy, suck it up.  Your team will respect you for being an equal team member.

Here is a list of the few outcomes you will get:

  • The team will find it easier to laugh about the problem instead of getting frustrated.
  • The team gets satisfaction in knowing the problem is being recognized.  This alone will begin to reduce the frequency of build-busting mistakes.  Your team will also become more aware of the lazy mistakes that have earned them (or others) the trophy, and they will be more intent on not making them again.
  • The team gets a chance to vent about it.  However, the venting is normally not an issue since the presentation of the trophy says it all.  There is rarely any need or desire to discuss it any more.  Point made, venting done!
  • The team can forget about the issue.  Although, jokes will continue at the recipients expense, they will soon subside once the trophy is awarded.  This is especially true as the trophy makes its way around the team.  The problem has been addressed!
  • Usually, the root cause of the broken build is researched and resolved before the trophy is even awarded.  This causes the team to focus on solving the problem first.  This is a beautiful outcome.  Remember, false broken build accusations can win the trophy as well.  Therefore, the whistle blower soon becomes very diligent in determining the problem before “officially“ sounding the Broken Trophy alarm.
  • After the trophy has been awarded to a few people, it will become easier to award and easier to receive, and the team will soon begin to recognize the reduction in build errors.  The confidence of the code in your SC database will begin to improve.

I have seen this work very well.  In fact, it has always work well.  The important point is to remember that this is all in good fun and good productivity for the entire team.  Some may see this as being controversial or a public fogging.  I have never seen this be the case.  The first person to win the trophy is usually the hardest to award – and receive.  When presenting the trophy the first time be sure to remind everyone of this.  As long as everyone focuses on the lighter side, your entire team will win.