How to Initialize a Git Repository using Visual Studio Code and publish the code to Git Server (Visual Studio Team Services).

In previous article we learned about how to clone a existing Git repository to a local system. Today we would learn how can you Initialize a Git Repository in your local system first and then publish it to the centralized Git repository.

Lets start ..

Step 1: Create a folder in your local system directory.


Step 2: Open Visual Studio Code.


Step 3: Click on  Left_Bar_Explorer_Icon(Explorer ) Icon displayed on the left side bar of Visual Studio Code and Click on Open Folder button

Click Open folder link, existing on the Welcome Page under Start section (Shown below)


Go to File > Menu > Open folder
Use Ctrl + K, Ctrl + O

Step 4: Select the folder created above which would start displaying in Explorer windows as shown below.


Step 5: Click on the Left_Bar_Git_Icon (Git) icon displayed on the left side bar in Visual Studio Code. This would show a button “Initialize Git Repository”

Step 6: Click on “Initialize Git Repository” button. This will create a local .git folder in the local folder. This .git folder is the folder which does the magic and keep each and every detail about local branches, remote branches, local check-ins, log history and every other information which is required from version control perspective.

Once the repository is initialized the complete folder where the Git has been initialized would start to be tracked. Now git would start tracking this folder (HelloWorld) and shows the changes made with in this folder.Initialize_Repository_6

Step 7: Let’s add a new file to “HelloWorld” folder. As soon as any file is added or modified, it would start showing on the Git Icon on the left side bar as a number. If one file is added and one file is modified then total 2 would be displayed on Git icon as shown below where only one new file has been added and Git icon shows one.Initialize_Repository_7

The file added above is shown as “U” means Untracked. This is because this file is still not tracked by Git. This is because the file is not checked-in into the local repository.

Step 8: Click on the “+” on the right side of the file and Staged it. Provide some comment in the message box and click on Commit_All_Icon(Right) icon on the top, to commit the file in the local repository. Here just note that the file would be checked-in in the default master branch.Initialize_Repository_8

Now we are done with the changes and want to push the changes on the Git Server but you can see all the options available in git menu are disabled.Initialize_Repository_8.1

Also on the left bottom, Status Bar does not show Publish_Icon (Publish) icon which publish a branch to the remote server.


This is because Visual Studio Code does not know where the files need to be pushed or in the other words the destination is still not defined. or technically it can be said that Git Remote is not defined.

Step 9: Let define a git a remote with the url of Visual Studio Team Services (VSTS). Here I would like to mention that I have a account on Visual Studio Team Services and this is free to use up to 5 users. So if you have a small team of 5 members, you should give it a try.

As I do not have any predefined repository on VSTS so first we need to create Repository in VSTS. As the scope of this article is to use an existing Git Repository so I am assuming the HelloWorld repository is already created in VSTS. Creation of repository in VSTS is very easy and after login to the VSTS, you need to create a project which internally create the Git repository. You have choices to choose either Git ot TFVC.Create_Remote_Repository

Default remote which Git refers by default is “Origin”. I would be defining a local remote using “Origin” only with “HelloWorld” repository created on Git Server. After defining a local remote Visual Studio is aware about that to which repository the code has to be published and what would be the repository name.

The command for defining a git remote is git remote add <remote name> <repository url>

Open Terminal and Run the above command.Define_Remote

Once the remote is defined, publish icon would be displayed in Status Bar.Publish_After_Remote

Step 10: Now once the remote is defined, you can push your files to the remote server. The command to push the added/modified files to the server is

git push -u origin –all


If all goes well, you would get the messages shown above which push all the objects to the specified repository and the Sync_Icon (Sync) icon would be displayed in Status Bar.


Now whenever you have any local commit to Push or any commit to Pull, it would show up in the status bar itself as shown below.


Here it shows that 1 commit is required to be Pulled from server and 1 commit is required to be Pushed to the server. After clicking on Sync icon the local branch and server branch would be Synced and both the code base will be same.

That’s it…

I hope this article would help you to setup Git for the first time where you have files in the local system and the same need to be published to the Git server for the first time.

Happy Coding!!!


Configure Git with Visual Studio Code


After a long time, today I got a chance to share my new learning with you all in which I will discuss how to Configure Git with Visual Studio Code. We  recently started working on an AngularJS application and decided to use Visual Studio Code Editor for development.

As a first step we needed the Visual Studio Code (VSC) to be configured with Team Foundation Server (TFS). VSC has inbuilt capability to be configured with any Git repository (DVCS). Here I would like to mention that VSC does not have capability to be integrated with TFS repository (CVCS).

After searching the net, I still could not make out what is the easiest & straight forward way to configure Git in VSC where the Remote Git Repository is already available because I did not find any UI Clone command under Git menu. Also there is no way to define the remote repository location which need to be cloned.

Git Context Menu

Git Context Menu

After playing with VSC for some time, I found the way to configure VSC with Git in just 5 steps which were easy and straight forward.

Let’s see what are those 5 steps.

Step 1: Install .Net Framework 4.5 from Web Installer or Offline Installer.

Step 2.a: Open Visual Studio Code

Step 2.b: Go to View > Integrated Terminal

Step 2.c: Navigate to the directory (Use DOS CD command) where the remote Git repository need to be cloned. Lets say we would like to clone under C:/Git/ and suppose the remote repository name is sg_angular.

Step 3: Before running the Clone command, we would be running the following command to Cache the Git Credentials in Windows else when ever Git Sync/Pull/Push command is triggered, it will ask for credentials. This step can be avoided, if you are OK to provide the password every time.

Cache Credentials to avoid prompt every time.

Cache Credentials to avoid prompt every time.

Step 4: Now type git clone <Your Remote Git Repository URL> like shown in the below picture. Press Enter.

Clone Command

Clone Command

Step 5: Credentials window should be opened. This would ask the credentials which would allow you to connect with remote repository.

Git Credentials Window

Git Credentials Window

Once the credentials are provided, VSC will start cloning the Remote Repository under navigated folder.

Make sure the git command is typed in small characters else you may get “fatal: cannot handle Clone.exe as a builtin“.

Clone Remote Git Repository using Integrated Terminal

Clone Remote Git Repository using Integrated Terminal

In order to use the local repository, Please Go to File > Open Folder and Select the folder from C:\Git\<Git Repository Folder> Or Your own folder. This will open all the files in explorer and you can start changing the files.

That’s All…

Happy Coding..

ASP.Net Website Project – External Assembly References

Today I just thought of removing the Assembly Reference errors which I get whenever I take the latest of an ASP.Net Website Project (Not ASP.Net Web Application Project) along with many class library projects.

 As we all know that Website project does not have any project file which can keep reference path and refer back dependencies from that path, the question arises where exactly these external assembly references are stored?

The first thought came to my mind was, If project does not have any project file then it would be having same information somewhere in Solution file.  After going through the complete Solution file carefully, I learned that Solution File has references but all Internal for which the Projects are already added in same solution.

During 2 Hours of Goggling I found many links which had discussed about the same and provided many solutions.
One of the link from “” specified that Visual Studio creates a Solution file in Projects folder of respective version of Visual Studio. If someone is using Visual Studio 2010 then a solution will be created at “C:\Users\username\Documents\Visual Studio 2010\Projects\YourWebSite\YourWebSite.sln which will have the path to the external assemblies.
I got what I was looking for and followed the specified path and later realized that  In this case I already had a solution created to manage all of my projects and except that solution I could not find any solution created anywhere.
Another thread suggested that an xml file is created at “%LOCALAPPDATA%\Microsoft\WebsiteCache\Websites.xml ” and the same is updated every time whenever an external link is added or removed. When I explored this location, found the same xml but unfortunately it did not have any reference’s to any external assembly.
During the search I was Adding and Removing the references in the Website project continuously and in the same process accidently noticed that whenever I add the external assembly reference, an additional file is also being added along with the assembly and this file had an extension “.refresh” and the full name was like “.refresh” e.g.  Telerik.Web.UI.dll.refresh . As always at first I thought of leaving this file and move ahead with my research but then decided to read about the same and was quite surprised with what I found about it. 
However I had seen this file quite many times earlier too during checking in the code to Source Control but never cared and left it unnoticed every time and today luckily opened this file in notepad. “.Refresh” file is the file which contains the full relative physical path of external referenced assembly. When you open this file, it looks like ..\..\..\3rdPartyDLLs\Telerik.Web.UI.dll .
As a Best Practice we do not add bin folder and any file added to it, in Source Control but in case of Website project, in order to allow the Solution to resolve the external references automatically during build of the project itself, it is required that .refresh files are checked in source control so that whenever anybody takes the latest for first time these assembly are placed in bin folder automatically.
Once I found all this, luckily I got an article over the web too explaining .refresh files and its usage.
In case you find this article interesting, please do not forget to share the same with your peers and friends. You can use the email link below or any social media of your choice. Also rate the article, if it has really helped you learning something new.
I will be back soon with something new and interesting too.

Till then… Happy Learning..

DOCTYPE (Document Type) Explored


Recently when I started studying HTML5, first question came to my mind was that how does a browser come to know, if written HTML is compatible with HTML v4.1 or HTML v5.

In order to find out the reply of the same query, I started exploring and here I would like to share my knowledge about the same. While exploring, I came to know that all this is controlled by a tag called <!DOCTYPE> which is a very first tag in most of the web pages which really made me surprised because every web page has this tag added automatically whenever a page added using some IDE but I never cared about this tag and never tried to explore but this time Just out of curiosity to know more about this tag, I dug up a little more.

In this article I will be explaining about <!DOCTYPE> tag and will give the answer of following queries.

How does a browser come to know, if the page written is in HTML4.1 or HTML5?

What is a <!DOCTYPE> tag and what does this tag do?

How many types of DOCTYPE HTML4.1 & HTML5 have?

How <!DOCTYPE> affects the rendering of HTML elements on different browsers?

How a wrong “<!DOCTYPE>” make an HTML page invalid?

How to verify, if a page written is valid or not?

How should we decide on defining the type of <!DOCTYPE>?

How <!DOCTYPE> is related to document mode (Standard, Quirks and Almost-standards mode) and How does a browser decide about rendering of a web page in Standard mode or Quirks mode?

Lets Start Exploring

So let’s start answering one by one.

How does a browser come to know, if the page written is in HTML4.1 or HTML5?

As I mentioned earlier that whenever a webpage is added using some IDE, a Tag called <!DOCTYPE> is automatically added on the top of the page which has few attributes defined in it. This <!DOCTYPE>  tag represents and signal the browser that the page about the used HTML version. Whenever a browser encounters a webpage that contains a <!DOCTYPE>, it uses the value of the document type to determine the document mode for the webpage. Because HTML 5 has just one <!DOCTYPE> which we will discuss in a little while, so this <!DOCTYPE> is defined like <!DOCTYPE html>. This tag itself denotes that written webpage is compatible with HTML 5. So whenever <!DOCTYPE> is defined as <!DOCTYPE html>, it means the HTML5 is being used.

What is a “DOCTYPE” tag and what does this tag do?

A “Document Type Declaration” or <!DOCTYPE> tag instructs the web browser about the version of HTML, web page is written in and about how other tags will be rendered on the browser.

The <!DOCTYPE> tells a browser, “I’m using HTML 4.01.” When the browser sees that, it assumes you know what you’re talking about and that you really are writing HTML 4.01. That’s good because the browser will use the layout and display rules for HTML 4.01. This tag informs the browser that the written HTML is a Standard and accepted by all the browsers. This Standard could be any one out of 3 standards i.e. Strict, Transitional & Frameset about which we will discuss further down the line.

When “DOCTYPE” is declared in a page then, the browser knows exactly how to handle your page and (at least on any browser you’d care about) the page is going to display as you’d expect. It tells the browser the type of the document.

“DOCTYPE” declaration represents that Standard HTML has been written and the written HTML page is compliant with the standards defined by W3C (Worldwide Web Consortium).

In HTML 4.01, the <!DOCTYPE> declaration refers to a DTD (Document Type Definition) . The DTD specifies the rules for the markup language, so that the browsers render the content correctly.

The purpose of a DTD is to define the legal building blocks of an XML document. A DTD defines the document structure with a list of legal elements and attributes. A DTD can be declared inline inside an XML document, or as an external reference.

A <!DOCTYPE> tag must be the first tag in an HTML document and it looks like

<!DOCTYPE html PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN”“”>

The following picture dissects each part of the DOCTYPE tag. Read carefully to get fair understanding about the same.

Document Type Declaration

Document Type Declaration Transitional

Now you might be thinking that we have not talked about the word “Transitional”. What’s with this transitional? If we’re writing “standard” HTML 4.01, why is it transitional? Let’s understand the meaning of the same.

There are actually two DOCTYPEs, one for those transitioning to HTML 4.01, and a stricter DOCTYPE for those who are already there.

Imagine you’ve got a Web site with hundreds of Web pages, all written in nonstandard HTML. You’d like to improve the site and get that entire HTML up to the 4.01 standard, but you’re using lots of old legacy stuff from back in the 2.0 and 3.2 days of HTML. What do you do? Use the HTML 4.01 Transitional DOCTYPE, which allows you to validate your pages but still permits some of the legacy HTML. That way, you can be sure you don’t have any outright mistakes in your markup (like typos, mismatched tags, and so on) but you won’t have to rework your entire HTML to get it to validate. Then, after you’ve removed the entire legacy HTML, you’re all ready for the strict document type, which ensures you have a fully compliant, standardized Web site.

How many types of DOCTYPE HTML4.1, XHTML & HTML5 have?

HTML 4.01 & XHTML has three different <!DOCTYPE> declarations  while HTML5 there is only one <!DOCTYPE> declaration.

HTML 4.01 Strict

In this DTD, all HTML elements and attributes are allowed except presentational or deprecated elements (like font). Framesets are also not allowed.

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01//EN” “”&gt;

HTML 4.01 Transitional

In this DTD, all HTML elements and attributes are allowed including presentational or deprecated elements (like font). But still Framesets are not allowed.

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN” “”&gt;

HTML 4.01 Frameset

In this DTD, all HTML elements and attributes are allowed including presentational or deprecated elements (like font) along with frameset content.

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01 Frameset//EN” “”&gt;

XHTML 1.0 Strict

In this DTD, the markup must also be written as well-formed XML. All HTML elements and attributes are allowed except presentational or deprecated elements (like font). Framesets are also not allowed.

This DTD is equivalent to HTML4.01 Strict DTD but the markup must also be written as well-formed XML.

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN” “”&gt;

XHTML 1.0 Transitional

In this DTD, the markup must also be written as well-formed XML. All HTML elements and attributes are allowed including presentational or deprecated elements (like font). Framesets are also not allowed.

This DTD is equivalent to HTML4.01 Transitional DTD but the markup must also be written as well-formed XML.

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “”&gt;

XHTML 1.0 Frameset

This DTD is equal to XHTML 1.0 Transitional, but allows the use of frameset content.

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Frameset//EN” “”&gt;


This DTD is equal to XHTML 1.0 Strict, but allows you to add modules (for example to provide ruby support for East-Asian languages).

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.1//EN” “”&gt;


<!DOCTYPE html>

How “<!DOCTYPE>” affects the rendering of HTML elements on different browsers?

Different browsers render the different tags differently. Whenever we define a DOCTYPE, it means we are telling to the browser that HTML Standards of the specified DOCTYPE have been used.

When I think about little past then this really make me smile that I had been so frustrated sometimes that few of the web pages of an application opens in “Quirk” browser mode while some will open in “Standard” browser mode. While exploring about “DOCTYPE”, I came to know that only correct “DOCTYPE” is responsible for opening the webpage in correct browser mode also.

How a wrong “<!DOCTYPE>” make an HTML page invalid?

Defining a wrong DOCTYPE makes Web page invalid. e.g. while developing a page if someone has mentioned the DOCTYPE as Strict and still he uses the deprecated element like “font” then this element makes that page invalid or let us say we have used <img> tag and we have not defined “Alt” attribute to this tag then also it become an invalid page because as per Strict DTD “Alt” attribute is mandatory to define in <img> tag.

How to verify, if a page written is valid or not?

W3C has a website which allows you to validate your webpages against defined “<!DOCTYPE>”.

This website allows 3 ways to validate a webpage.

  1. Validate by URI which allows validating a webpage online. If your website is available publically then the webpages can be validated by providing the url directly in the website.
  2. Validate by File Upload which allows validating a webpage by uploading the page on the website.
  3. Validate by direct input which allows validating a webpage by coping the markup in the provided area in the website.
W3C Page Validator

W3C Page Validator

How should we decide on defining the type of “<!DOCTYPE>”?

While defining the “<!DOCTYPE>”, big question comes to our mind that how should we decide that what type of DOCTYPE (DTD) we should define. Well it’s quite simple.

Transitional DTD gives us a transition point between old style HTML and standard HTML 4.01 so whenever we have old written webpages and want them to make compatible with latest browser with much hassle we can go for “Transitional” while if we are developing new web page then Strict must be used.

How “<!DOCTYPE>” is related to document’s mode (Standard & Quirks) and How does a browser decide about rendering of a web page in Standard mode or Quirks mode?

The browser will figure out that you’re not really writing HTML 4.01 and go back to quirks mode. And then you’re back to the problem of having the various browsers handle your page in different ways. The only way you can get predictable results is to tell the browser you’re using “HTML 4.01” and to actually do so. As web is becoming a standard day by day and all browsers are willing to support the standards only hence we should use the Standard document mode which can be forced by using <!DOCTYPE html>

While exploring about the DOCTYPE, I came across one of OReilly’s Head First book which had an interesting Interview between Browser and Head First. I would like to share that Interview here which is quite interesting and me to clarify the topic.

Head First Interview with Browser

Head First Interview with Browser

In this article we have learnt about <!DOCTYPE> and Document’s mode which are important to render a page consistently in all the browsers. It is always recommended that we use instruct the web page to use the Standard document mode and always define a <!DOCTYPE> in the page to avoid any compatibility issues.

I would appreciate, if you could let me know your feedback about the article content, presentation and coverage which will help me to improve on in my future articles.

Happy Learning…