Should you Fire a Coworker for Making an Honest Mistake?

A while back my hairdresser accidentally cut my ear. It was just a small cut and I hardly felt it but since cuts in ears have a tendency to bleed a lot my hairdresser felt really bad and almost starting crying.

After having driven home with one hand on the steering wheel and the other hand holding a towel to my ear (it’s hard to drive a stick that way), why wife went into conniptions and while she tried stopping the bleeding she demanded that I find a new hairdresser.

“Why would I do that?”, I asked.

“Well, obviously this one is highly incompetent. And she even made you pay 100 DKK for this mess”.

I said: “I am not going to find a new hairdresser. I just invested 100 DKK to be absolutely sure that this hairdresser will never cut my ear again.”

So far I have been right. The nice little scar on my ear reminds my hairdresser to be extra careful and thorough :-).


Once in a while you read about developers being fired for making honest although massive bugs. The question is: Is it the right thing to fire people?

Personally, I think it is the wrong thing to do. Making an honest mistake is not enough to get you fired.

But it all depends on how you handle that mistake. If the person who made the mistake steps up to the plate, takes responsibility and does everything he or she can to fix it and learn from it, then you as a company will not get a better co-worker by firing and hiring somebody else. The new guy might even make the same mistake. It’s also very likely that the mistake happened because the processes in your company are not good enough.

What do you think is the right thing to do?

Some Advice for Beginners

If you are new at programming, here is some sane advice for you.

The list is built from my own experience since we are all newbies at something, right?

The list could be a lot longer but I have picked 7 important pieces of advice that recently have had some relevance for me while mentoring.

1. Have Fun!

Yes, that’s right. This is the first and most important piece of advice. Coding is supposed to be fun. If you are not having fun, maybe coding is not for you 🙂

2. Use Existing Guide Lines

You may be a beginner and you may be in over your head but the sooner you start using existing guide lines such as naming standards and best practices, the sooner your coding skills will take off. Your company may have existing coding standards (they should) and they are there for a reason. Following guide lines and standards will help you and your mentor better understand the code.

Also, your code will probably not pass code review without following existing standards and it is a real pain to fix it all later.

3. Your Code is not a Special Case

I am sorry I have to break this to you but your code is in no way ground breaking or requires special treatment. That means you do not get to use gotos liberally, use inheritance like the world has never seen before, or put all 3,000 lines of your program in the same file.

Everybody else can do without strange constructs and so can you.

4. Read the Error Messages

If the compiler refuses to compile your code, then by all means read the errors messages. They may be cryptic but you might as well get used to them because it won’t be the first time you see them.

Runtime errors can be hard to figure out but the next item on this list may help you with that.

5. Debug Everything

Debugging is really, really, really important. Someone once gave me the advice to always debug through your code. So this piece of advice applies to everybody, not just beginners.

Debugging will help your understand how your code is working. Whenever I write a piece of code I step through it with the debugger, even though it appears to be working. A good way of doing this is to debug through your unit tests.

So, learn how to debug in the programming environment that you are starting to learn. Did I mention that it is important?

6. The Error is Most Likely in Your Code

If your code fails (and it will) it is like 99.99 percent certain that you are the one who introduced a bug. The bug is not in the programming language or in the platform. It is in your code!

So it you think that .NET cannot save files larger that 50 lines or that C# is slow at simple math operations, then you are wrong.

The bug is in your code!

7. Stop Excusing

Everybody seems to make excuses for their code. There is no reason to. Your code has bugs and it could be designed better but I am yet to meet a programmer who writes perfect code. If your mentor ridicules your code, you need to find a better mentor (yes, we are all guilty of laughing at some poor guy’s code).

That’s it. I hope it will make your journey into coding a tad easier.

Deploying ASP.NET Core Applications from Bitbucket to Azure

Give the most tedioust jobs to your laziest employee and they will automate it.
My boss

That’s right. I am lazy. I hate repetitive tasks. And as a developer you probably feel the same way.

One of those repetitive tasks is deployment

There are numerous ways and frameworks to set up automated builds and deployments. Some of them can do just about anything almost up to the point where they will make you coffee while you wait for your builds.

Recently while working on a small ASP.NET Core website I found out that Microsoft Azure has a very simple deployment tool for building and deploying from your favourite code repository to an Azure web application. I was especially happy to find that it supports BitBucket even though it seems anything not-on-Github is not cool.

Well, I am too old to be cool and I like Bitbucket so bear with me.

Setup

Setup is a breeze. Got to the new Azure portal and create your new web application.

After the web app has been created, go to your web app and choose “Deployment Options”.

azure-deployment-options

The next steps allow you to log in to your source code provider (i.e. Bitbucket) and choose project and branch (typically the master branch). The beauty here is that Azure supports pulling code from all kinds of sources like Dropbox, Onedrive, Github, and of course Bitbucket.

azure-deployment-options-configure

After you save your settings, Azure will fetch your last commit and start building it. You can se the progress by clicking “Deployment options” again.

azure-deployment-progress

Build Errors?

It looks like Microsoft has just recently upgraded the compiler but I have previously run into problems with building newer C# features such as inline declaration of variables like so.

var salaries = new Dictionary<string, decimal>()
{
    { "Jakob", 10000000000 },
    { "Some other guy", 42 },
};

// Inlining variable declaration
if (salaries.TryGetValue("Jakob", out var salary))
{
    // Do something with salary.
}

If you run into this problem, all you need to do is add the Nuget package Microsoft.Net.Compilers to your project. This will make sure that your project is compiled with the latest C# compiler.

Conclusion

This kind of deployment is extremely simple and easy, which is a good thing. On the other hand it will not run any unit tests in your project and it will deploy straight to production without any testing or staging. You might consider this solution for smaller, non-mission-critical sites.

Creating Your Own Visual Studio Project Template

All code on Github.

In previous articles (1 and 2) I walked through how to add Webpack and Typescript to a Visual Studio ASP.NET Core MVC project.

It turned out to be quite a cumbersome and error prone process and it is not something you wish for your worst enemy to go through twice (or maybe you do – I don’t know).

Luckily, it is quite easy to create your own project templates for Visual Studio so that you can repeatedly create new projects with the same setup.

As you probably know, you can create new projects for Visual Studio by using the dotnet new command. For example you can create a new ASP.NET Core MVC project by running

dotnet new mvc -n "MyFacebookKillerApp"

Type dotnew new to list all available templates.

Wouldn’t it be nice if we could do the same thing for our ASP.NET MVC with Webpack and Typescript thingy project? Fortunately, we can (otherwise this would be a very uinteresting article).

First step is to configure our template.

Configuring the Template

Start by creating a folder named “.template.config” at the root folder of your solution. This is typically where the .sln file is sitting.

Create a file named “template.json” inside the “.template.config” folder. Insert the following into the file and change the relevant properties (such as author, identity, shortName, and sourceName):

{
  "author": "Jakob Christensen", 
  "classifications": [ "Web" ],
  "name": "ASP.NET MVC Core with Knockout/Webpack/TypeScript",
  "identity": "t4rzsan.MvcKnockoutTypeScript", // Unique name for this template
  "shortName": "mvcknockouttypescript", // Short name that can be used on the CLI
  "tags": {
    "language": "C#"
  },
  "sourceName": "CoreWebApplication2", // Will replace the string 'CoreWebApplication2' with the value provided via -n.
  "preferNameDirectory": true,
  "exclude": [ "**/[Bb]in/**", "**/[Oo]bj/**", ".template.config/**/*", "**/*.filelist", "**/*.user", "**/*.lock.json", "**/node_modules/**/*" ]
}

Choose something brief but meaningful for “shortName”. This is the name that you will use when running the dotnet new command.

The property “sourceName” is important. When the template runs, the string “CoreWebApplication2” will be replaced by whatever the user specifies for the -n(ame) parameter for dotnet new. The text will be replaced in all files. That includes namespaces in .cs files and renaming of .csproj files. So you must change “CoreWebApplication2” to whatever you used as project name for the solution, you are using as template for your template (if you know what I mean).

I have set “preferNameDirectory” to true which means that dotnet new will use the name of the current folder as project name if -n has not been specified.

When you are done with the configuration it is time to register the template.

Registering the Template

You install the template by running the command dotnet new --install [folder] where [folder] is the path to the parent folder of “.template.config”. So, for me that would be

dotnet new --install C:\Users\Jakob\Source\Repos\CoreWebApplication2

When listing the installed templates you will we your own short name in the list:

dotnetnewinstall

Finally, let’s see if it works.

Using the Template

Create a new folder somewhere for your new project and CD your way to the folder in the command prompt. Start by typing (insert your own short template name):

dotnet new mvcknockouttypescript

That’s it. Very cool!

By the way, Don’t forget to update npm and install all dependencies for the new project.

npm update npm@latest -g
npm install
npm run build

Working Effectively with Windows as a (non-)Developer

There are lots of great articles on how to know your tools to be a better programmer. I thought I’d chip in give and give 10 tricks on how to be a good Windows user and hence also a better developer. These tricks are very simple and have been part of Windows for a while (some even before Windows 10) and yet they are unknown to many Windows users.

There has always been an ongoing war on whether macOS or Windows is the better. I am a user of both and I love and hate both of them (although I am more effective on Windows). I hope the following tricks can be of help to Mac users who sometimes need to use Windows, and also of help to existing Windows users who perhaps can learn a new trick or two.

I would be happy to hear about what tricks you use to make life easier so please join in on the comments.

These tricks all apply to Windows 10.

1. Show file extensions in Explorer

For some reason the default setting in Windows is to hide all known file extensions.

There should be a law against that.

So, the first and most important trick is to get Windows to show all known file extensions in Windows File Explorer.

For example, I had a client that stubbornly claimed that double-clicking the MyApp.exe file would only show some gibberish in Notepad. After a while it occurred to me that the standard .NET configuration file MyApp.exe.config file showed as MyApp.exe on the client’s machine because the file extension .exe was hidden.

So, the first thing you do on a new Windows box is to open Explorer, click Options -> Change folder and search options. Go to the View tab and clear the check box for “Hide extensions for known folder options”.

2. Use the Run command

The second most important trick is the “Run” command in Windows. Mac has its very useful Spotlight Search, and Windows has its equally useful Search feature in the Start menu, but I find the Run command much more useful.

The Run command allows you to run one-line command line instructions. You get to the Run command by typing Windows+R on the keyboard. That will open up a small dialog to the lower left where you can type any command.

The Run command gives you a very fast way to start apps or open web pages. The following are a few common examples:

  • calc (starts Calculator)
  • notepad (starts Notepad)
  • excel (starts Excel)
  • winword (starts Word)
  • mstsc (starts remote desktop terminal)
  • inetmgr (starts the IIS Manager)
  • cmd /f:on (starts a command prompt with tab completion)
  • www.dev.to (opens the default browser and goes to dev.to)
  • http://dev.to (same as above)
  • %programfiles% (opens Explorer and goes to the program files folder, usually C:\Program Files)
  • control panel (opens the Control Panel)
  • services.msc (opens the services panel)

3. Use Windows Search

I already mentioned it above, and I will mention it again. Few people realize that Windows has built-in search similar to Mac’s Spotlight search.

Just press the Windows button on the keyboard to open the start menu and start typing immediately. This will search for apps and files and the search results show immediately on the start menu. It evens searches tags in images and content in pdf files.

I actually never understood the hatred for Windows 8 and 8.1 and the large start menu. To me it was just a big friendly searchable start screen. But I guess I was the only person in the world that liked it.

Unfortunately, Windows Search does not search the internet.

4. Use the Power menu

The power menu is shown when you press Windows+X on the keyboard. The power menu gives you immediate access to the most important stuff such as settings, event viewer, network connections, and the command prompt.

Speaking of the command prompt, if you prefer to use PowerShell, you can replace the command prompt with PowerShell on the power menu. Right-click your taskbar and choose taskbar settings. Then turn on the setting “Replace Command Prompt with Windows PowerShell in the menu when I right-click the start button or press Windows-key+X” (now that’s a long sentence).

5. Easily start new instances of an app

As you know you can start an app by clicking its icon on the taskbar.

Now, if you want to start more instances of the same app, you hold left-Shift and click the icon.

And if you want to start an app as administrator, you hold left-Ctrl and left-Shift and click the icon.

You should pin command prompt and PowerShell to the taskbar so that you can start and administrator prompt just by left-ctrl + left-shift + clicking it.

You can also start an app that has been pinned to the taskbar simply by holding the Windows key and pressing the number for the app. So, for example, Edge is the third app om my taskbar, so I can start it simply by pressing Windows+3 on my keyboard.


(I apologize for my hopeless, childish handwriting)

6. Use the Snipping Tool

This tool is very helpful for capturing screen shots and I use it all the time, for example for writing blogs. Just search for “Snipping” in your start menu to use it.

You may find difficulties in snipping a screen shot of menus and such but of course I have a trick for that:

  1. Start the Snipping Tool and click New.
  2. Press the Esc button on your keyboard.
  3. Open whatever menu you wish to capture.
  4. Press Ctrl+Print Screen on your keyboard.
  5. Now you can draw a rectangle of with the Snipping Tool to capture the menu.

7. Copy the path of a file

Left-shift and right-click a file to reveal a number of extra items on the context menu. One of them is “Copy as path” which will copy the file’s full path to your clipboard. Neat.

8. Use shortcuts

Some common shortcuts:

  • Windows+E: Start File Explorer
  • Windows+D: Show the desktop
  • Windows+I: Open settings
  • Windows+Ctrl+D: Create new virtual desktop
  • Windows+Ctrl+right arrow: Go to next virtual desktop
  • Windows+Ctrl+left arrow: Go to previous virtual desktop
  • Windows+Ctrl+F4: Close current virtual desktop
  • Windows+arrow up: Maximize window
  • Windows+arrow down: Minimize window
  • Windows+arrow left or arrow right: Snap window to the left or right border

By the way, if you grab a window by the title bar and shake it with the mouse, all other windows on the desktop will be minimized.

9. Keep your Windows desktop clean

With Windows search and the run command, who needs icons on the desktop?

Add shortcuts to the taskbar for the apps that you use the most for easy access and leave the desktop clean and uncluttered.

10. Easily create connection strings

The last trick for now is for developers. I find it incredibly useful and I have not met a single person who knows about it since I learned it many years ago. So I decided to include it here as a small bonus for those who made it this far.

I can never remember the syntax or the property names for connection strings when connecting to a database from code on Windows which is why this trick has helped me for years. A long time ago at a conference (in Boston I believe) I saw the presenter creating a file on his desktop with the extension .udl. Then he double-clicked the file which opened a small dialog where he entered SQL Server instance name and selected authentication and database name.

After dismissing the dialog he opened Notepad (by pressing Windows+R and entering “notepad”) and he then dragged the .udl file to Notepad, revealing a beautiful connection string. How about that!

By the way, the .udl trick won’t work unless you have followed the very first trick on this list: “Show file extensions in Explorer”.

I hope you find above useful 😀

Which is better for teaching? C# or F#

Recently I have had the pleasure of training a couple of colleagues in the wonders of programming. At work we use C# for most of our applications so naturally I started preparing my material in C#.

I did not get very far before it occurred to me: This is going to be a long haul…

Now, my colleagues are smart, really smart, much smarter than me, but they do not have much experience in programming. They have been using SQL, some VBA, and perhaps a bit of R, but none of them have been doing real application development and they know nothing about OO theory.

Unfortunately, you do not get very far with a language such as C# without knowing just a little bit about OO programming.

Let’s start with the compulsory and useless “Hello, world” example:

using System;

namespace ConsoleApp
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Hello, world");
        }
    }
}

That’s a lot of code just to print out a stupid message on the screen.

“What are all those things for?” my colleague complains and I answer “We’ll get to namespaces, classes, static, void, arrays, and more stuff later”. He’s not happy and continues “Do I really need to write all those curly braces and semicolons?”. And when I tell him yes, and don’t forget that it’s all case sensitive, he breaks down and says “I miss VBA…”.

Of course curly brackets and case sensitivity has nothing to do with OO but I think we can all agree that OO is really, really hard. Heck, I don’t even master it after years of C++ and C#.

I find that it takes a long time for beginners to grasp OO and when they start to see the light they will abuse inheritance and create everything as singletons. And interfaces seem to be impossible to understand even though I do my best with lousy metafors such as cars and DVD playsers.

Usually, beginners actually tend to completely ignore that C# is object oriented and they take a straight forward approach and create a very long Main function.

So, perhaps teaching my colleagues C# is not the right approach. Perhaps I should try teaching them a functional language instead such as F#? Now, I am not saying that functional languages are easy but I do think that you can get really far with F# without knowing advanced stuff such as monads. In F# the “Hello, world” example boils down to

printfn "Hello, world"

Very simple. Not much to talk about.

Besides, there are a couple of important points to consider when bringing F# to the table:

  • My colleagues are all mathematicians and functional languages are perfect for math stuff.
  • F# is a .NET language and will work together with all the C# code in our company.
  • F# can work as a scripting language for makeshift assignments.

I am thinking that it would suffice to teach the basics of F# such as record types, functions, pattern matching, the Seq module, type providers, and perhaps partial application.

What do you think? Would F# be easier to grasp or should I go for the usual C#?

Changing Work Item Templates on Team Foundation Service

Introduction
If there is one thing that Team Foundation Service (TFS) does really well, it is the use of work items.  A work item can be a lot of different things.  For example, it can be a bug, a task, a user story, an epic, or a test case. It can even be a request for a code review.

You can define relations and dependencies between work items and you can assign work items to changesets (commits).  The possibilities seem endless.

The work items available to you are decided by the template that your admin chooses for you when she creates a so-called team project.

image

At work we have been using TFS since the dinosaurs walked the earth.  Back then TFS was a whole lot different than it is today which means that the templates looked a lot different.  For example, the template used for the team project we are using on my team is based on some old Microsoft Foundation framework which only allows bugs and tasks.  I does not allow us to create cool things like user stories or code review requests.

So I decided to upgrade the templates.  There is not built-in way to upgrade so you have to do it manually. I am no TFS expert but I found out that the process is: 

  1. Export the work item templates from TFS.
  2. Edit the templates if necessary.
  3. Import the templates to TFS.

Sounds easy, right?  Well, it’s not hard but it is kind of cumbersome.

Changing the work item templates is only possible on on-premise TFS. Don’t try this on Visual Studio Team Services (at visualstudio.com).

Exporting Templates

Work item templates (WITs) are defined as XML-files so first you want to export the XML-files that you want to use from TFS.  The export is done through Visual Studio and the tricky part is that you need to do it from a Visual Studio version that corresponds to your TFS version.  So, in my case we are on TFS 2015 so I need to do the export from Visual Studio 2015.

To export the WITs go to the menu Team –> Team Project Collection Settings –> Process Template Manager.  Here you need to decide which template you wish to upgrade to. If you want to upgrade to the “Agile” template, then that is the one you should download.

image

Click the “Download” button to download the XML-files.

If you chose to download the “Agile” process template, the files will be placed in a subfolder called “Agile”.  The interesting files for WITs are located under “Agile\WorkItem Tracking”.

If you take a look at the files in the folder “Agile\WorkItem Tracking\TypeDefinitions” you will see that there is an XML-file for each work item type, for example Bug, UserStory, Task, TestCase, CodePreviewRequest.  The files define the fields and states for the work items. These are the files that you need to import to our legacy team project to upgrade it to a newer process template.

For the import you need to use the witadmin.exe tool from the command prompt.  You have to use witadmin.exe for the right version of Visual Studio and TFS.  For Visual Studio 2015 and TFS 2015, witadmin.exe is located at

%programfiles(x86)%\Microsoft Visual Studio 14.0\Common7\IDE

So let’s start importing the work item templates. Unfortunately, I have been unable to find a way to batch import all the files in one shot so you have to do it one file at a time.

witadmin importwitd /collection:"http://mytfsserver/tfs/MyCollection" /p:"MyTeamProject" /f:"C:\downloadedtemplates\Agile\WorkItem Tracking\TypeDefinitions\Bug.xml"
witadmin importwitd /collection:"http://mytfsserver/tfs/MyCollection" /p:"MyTeamProject" /f:"C:\downloadedtemplates\Agile\WorkItem Tracking\TypeDefinitions\CodeReviewRequest.xml"
witadmin importwitd /collection:"http://mytfsserver/tfs/MyCollection" /p:"MyTeamProject" /f:"C:\downloadedtemplates\Agile\WorkItem Tracking\TypeDefinitions\CodeReviewResponse.xml"
...

You may encounter errors when trying to import. I ran into a number of renaming errors:

TF26177: The field Microsoft.VSTS.Common.BusinessValue cannot be renamed from '
Business Value - Microsoft Visual Studio Scrum 1_0' to 'Business Value'.

If fixed the errors by manually editing the XML-files. In the above case I searched for “Business Value” in the XML-file that failed and changed it to “Business Value – Microsoft Visual Studio Scrum 1_0”. It didn’t seem to matter anywhere in TFS after the import.

After all the WITs have been imported (without errors!) the final step is to import the categories. For example, the file categories.xml define which work items can be created directly by the user in TFS, and which work items are hidden, such as code preview requests that are created indirectly through code review requests in Visual Studio.

witadmin importcategories /collection:"http://mytfsserver/tfs/MyCollection" /p:"MyTeamProject" /f:"C:\downloadedtemplates\Agile\WorkItem Tracking\Categories.xml"

And that’s it! Now you should be able to create all the fancy Agile work items from within TFS, and you should be able to request code reviews from Visual Studio.

Building C# 7.0 on On Premise TFS

At work we are running on premise Team Foundation Service 2015 (yeah, I know, right?).

We have been struggling a bit to build C# 7.0 code on it.

We installed Visual Studio 2017 on the build machine but it seemed that no matter what we did, we were only able to choose between “Visual Studio 2015” and “Visual Studio “15” Preview” in the build step. As you may know, the latter is a preview for Visual Studio 2017 and it just did not do the job for us.

The solution is quite simple and it is a bit embarrassing that we did not find out faster.

It turns out that all you have to do is use an MSBuild step instead of af Visual Studio Build sted. Under the “Advanced” section, you put in the path for the latest msbuild.exe on your build machine.

If you put Visual Studio 2017 or even better, the Visual Studio 2017 build tools on your build machine, you should be able to find msbuild.exe in there somewhere.

msbuild
(screenshot is from https://www.visualstudio.com/ but you get the idea).

Be a responsible developer

The world is evolving around software. Software controls everything we do from toasting bread to sending people into space. Software enables people and companies. It is in fact really hard to think of a job or a task that does not include software in some way, at least in the Western hemisphere.

That puts us, the developers, in a special spot. We are the ones that make it all possible. It gives us great power and as you know, with great power comes great responsibility.

Not all software developers live up to that responsibility. The recent WannaCry ransomware attack is one such example where evil-minded software developers take advantage of laymen’s lack of knowledge when it comes to computers and software.

But we also need to be responsible developers on a smaller scale, when developing everyday software such as mobile phone apps and web sites for commercial and other purposes.

What do I mean by being a responsible developer? I mean that you need to be nice and respectful. Don’t be pushy and annoying. Don’t pretend that your app can do stuff that it cannot. Be helpful and serviceminded.

Just last week I downloaded an app to my iPhone from Apple App Store. The app was a calendar and todo-list for things you need to do around your house. On the first run it requested permission to show notifications which I allowed because – you know – it sort of makes sense to get notifications from a calendar/todo-list.

It did not take long before the app started acting up. Within an hour or two, the app popped up a notification with some kind of click-bait message, trying to lure me into opening the app.

I immediately uninstalled the app. The developer should be ashamed for being irresponsible and wasting everybodys time.

A couple of months ago my father bought a new laptop. Nothing fancy, just a laptop for checking emails and netbanking. The machine came with a bunch of unrelated, useless blotware that is only used for marketing stunts. My father is in his seventies. He has no idea what a computer does and he does not stand a chance against bloatware. Of course, I removed it all. Lenovo, I am looking at you. Start being responsible.

The list of examples goes on and on…

Some of the worst examples are social media. They will bug you and bother you in an endless stream of emails, toasts, badges and what-not until you cave in and open their app. Even after you have disabled all kinds of notifications they will email you just to make sure.

I know we are all under pressure form CEOs and CMOs that want to drive traffic to your apps and web sites but we, the developers, are the last line of defence, and we need to step up and create software that is useful and a joy to use. I believe that in the long run this will make your more money than being annoying.

Setting up ASP.NET Core in Visual Studio 2017 with npm, webpack, and TypeScript: Part II

Example code on Github.

This is the second part in my small series on ASP.NET Core and the coolest of the cool JavaScript libraries out there, except that they are probably already outdated by the time I finish writing this.

In part I we took a look on how to install npm and webpack into our ASP.NET Core project. In this part we will set up TypeScript. Visual Studio (VS) will compile TypeScript for you automatically but we will disable that feature and let webpack do the TypeScript build just for the fun of it.

Set up TypeScript
Start by installing TypeScript using npm (this is all described on in webpack’s documentation):

npm install --save-dev typescript ts-loader

Notice how package.json is updated with typescript and ts-loader. You may be wondering what ts-loader is. I know I was. It is a “TypeScript loader for webpack” which really does not say much but it is the thing that makes webpack take care of our TypeScript code.

While we are at it let’s install Knockout.js which we will use for building view models in TypeScript.

npm install --save-dev knockout @types/knockout

By using @types we tell npm to install the typings for Knockout as well. I tend to think of typings being to TypeScript what header-files are to C++. The typings go into the node_modules folder as everything else.

Next we need to create a configuration file for TypeScript. Right-click your project node in VS solution explorer and click “Add New Item”. Search for “json” in the templates dialog and choose “TypeScript JSON Configuration File”. The file must be name “tsconfig.json”. Change the contents so that it looks something like this:

{
  "compilerOptions": {
    "outDir": "./wwwroot/build/",
    "noImplicitAny": false,
    "noEmitOnError": true,
    "removeComments": false,
    "sourceMap": true,
    "target": "es5",
    "module": "commonjs",
    "moduleResolution": "node",
    "compileOnSave": true
  },
  "exclude": [
    "node_modules",
    "wwwroot"
  ]
}

Notice that I have told the TypeScript loader to put the generated .js files in the folder “wwwroot/build”, and that I have told it to resolve any 3rd party modules by using “node” (i.e. it will look in the “node_modules” folder).

Test TypeScript build
Let us test that we can build TypeScript files. By default VS will build what ever .ts files you add to the project. Start by creating af Scripts folder in your project next to the wwwroot folder. Add a TypeScript a file named “myviewmodel.ts” to the folder. We will create a Knockout view model class so start by importing Knockout to the .ts file by adding the following line at the top.

import * as ko from "knockout"

Note how VS IntelliSense kicks in as you type. Very cool. Above we set “modeResolution” to “node” so that the TypeScript loader knows to look in node_modules to find Knockout. Now lets add a view model with two observable fields using the Knockout TypeScript definitions. The last line applies the Knockout bindings to the view.

import * as ko from "knockout"

class MyViewModel {
    firstname: KnockoutObservable<string>;
    lastname: KnockoutObservable<string>;

    constructor(firstname: string, lastname: string) {
        this.firstname = ko.observable(firstname);
        this.lastname = ko.observable(lastname);
    }
}

ko.applyBindings(new MyViewModel("Jakob", "Christensen"));

Now if you build your project in VS, you will see a new folder underneath “wwwroot/build” with the compiled .js file.

Set up the webpack TypeScript load
Instead of letting VS do the TypeScript build we want webpack to do it and we already installed ts-loader to do it for us. Why would we want to do that now that VS can do it for us? I like to do it because I prefer to keep everything front-end-ish together. So, webpack does the build, the bundling, the code splitting, etc.

Now, add a file called webpack.config.js to your project at the project root. Paste the following into the file.

var path = require('path');

module.exports = {
    entry: {
        site: [
            './wwwroot/js/site.js', 
            './scripts/myviewmodel.ts']
    },
    output: {
        filename: 'bundle.js',
        path: path.resolve(__dirname, 'wwwroot/dist/')
    },
    module: {
        rules: [
            {
                test: /\.tsx?$/,
                loader: 'ts-loader',
                exclude: /node_modules/,
            },
        ]
    },
    resolve: {
        extensions: [".tsx", ".ts", ".js"]
    }
};

This configures webpack to compile the .ts files. It also instructs webpack to take the compiled .js file and bundle it together with some other site.js file that we might have in our project and put it all into a file called bundle.js places in “wwwroot/dist”. This is the file you want to reference in your HTML files. By the way, the compiled .js files will no longer end up in the “wwwroot/build” folder so you can delete that.

Webpack build
To build and bundle, first edit your package.json so that the build block looks like this.

  "scripts": {
    "build": "webpack"
  },

Then remove the line containing “compileOnSave” from tsconfig.json.

Finally, go to the cmd prompt and run the following npm command from your project folder.

npm run build

You should now see the file bundle.js in “wwwroot/dist”.

Of course you don’t want to go to the cmd prompt every time you have changed something in your .ts files, so we want VS to run the npm build. Fortunately, the ever-present Mads Kristensen has created a VS extension that does it for you. After installing the extension you can see the npm custom build task in Visual Studio’s Task Runner Explorer. Right-click “build” to tell VS to run the build task before or after your normal VS build.

This will add a line to the package.json file.

"-vs-binding":{"BeforeBuild":["build"]}

Cleaning up
As I said above, VS automatically picks up .ts files and builds. You don’t want that when using webpack. To disable the VS build, right-click your project in Solution Explorer and choose “Edit [your project name].csproj”. Add the following line under the <PropertyGroup> element.

<PropertyGroup>
    <!-- ... -->
    <TypeScriptCompileBlocked>true</TypeScriptCompileBlocked>
</PropertyGroup>

Also, you might want to remove bower.json and bundleconfig.json if present, as package.json and webpack.config.js replace them. As far as I know bundleconfig.json works with another Mads Kristensen extension to bundle .js files.

That’s it. Now it is up to you to take fully advantage of webpack for code splitting and uglifying and what not.