In an earlier article (Visual Studio Source Control With Git & Visual Studio Online) we discussed how to add an existing Visual Studio to source control using Git, including syncing with a remote Git repository on Microsoft’s Visual Studio Online website.

While perhaps not as common a choice as Dreamweaver or some other tools, one can use Visual Studio to manage non-ASP.NET website projects. One reason you might want to do this is to take advantage of Visual Studio’s built-in source control features. Dreamweaver has some basic source control features as well but relies more on external tools to manage everything. There are advantages and trade-offs either way, so it really kind of comes down to personal preference.

I recently decided to create VS projects to manage some WordPress plugins and themes, and I discovered that the process for getting everything going with Git and Visual Studio Online is a bit different and not as straightforward as one might like.

Install The Git Command Line Tools

Once again, since we may have some new people in the audience, before we do anything else, let’s make sure the Git command line tools are installed. Go to the View menu and select the Team Explorer item near the top. This will open the Team Explorer view if it’s not already open. Find that window and click the Home icon from the icons at the top, then click Settings in the next screen.

Once you’re in the Settings screen, near the bottom there should be a section labeled Git, and one of the links underneath it should be Install 3rd Party Tools. Click that and follow the prompts.

How To Git ‘er Done

There are many possible variations on the whole process that will work, but there are also some things that won’t work as you might expect if you have been using source control with ASP.NET web projects or non-web projects. Through trial and error, the method presented here seems to be the easiest and quickest method I’ve found.

You’ll want to start with an empty workspace in Visual Studio, no open project or solution.

This method starts by creating a local repository. Go to the Team Explorer window (select it from the View menu if it’s not already open), then to the Connect section by clicking on the electrical plug icon, or by clicking on the section title underneath the icon bar, which will bring up a menu with choices for the different pages of the source control management.


Once you’re on the Connect page, then under Local Git Repositories, click “New” and then select the path where your project will be located. At this point that should be an empty directory.

If you want to use an existing directory with files already in it, move them to a temporary location for now, because Git won’t allow you to create a new repository in a directory that already has files in it. (No, I dunno why. Seems dumb to me too, but I’d imagine there’s some reason that hasn’t yet occured to me.)

Once you have the path selected, click the Create button.


Now that the Git repository has been created, make sure it’s selected by double-clicking it in the list.

If you had moved the files from the specified directory out to a temporary location, now is the time to move them back. If it’s an empty project so far, then I recommend creating a simple text file named something like {project}.txt (with your project name) so that we can add it to the repository and kickstart things.

Now go to the File menu and choose Open->Website. Specify the same folder where you created the new Git repository. You should get a new solution with a single project/website listed, like this:


At this point, you should save your project. Select “Close Solution” from the “File” menu. You’ll get a message asking if you want to save. Save the solution file to the same folder where you created the new Git repository. You’ll probably want to also set the solution filename to “{project}.sln” or something else that makes more sense than “localhost_42341” or whatever other random name was created by Visual Studio.

Saving the solution file to the repository folder is important. If you save to a different folder, then the solution file itself won’t be able to be added to the source control project. That would be bad.

Once the solution has been saved and closed, reopen it. In the Solution Explorer, note the little plus signs next to the filenames. This indicates that the file will be added to source control with the next commit operation. However, since we just added an entire project, there may be files in the list that we didn’t want to include, so we’ll want to review everything and remove anything we don’t want to include.

Go to the Team Explorer window again, and click where it says “Connect”. A popup menu will appear. Select “Changes“.


At this point you’ll see that the “Included Changes” section includes all of the files in the project directory. However, there may be files that you do not want included in source control for one reason or another. Review the list of files and if you see anything that should not be included, click on it and drag it down to the “Untracked Files” section at the bottom. You can use control-click or shift-click to select multiple items at once before dragging them.

Now we’re ready to make our first commit to the repository. Scroll back to the top of the window and click in the yellow edit box where it says “Enter a commit message”. Enter something relevant like “Initial check-in of project”.


Once you’ve entered your message, click the “Commit” button. If all goes properly, you’ll get a message like “Commit eeaa0e65 created locally. Sync to share your changes with the server.

Before we can sync, we need to specify the remote repository with which we’ll be syncing. If you haven’t already created the project on Visual Studio Online, now is the time. Refer to the earlier article (Visual Studio Source Control With Git & Visual Studio Online) if you need information on doing that.

Once you’ve created the remote repository you’ll need the URL. You can get this from the “Code” section of the project on the website:


Go back to Visual Studio, and click on where it says “Unsynced Commits” at the top of the Team Explorer window. Then enter the URL in the yellow box under “Publish To Remote Repository“.


Click the “Publish” button and it will start uploading your files from the local repository to the remote server. This may take awhile, depending on how many files there are and your connection speed. Eventually you should get a message telling you that the publish is completed.

Now, when you commit changed files to the local repository, you can sync to the remote server by hitting the “Sync” button after the commit operation finishes.

That’s pretty much it as far as getting everything working with source control is concerned. Have fun!

May 27th, 2009 by Mike Fulton
Categories: Microsoft, Web Design & Programming, Windows
NVIDIA Graphics Gadget

NVIDIA Graphics Gadget

I first got involved in creating Vista Sidebar gadgets back when Windows Vista was still in beta release.  I was asked by NVIDIA to create a gadget that would display the type of graphics card you have installed, the current NVIDIA driver version, how much graphics memory was on the card, and the current operating temperature.  And if you had two cards working in NVIDIA’s SLI mode, it needed to show the separate information for each of the installed cards.  Lastly, it had to be able to generate an alarm if the temperature got too hot.

It sounds like it’s really not that hard, provided you have a means of collecting those various tidbits of information about the installed graphics card(s), but it was still a challenging project in some ways.  For one thing, when I started the project, the documentation about creating gadgets was brand new and still undergoing occasional changes.   The first few weeks I was working on the gadget, the documentation changed 3 times.

Also, there were really no samples to look at except for those gadgets included with the Vista beta.   Some decent gadgets are included there, but none of them were created with the goal of being sample code for developers.  Between the lack of samples and the shifting documentation, there were a lot of questions about “Can you do xxx in a gadget?” that nobody seemed able to answer quite yet.

What Is A Gadget?

Gadgets are basically small, specialized webpages that exist independently of any visible browser.  Windows Vista isn’t the first system to have such an animal.  The Macintosh OS X has the Dashboard and “widgets”, and Yahoo has their Yahoo Widget Engine, previously known as Konfabulator.  All of these are slightly differnet flavors of the same idea.  They are all created with a mix of browser-compatible artwork, HTML, CSS, and your favorite scripting language. Generally, they can do almost anything you can do on a regular webpage, but are typically designed to show a specific and limited amount of information.

There’s usually some manifest file gluing it all together.   For Windows Sidebar Gadgets, there’s an XML document that specifies all the information needed by the system.

Gadget Scripting

Most gadgets need to allow for some interactivity with the user, or with web servers, database servers, or who knows what.  To manage this, you can use any client-side scripting language that is supported natively by Internet Explorer.  That means Javascript or VBScript for most people.  The good news is, you don’t have to worry about targetting 14 different combinations of browser type and version. 

Javascript code running in a gadget has some additional restrictions compared to code running in a standard browser.  Certain things just don’t work, such as alerts or input prompts.   And you’re not able to open new windows.

On the other hand, gadgets also have some additional capabilities available through Javascript compared to code running in a standard browser.  For example, they have access to a special system object class that provides access to variety of things that Javascript would ordinarily not be able to access.

Gadget Security

Gadgets have to live within a security model that’s more or less similar to what a regular webpage has, but there are some important differences.  The main example is that the System.Gadget object class allows your script code to access to the local file system and a variety of other things that Javascript would ordinarily not be able to access.

Another nice thing is that because gadgets are based locally instead of coming from a web server, the usual security restrictions for not allowing cross-domain script access have been lifted.  Your Javascript code can make Ajax requests of any domain as desired.

The NVIDIA Status Gadget

The NVIDIA Status Gadget needed to be able to display information that could only be obtained from one source: directly from the NVIDIA graphics drivers.  Since it was not possible to access the drivers directly from the gadget’s Javascript code, I needed an alternative way to get the information.  So what I did was to create an Active-X control that implemented an object that was accessible from Javascript.  This control was basically just a wrapper for the calls in the NVIDIA drivers that returned the desired information.

This got the job done, ultimately, but it did complicate development at first.  Before I could write the gadget, I needed the Active-X object, and before I could really test that the Active-X object was working right, I needed the gadget as a client.  Ultimately, the Active-X control wasn’t really that complicated, as such things go, but it was an added task that most gadgets don’t have to worry about.