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!

July 11th, 2015 by Mike Fulton
Categories: Humor, Miscellaneous Rambling, Web Design & Programming

HTML5 has been the big new thing around the internet for about 6 or 7 years now, and it got me thinking that, hey, it’s probably not too long before someone decides that the next version is overdue.  So I have to think HTML6 is peeking around the corner.

While there’s no doubt plenty of new features that will come with HTML6, I’d like to spend a moment to suggest some new tags that I think are sorely missing from the markup language. Combined with a reasonable application of CSS styles to properly set them off, these new tags would help users convey a greater depth of meaning to their web pages, comments, and message threads.

< sarcasm > Best New Feature Ever < / sarcasm >

One of the most glaring omissions in the HTML specification, going all the way back to the original version, is a lack of any tags to indicate the intended tone of voice. And as a result, one of the biggest problems with the entire internet is that people often don’t understand when a post is intended to be taken at something other than face value.

Being sarcastic is often referred to as being a “smart ass” — usually by those on the receiving end.  However, I didn’t think the idea of a new < smartass > tag would really get too much traction.

I really do think this tag would be a huge improvement to the internet, HTML, and life in general.

< satire > Because Sometimes Sarcasm Is Too Snarky < / satire >

Satire and sarcasm are related but not quite the same thing, so they really do need separate tags. Sarcasm is usually much more snarky, more obvious, and often has an undercurrent of anger and/or bitterness so it. Sarcasm is typically expressed by presenting the opposite of the desired argument. Satire is more subtle, and more tongue-in-cheek.

On many occasions I’ve seen someone post a link on Facebook and then go off making some angry comment about it, and it’s clear that they didn’t realize that The Onion is a satire website.

Parody is a less subtle version of satire. I don’t really think we need a separate tag for it, however. Thoughts? Questions? Perhaps we should put out an RFC on this?

< flame > Bitch Bitch Bitch < / flame >

Another good tone-of-voice tag would be flame.  This would indicate a block of text where someone is going off on a rant about something.  Usually it’s a complaint of some sort, but not always. Sometimes it’s just a very impassioned response to another post in a message thread. Expect cursing, WORDS IN ALL CAPITALS, and other good stuff.

It’s worth noting that this tag is already used informally by many people, albeit in an inconsistent fashion.  It’s time to make it official!

< troll > Oh Yeah, Well Nazis So There! < / troll >

An interesting internet phenomenon is the troll. No, not the mythical creature who lives under a bridge and attacks passers-by. An internet troll is someone who makes posts or comments on a message thread of some sort which are intended to manipulate other users, to provoke a certain response.

There aren’t any specific words or phrases to watch for in a troll post.  However, invoking Nazis, communists, gay marriage, former President George W. Bush, or President Obama are all traditional tactics of the modern internet troll.  A really good troll can combine all of those topics into the opening sentence of their post. But depending on the overall subject matter, a troll’s post really could be almost anything. For example,

Batman would beat Superman in a fight

J.J. Abrams has ruined Star Trek and now he’s gonna ruin Star Wars

The Nazis Took Everybody’s Guns Away Too!

Gay Marriage is For Faggots

I apologize for that last one. Although it’s arguably true, I realize that last word is considered a bit offensive. Unless you’re British and talking about cigarettes. However, it wasn’t my intention to offend, but rather to demonstrate how being offensive is one of the troll’s prime weapons.  There’s almost always some part of a troll’s post that’s offensive to someone.

I guess I have to apologize for the first example, as well.  It should be clear to anybody paying attention that Superman could heat-vision Batman into ashes from the other side of the solar system, so really, Batman has exactly as much of a chance to win as Superman decides to give him.

The main attribute of a troll’s post is extremism. It’s extremely offensive, or extremely conservative, liberal, or even extremely center-of-the-dotted-white-line middle-road.  More often than not, the direction of the extremism more or less indicates the direction of the troll’s actual option, but playing devil’s advocate is also quite common, as the troll is far more interested in provoking a response than they are about engaging in serious discussion or debate.

As with sarcasm, one of the biggest problems with a troll’s post is that many times, readers simply don’t understand that the post is purposefully (or perhaps subconsciously) intended to be incendiary and offensive.  Indeed, one of the things about a troll’s post is that you can’t even be sure it represents their viewpoint.

< funny > Well, Maybe < / funny >

As with sarcasm, it’s not always easy to determine when someone is trying to be funny.  If this post has accomplished nothing else, it should have proved that point beyond a shadow of a doubt. This new tag wouldn’t necessarily make a bit of text any more hilarious, but at least now you would have some indication that humor was the actual intent.

I wish I could use it now.

When I started working more with ASP.NET a couple of years ago, doing a couple of complete websites from scratch, rather than working from an existing template or someone else’s site, I soon ran into the error shown below. While trying to troubleshoot it I came to the conclusion that it’s both very common and yet not very well understood.  Eventually I figured I had a good handle on the whole thing so I thought maybe it was time to share.

Here’s the error you get from IIS:

Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that configuration specifies the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster.

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.Web.HttpException: Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that configuration specifies the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster.

To simplify what’s happening, the error occurs because the client and server aren’t using the same key to encrypt & decrypt data that gets sent back and forth by ASP.NET.

So, how does that happen?  The message refers to the  entry in your ASP.NET website’s web.config file.  This entry defines how ASP.NET gets the encryption key used to encrypt and decrypt data sent back and forth in ASP.NET.  The default configuration for  is to specify ASP.NET should automatically generate the key. When AutoGenerate mode is turned on, the key is generated at the start of the browser session and in theory should last as long as the user’s session with the browser is open.

It makes perfect sense that when you have multiple servers working together, you have to synchronize them in certain ways, such as making sure they all use the same encryption key.  So turning off AutoGenerate would make sense in that scenario.

But I was using a single, stand-alone server, not a cluster or farm, so the message didn’t seem to apply.  Oddly, the information I could online seemed to largely ignore this alternative.

After experimenting with it for awhile, I came to the conclusion that the problem can also be caused by the expiration of the session on the server side. This can happen for a variety of reasons, but the most common would be simply that the client side sits idle long enough.  Like, you know, if the user walks away from their computer at bedtime, leaving the site open in their browser window.

After the session has been inactive for awhile, the server purges it in order to recover the memory and any other resources that might be involved.  Later, when the user comes back to the computer and does something that causes an event, the JavaScript code that ASP.NET uses to do its magic will still have the old encryption key from the night before. When it sends data to the server, the server will create a new session, since the old one was purged.  But the new session will have a new encryption key that doesn’t match what just came in from the client, so it spits out the error.

Aside from the user being idle for awhile, there are other scenarios which can cause an open session to be reset, such as files in the website being updated, user’s authentication status changing, or the user’s internet connection changing in some way, to name a few possibilities.

When the session gets reset, the appearance of the error depends on what happens next.  If the user clicks a plain old fashioned link to another page, the error will not occur, since this does not require any encrypted data to be sent back to the server.  However, if the item being clicked is an ASP.NET HyperLink control or something similar where an event is generated, then the client will send encrypted data and the server will go boom.

Annoyingly, there appears to be no way to catch this error and recover from it once it’s happened, at least that I’ve found.

But the fix is simple.  Just always use a specific Machine Key configuration with your ASP.NET websites, rather than AutoGenerate. There is a web-based tool for creating a unique Machine Key available online.

A Brief Sidebar About The ASP.NET Page Life Cycle

These days there are a few different flavors of ASP.NET out there.  The original flavor is commonly known as “Web Forms”. Subsequently Microsoft has come up with ASP.NET MVC and Razor.  These newer flavors do things a bit differently in some ways, but this article is mainly about the original “Web Forms”.

When I first hit this error, I was still relatively new to ASP.NET and didn’t have a full understanding about the relationship between the server and client sides.  If that applies to you, then read on and I’ll try to explain a few things so you have a background for what’s happening with the error.

When your page is first loaded, ASP.NET creates an instance of the class which is attached to the page and then calls the methods named Page_Init and Page_Load to handle whatever processing is required to create the page.

Part of what gets created during this process is a block of JavaScript code which handles the client-side part of ASP.NET.  This includes a data structure called the viewstate which describes the status of all controls on the page which have the runat=”server” attribute assigned to them, regardless of if they are plain HTML tags or something ASP.NET specific.  This attribute means that when some sort of event occurs on the client side, we want to have it processed at the server side. The ASPX source file for the page can assign handlers for these events, or your Page_Init and Page_Load code can do it.

An event handler is a method (usually within your page class) which knows how to process the event in question. Whenever some event happens on the client that needs to be processed on the server, the ASP.NET JavaScript code updates the viewstate data, then encrypts it and sends it to the the server along with a description of whatever event occurred.  This whole process is known as a postback.

On the server side, when a postback happens, the Page_Init and Page_Load code for the current page is called again, just like it was when the page was first created, except now the property IsPostback is set to true, whereas it had been set to false originally.  Your page’s code can look at this value to determine if there is extra processing required for the postback, or if there something that can be skipped.

After the Page_Init and Page_Load code finishes, then ASP.NET calls the function that was designated as the handler for the event which occurred.  It might handle a button being clicked, or whatever else was done.  After this processing is done, unless the code redirected to another page, the updated viewstate structure is returned to the client, which then decrypts it and updates the window contents as indicated.

« Previous Entries