free html hit counter
Posted on: Tuesday, 10 January 2017 by Rajiv Popat

I’m obviously late to the party but I’ve been hooked on to Visual Studio Code both as an editor and a complete IDE for developing .NET Core Applications and all I can say about Visual Studio Code and .NET core is that I am loving everything I see.

Getting up and running with .NET Console applications is really easy with Visual Studio Code and something I'll probably cover in a different post. This post is focused more around building and debugging ASP.NET Core applications using Visual Studio Code. In the posts to come we will build a simple real life application using .NET core and Visual Studio code.

I recently needed a simple application where I can store excerpts from various books and research papers I read for future reference and so that's the project I'm going to work on for the purposes of these posts. The code that we build during this series will eventually be open sourced and posted on GitHub.

In this post we get started with a simple ASP.NET Core project using Yeoman and the .NET Core CLI and we will then debug it using Visual Studio Code. Why do all this when we can build the same application using Visual Studio 2015? Even though we will build this application in Windows we want the toolset and code to be portable so that we can easily move to Linux or Mac and start developing there whenever we feel the need to do so; which is why we won’t use anything that we cannot use in a Linux or a Mac environment.

In fact, once we get through a couple of posts, we will actually move to a Linux machine and start developing there.

Let’s start by creating an ASP.NET Core app and setting up the debugging using Visual Studio Code. You can of course do this using two ways:

Approach #1: The .Net Core CLI:

This is probably the simplest and provides you with a nice clean ASP.NET Core application. Pretty similar to doing “File / New / Web Application” in Visual Studio if you happen to be a Visual Studio developer in the past. Some folks may love this because it’s straight forward. Others may not like it because it bundles a bunch of things (like the Entity Framework, Membership and stuff you may not even be interested in using). Plus as of now, it doesn’t seem to integrate things like bower out of the box (more on this later).  However, if you are looking to get up and running with a simple ASP.NET Core app up and running quickly you can start a command prompt window, go to the folder you want to create the project in and do:

dotnet new -t Web

This creates a simple Web Application project. To fetch all the dependencies the project needs you would have to do a:

dotnet restore

And to run the project (which also builds it automatically) you would do:

dotnet run

This would start the development web server and host the application which means you can now access it using http://localhost:5000:

And if you open your browser and hit the URL you have the application running:

We’ll come to the debugging part in a minute. Of course if you are not happy with a bunch of extra things that were added to your environment you can of course get more control over the templates that you use for stubbing out your application using Yeoman, which of course brings us to the second way of stubbing out your ASP.NET core applications.

Apporach #2: Yeoman Templates:

You will have to install Yeoman before you begin with this, which of course would mean installing NPM (and the simplest way of doing that is installing Node JS). Yeoman also fetches your Javascript files and files like the bootstrap.css from the right locations using Bower. So you are better off installing bower up front before you proceed.

Once you have Yeoman installed you can do a:

yo aspnet

From your command prompt once you are in the folder where you would like to create the project. Yeoman of course gives you larger control over the project you stub out by letting you pick from a host of templates that you can use (which would in turn decide which dependencies get installed):

In the above sample / screenshot we have an option of picking from different templates. We can pick a basic web application without Membership and Authorization OR just “Web application” which has everything (including membership and authorization pre-configured).  Of course with this I also get to pick between the UI framework that I would like to use for my project:

In the above example I’m going Bootstrap. Once done you would specify the name of the project and once that is done you can go ahead with::

cd research
dotnet restore
dotnet run

In the above command we switched to research folder because yo command creates a folder with your project name. Once you run the code with ‘dotnet run’ You get a similar application this time as you did with .NET CLI only this time around you don’t see the Login link on the top right corner of application:

Now that we have the application up and running (with both .NET CLI / Yeoman, depending on what you pick), let’s get to debugging it using Visual Studio Code.

Debugging Using Visual Studio Code:

The more I use Visual Studio Code the more I seem to like it. It’s light. It’s elegant. Works on multiple platforms and what I love about it is the ecosystem of plugins that turn a lighting fast editor into a full blown IDE! If you don’t have the IDE, grab a copy from here and install it on your machine. Now from the command prompt you can navigate to your project folder and type a “code .” (without the quotes) and you should see your project open. The “.” of course, stands for the current folder and in Visual Studio Code you don’t work with projects / solutions, you open specific folders. Which means if opening the project from command prompt doesn’t make sense to you, you can open Visual Studio Code and Open a Folder from File / Open menu. The moment you open the codebase in Visual Studio Code, it looks for required assets and asks you if it should import those. Click on Yes.

Like I said before, it’s the plugins that turn this code editor into a powerful IDE. I’ve jumped to the plugins tab, searched for and have grabbed the the following plugins I need to get started:

At this time if you were using Yeoman and had bower properly installed Your Launch.json should have the following value correctly set and you should be able to debug your application using debug tab and selecting “.NET Core Launch (Web)” from the debug type drop down and hitting the play button of the familiar F5 key:

If you started with .NET CLI tools (instead of Yeoman), you may not automatically get all bower dependencies configured in your bower.json file like Bootstrap and JQuery. So when you run the project with “dotnet run” it runs fine but when you Debug using Visual Studio Code so see things like Bootstrap and JQuery aren’t properly imported and you see your application looks like this (and the Javascript functions inside the application don’t work either):

This is where is pays to understand how Bower really works and how these templates are generated. The reason why your application runs fine when you execute it using “Dotnet Run” and doesn’t when you execute it using Visual Studio Code is that both (Dotnet Run / Visual Studio Code debugging) execute the applications in different modes. While “DotNet Run” executes the application in production mode, Visual Studio Code runs it in debug / development mode.

If you open your _layout.cshtml file you would notice that the template has generated a layout file that picks up bootstrap, Jquery and other dependencies from “~/lib” folder for Development environment and directly from ASP Net live CDN in case of production and staging environments. Since we are running in Development environment when debugging from Visual Studio Code we need the dependencies to be present in the “~/lib” folder.

If you check the wwwroot folder however you’ll see that the lib folder is missing:

To get the dependencies in the right folder we’ll use Bower to download the dependencies in the right folder. Where bower downloads the dependencies is defined in “.bowerrc” file:

And as the above picture shows our .bowerrc file does have the right location. We also have the bower plugin installed. So Let’s hit CTRL + P and Type “> Bower” in the search bar  that pops up:

Now you get a list of bower commands from which you can select Bower Install and hit enter:

The moment you do bower should grab all required dependencies for you and you should now see a new lib folder with the right dependencies:

And you are also able to debug the application properly now with Bootstrap, Javascript and other dependencies working fine:

Personally, I like Yeoman primarily because it provides a larger choice of templates and runs the “bower install” command pretty much automatically (assuming you have bower installed) but both .NET Core CLI and Yeoman should help you get started quickly with your first ASP.NET Core application. Both work across platforms and which one (Dotnet CLI / Yeoman) you use is just a matter of which templates you prefer.

As far a Visual Studio Code is concerned I love it. While Visual Studio 2015 Professional versions manage some of these tasks out of the box, Visual Studio Code is really nice because for me it hits the fine spot between showing me what’s happening under the hood at the same time keeping me sufficiently productive. This post covers two ways of getting up and running with an ASP.NET core project and you can use either of the two and all it takes us is a minute to get started with the setup and debugging on a new ASP.NET core project using Visual Studio Code.

In the next post we’ll get started with the actual application using ASP.NET Core where we will be creating a simple application where you can store experts from various books and research papers that you might be reading for future reference. As the series of posts proceeds I’ll dump the code on GitHub and also try and host it using the cheapest most scalable cloud options.

posted on Tuesday, 10 January 2017 13:52:02 UTC by Rajiv Popat  #    Comments [0] Trackback
Posted on: Sunday, 06 June 2010 by Rajiv Popat

I love writing on this blog. For me this blog is more of an opportunity to stand back, evaluate the experiences of my life and write about these, by adding a little bit of myself to this blog. The very fact that I post multiple times a week, turns this blog into something which allows me to exercise my writing skills and develop my writing mussels.

Having said that, this post has developed a very different audience than what I initially expected. Besides programmers, this blog is read by managers, business folks and even my mom. One of the thing that I try to pay special attention to, while writing, is the timelessness of each post.

I try to add content here which usually does not tend to become obsolete when the next version of visual studio comes out. Of course, there are one or two  exceptions, but then, most of it happens to be timeless. At-least I try to make it timeless to the best of my ability, even though when I read my older posts, I do realize how much I sucked.

Because this blog is read my more than one reader, it often means that I end up spending a lot of time adding graphics, hyper linking, formatting and proof reading all content that goes out here.

To be honest, I love doing all of that.

A huge part of my life includes working with other human beings and that is what this blog is all about.

But then, there is another part of my life. A different persona, so to say. One that deals with bytes. One that likes to fiddle with technology, explain design patterns using wild examples and whacky home made philosophies and the one that likes to tinker with the code-base of crux in my free time.

Unlike most software developers, I have been fairly open about my experiences with other developers or what I learn from these experiences but then unlike most developers who write blogs, my close encounters with code and technology often remain undocumented.

The idea is not new however. I have been thinking about this for a long time. The whole concept of learning like a teacher and teaching like a student is something that I have talked about before on this blog.

I think it is time when I can introduce a different part of my personality on a different blog all-together.

People, here is presenting, my code-persona.

Think of code persona as my personal little wall to scribble things on as I work. Just bought a new cam-coder, you might read a review that I slapped together rather quickly there. If I just learnt a neat way to solve a programming problem, you might read it on code persona. The posts on code persona might not be as well formatted or as minutely proof read as this blog, but that's the whole point. Like I said, its my personal little wall.

So What Happens To This Blog?

Nothing. It continues. Just as before.

I am not stopping to write on this blog.

This blog will continue to have posts added to it, just like before.

So if you like the kind of content that you read here, you will continue to find more of it. But if you are a hardcore programmer and you are more interested in curly brackets and semi-colons, code-persona is the blog you also want to subscribe to.

It's been quite some time since I did some serious hardcore technical blogging.

I feel like a little child again and that, I believe is a really good thing.

Feel free to hang out with us on code-persona.

More content will start getting added there soon.

Wish me good luck.

posted on Sunday, 06 June 2010 20:30:00 UTC by Rajiv Popat  #    Comments [0] Trackback
Posted on: Saturday, 03 October 2009 by Rajiv Popat

My Gripes With Technical Writing.

My previous blog was all about technical writing. As a young and budding developer; some of the posts out there were aimed at talking about the latest cutting edge technology; flexing my engineering mussel and getting more traffic out of Google.

As I wrote the posts however; I realized that; unless you are talking about the products you are yourself involved in; technical writing is harder than any other forms of writing.

Unless you genuinely believe in the craft of story-telling; the life-cycle of writing a technical post pretty much goes like this: You take a topic; you dissect it; you understand everything there is too understand about it and then you try to pass that understanding over to your readers. It was almost like taking a traditional approach to teaching.

After a while; I realized that there was one word that describes this entire process: Boring.

Don't get me wrong; dear reader. The mere act of writing code or reading it isn't boring. It gets you in the flow and does amazing things to your life. Having said that; the very process of writing about code; or reading about it; is in fact very boring; and there are multiple reasons; dear reader; why this is the case.

I'm going to make a humble attempt at touching some of these reasons and try to figure out why most technical articles or books out there are unable to keep my attention span end-to-end.

Ready?

Let's get started with my gripes on technical writing.

Technical Writing is Based On Facts.

Let's face it; the way most technical writers of today write; Dependency Injection is basically --- dependency injection. That's where most technical writers of today start and stop. Take the Wikipedia definition of dependency injection; for instance. Here is how it goes:

Dependency injection (DI) in computer programming refers to the process of supplying an external dependency to a software component. It is a specific form of inversion of control where the concern being inverted is the process of obtaining the needed dependency. The term was first coined by Martin Fowler to more clearly describe the mechanism.

The very first sentence is a turn off. By the time you near the end of the article; you can hear yourself snoring out loud.

It isn't Wikipedia's fault though.

What Wikipedia is doing; dear reader; is capturing facts and presenting them to you. This is what most other technical writers writing technical books seem to be doing. Most of them; seem to base their books or their writing around facts; and the inherent problem with this approach; dear reader; is that facts; are boring.

Lack Of Spice And Information Surrounding The Content.

Pick a few basic books on neuroscience and they will tell you a great deal about how our brain stores and interacts with information. Neuroscientists; around the world; up-till the recent times believed that information in the human brain is stored in a central location and that lesser the information the easier it is to commit and recall.

Recent opinions however; seem to suggest that information in the human brain is basically stored all over the place; and the human brain uses the 'context' to get you a faster recall. Long story short; dear reader; spice and some amount of irrelevant information; connected with the fact is just as important as the fact itself.

I first understood the importance of this brain-rule during my French-classes.

To illustrate my point; dear reader - I am going to teach you some French.

Ready?

The French word for 'who' is 'qui' - I want you to commit this to your memory - get on with your life and do a recall a couple of months later.

Now; if you are like most of us; chances are that a couple of months later; as you move on with your life you are going to forget this piece of information all-together.

Now; do this - turn the literal fact - "who in English equals qui in French" - into a tiny little sentence with some useless information and some context.

Put simply; just try and remember the English sentence - 'who has the key'.

Now; given that the pronunciation of key and qui are exactly the same; months later; when I ask you the French translation of 'who' - chances are; that you will not just remember the French translation; but you might actually have a faster recall.

Ok; back to technical books on programming. The problem with most technical books today; is that they lack this additional spice and information that is supposed to make it easier for people to remember the facts that the book is presenting.

When it comes to technical writing and reading about code; less is not more. In fact; neuroscientists around the world will tell you that when it comes to storing information about a fact; the more random connected information you have about the fact; the higher your chances of remembering that fact are.

Now; look around. Take a look at all the technical books you have. Also take a look at all the technical blogs that you can find online. How many of them give you this additional information connected with the facts they present? How many of them provide you with additional; hugely interesting information that helps you commit and recall the stuff; faster?

Thought so.

This Thing Is Supposed Be Fun.

I've known some amazing fun loving authors and have had the pleasure with observing them or even remotely working with them. These are seriously fun loving guys who can take a concept and drill it into your head by the time you are done with your lunch with them.

However; when they indulge in the act of technical writing; you somehow seem to get a sense that you are reading a completely different individual all together. Pick their books and you will realize that the sense of humor is gone; the jokes are gone; the funny analogies are gone.

What remains is a me-too book or a me-too programming blog on C# or Ruby On Rails that other C# or Ruby On Rails programmers go to.

Over years; our technical writers and authors around the world seem to have nurtured the thought that a technical book ought to be something 'serious' and 'professional' and therefore it is completely inappropriate to go out and experiment when you are writing a technical book or a technical blog-post. That dear reader; makes most technical books and blogs out there nothing more than material that you reference when you are stuck with a problem.

When was the last time you picked up a book on Design Patterns and had 'fun' reading it?

When was the last time you giggled while reading a book on C# programming?

When was the last time you had a deep realization that triggered a chain of thoughts while reading the explanation behind a code-snippet?

Technical Writing Lacks Persona.

Every book; be it a novel; or book about software development; reflects the author's personality. Most technical books out there however; don't.

We have seen the use of F-word; in books and blogs that are connected to software development.

We have seen management books use words like Asshole.

We have seen books on organizations and entrepreneurship which move and inspire.

The idea is not just to grab the attention of readers with purple-cow words; but to leave a little bit of your daily-persona into the book when you are writing it.

While it is true that no-one cares about you or your product; it is also true that there is a little bit of you in everything that you do and that little-bit-of-you makes everything you do different. Most technical writers however; seem to miss out on putting in a little bit of their personality into their technical writing.

We are Taking It Way Too Seriously.

There are over two hundred blogs that I subscribe too. The ones I love the most are blogs where authors take chances; post something that is wrong; learn from their comments and then go out there and change with time.

While the whole idea that authorship does not mean authority seems like a well known fact in blogs that do not talk about code; the ones that do; still seem to be a little hesitant at being opinionated; passing on their own thoughts and insights about the code they are explaining and making blatant mistakes while they do that.

As a matter of fact; most authors seem to take the easy-safe-boring way out; which is to eliminate this information all together.

As authors and programmers are we taking what we write or read; way too seriously?

Are we missing out on all the fun connected with making mistakes and learning from these mistakes?

After all; there is something to be said about learning with a mind of a child.

As I slowly start nearing the end of my first book and as I find more time to fly-free; every 'once-in-a-while'; I plan on working on an article or two that touches code; programming techniques and even design approaches; to see if I can add a little bit of myself to my technical writing.

The idea; dear reader; is to introduce you to my very own personal code persona that has it's very own approach to dissecting and trying to understand code; programming techniques; and information pertaining to improving your programming skills that is freely available out there.

Maybe; I'll make a fool of myself; maybe the articles will not be 'technical enough' for a few hardcore programmers out there. Maybe they may not fetch me all the Google traffic that my older blog used to fetch me; but I am going to go ahead and give it an honest shot anyways.

If you are a programmer at heart; you should too.

Go add a little bit of spice; fun and yourself to every seriously technical post that you are about to publish on your blog.

I dare you.

Small aside: If there is a book or technical blog out there that you know of; which goes deep into programming; code and design in a way that is fun; if you know a book or a technical blog that has an interesting persona of its own; I would love to read it. If its a blog I would love to subscribe to it. Go ahead; drop me a comment; or send me an email.

posted on Saturday, 03 October 2009 22:09:53 UTC by Rajiv Popat  #    Comments [0] Trackback