7 Features of C# 7.0 Worth Knowing | BinaryIntellect Knowledge Base

As you are aware of C# 7.0 and Visual Studio 2017 have been released. In this article I quickly take you through seven new features of the language that are worth knowing. I assume that you are familiar with C# 6.0 and hence I am not going into too much technical details of these features here. My aim is to quickly let you know of a few interesting features that can make your C# code more efficient and clear. Let’s get going.

Source: 7 Features of C# 7.0 Worth Knowing | BinaryIntellect Knowledge Base

Auto versioning SharePoint Apps (and Sandbox Solutions)


spav  is a simple tool which can be used to automatically version SharePoint App packages and SandBox solution packages. You can provide custom app versioning library to provide your own mechanism to build app or WSP. It also can be used to generate application version JavaScript file which can later used to inject into pages and use in client side.


This a project which I created to automate the versioning of SharePoint hosted app. Initially it started as small tool, but in order to make it usable to other developers, I have added few modifications to it.

First I will explain the reason I created this tool in the first place. Recently I was involved in development of SharePoint app which had rapid development cycle. Client was expecting fast builds which deployed in SharePoint Online site. Client used his app catalog to publish the developed application across multiple sites. First version of the application published in multiple sites without any issue, but when we had to release next version of the app, we faced few problems.

  1. Versioning of the app package
  2. Update exiting content published by app -> Solution feature versioning

In order to update an application which published via app catalog, next version must have version upgrade. It can be major, minor or even patch level update, whichever it is, it must be reflected on Version property in AppManifest.xml file. If we do not change version in this file, site collection administrators will not see an app update in Site Contents.

Even if we update app version in AppManifest.xml file, it will not update the content we added in the app if we do not version application features properly. You can read more about versioning features in this blog post. As you can see, update content of the an app not easy as we think, and it all depends on feature version.

In this version of the application, my target was very simple. I wanted to maintain same version throughout the application as well as all features. In this way, when I add or update a file in a module, it’ll automatically get replaced.


spav  is a simple tool which can be used to automatically version SharePoint App packages and SandBox solution packages. It also can be used to generate application version JavaScript file which can later used to inject into pages and use in client side.


In order to use this tool inside Visual Studio, you have to add pre or post deployment step to SharePoint add-in project. Whether to use pre-deployement or post-deployment is up to your requirement.

-p, --path  [Required] Directory of application project. Can be taken from $(ProjectDir) MSBUILD parameter.

-m, --mode  [Required] Running mode.

  • AppPackage: Increases the version of application package(.app)
  • Wsp: Build a sandbox compatible package with feature versioning
  • AppPackageAndWsp: Update app package and create sandbox solution

-b, --build-config  (Default: Debug) Application build configuration. Can be taken from $(Configuration) MSBUILD paramater.

-j, --build-js  (Default: False) Build JavaScript file to use in versioning for client side versioning. This will work with parameters –js-path and –js-class.

--js-path  (Default: {Path}\applicationVersion.js) Save path for JavaScript file.

--js-class  (Default: appVersion) JavaScript namespace to contain application version.

--versioning-lib  (Default: AutoIncrementBuildVersion.dll) Library used to get build version.

--versioning-class  (Default: SharePointAppAutoVersioning.AutoIncrementBuildVersion.VersionProvider) Full path of class in versioning library.

--help  Display help screen.


Auto increment patch and build version of the SharePoint App package

Generate SandBox compatible solution with feature updates

Update app package version and generate SandBox solution

Build JavaScript file which can be used inside the application while updating version of app package

This will generate below JS file.

NOTE: Application will use 5 commented lines which is on top of JavaScript file to generate the next version. If you erase these lines, version will be resetted to If you want to change major or minor version, you can change it in here and it’ll be reflected it next build.

You can access version values as below,

Use custom versioning library

You can write your own custom versioning library for your versioning purposes. In order to do that, you have to create new class library and add reference to SharePointAppAutoVersioning.Shared.dll  file which you can find in application folder.

Lets assume that dll from your project is ContosoApp.CustomBuildVersion.dll . In order to use this inside the application, you have to copy this file to location of spav.exe  path. After you copy it, you can use it like below.

I will explain in another post about tools and libraries which I used to develop this application. Meanwhile, you can check my repo here, fork it, do your customization and send pull request to me. I’d like to add new versioning libraries for different scenarios and make it usable for more people. 🙂 Happy coding!!

Treat Bugs as Tasks in Visual Studio Online

When we create a new project in Visual Studio Online in Scrum process template, by default it’ll treat bugs also as backlog items. It does not us to use bugs as tasks. But in some cases, we may need to treat bugs as tasks as well. In this blog, I will explain how to use both modes on Visual Studio Online.

When we start development of an application, we have two options to manage bugs in development process.

  1. Bug as a task
  2. Bug as a backlog item

Bug as a task

When we treat bug as a task, we can add bugs under backlog items. When we use this scenario, we can only add backlog items to sprint. Under backlog item we can add bugs and tasks. This mode is not enabled by default in Visual Studio Online. These are the steps to enable it.

  1. Goto Team Settings in project
  2. Goto Work Tab
  3. Goto section Working with bugs
  4. Select “Bugs appear on the backlogs and boards with tasks.”

When we change this mode, task hierarchy will look like below.


In sprint board, bugs can be tracked under the backlog item.


This is useful if project team is small and given bug is managed by only one person. If we need break it to multiple tasks, we can add sub tasks to bug. If there’s such requirement, it’s better to keep bugs as backlog items rather than manage it as tasks.

Bug as a backlog item

When we treat bug as backlog item, it’ll force us to add tasks under bug to track its state. This scenario useful when we split bug into multiple tasks which may be addressed by multiple people in the team. When we use this approach, task hierarchy will look like below.


In sprint board, we can see that we can track state of each task of the bug and assign them to different people.


This mode is useful when application is manage by large team or bug needs to assign to multiple people. In that case, we can create multiple tasks under the bug and track those separately.

Visual Studio 2015: npm, Bower and Grunt – Part 1

Few days back Microsoft released Visual Studio 2015 CTP 6, I have been using Visual Studio 2015 since the early previews and when it comes to new changes they brought to Visual Studio and Microsoft ecosystem, it’s mind blowing. It’s really nice to see where the company goes with all the new things.

But this blog post series not about Microsoft change, it’s about three small components they integrated to Visual Studio 2015. These were there in Visual Studio 2013 as well but wasn’t inbuilt. Those are npm, Grunt, and Bower. This blog post is for people who have trouble understanding what these are and would like to use these in Visual Studio 2015. First I’ll give introduction to each component and then I’ll show you how to use it in Visual Studio 2015. This blog post is purely used to describe each component and what are key features in each component. In next blog post, I shall describe how to use each in Visual Studio 2015. If you know what these are, you may skip to next post.

  1. Visual Studio 2015: npm, Bower, and Grunt – Introduction
  2. Visual Studio 2015: npm, Bower, and Grunt – Practical usage

Package Managers

Before I talk about each component, I want to talk little bit about package managers. Think of a scenario where you develop an application which uses external libraries. In early days, what we have done was to go to developer site and download required library and add it to our project as a reference. There are two major questions we face when we download libraries from websites.

  • What about dependencies?
  • What if this packages got updated?

Usually we get all dependencies from developer site, but it really can be a headache to add those to project. And about updates, we usually won’t check developer site for updates if it isn’t absolutely necessary. You may argue that updating the package may break the code, true there’s possibility for that. But what if there’s critical update in the package, may be security related, or change in back-end API which got updated in library, we don’t have any option but to update the package. Issue is, in such scenario we may not know the required change until our application starts to fail.

This is where package manager comes in. We can use the package manager to download and install required library to our project. Package manager will automatically download and install dependencies. When an update comes, the package manager will notify us about the update, if we need, we can update it, if we think it’s not necessary we can ignore it too. But at least we know we ignored it and we know what we are getting into, this is much better than not being aware of it.

One package manager we used since Visual Studio 2010 is NuGet package manager.


npm is a package manager for JavaScript. Note that npm only works for JavaScript libraries, in npm context, we all these libraries as packages. Limitation is we only can use npm to install these predefined packages which supplied by a repository. If we want something other than these packages, we can’t use npm for that task. Now you may ask, what do we need other than these packages, if this is such a sophisticated system, it should have all the libraries we want right? Answer is Yes and No.

Yes, because it has almost every commonly used JavaScript library in it. No, because if we want any other library which have htmlcss or images we can’t use npm for that. To understand the reason for this, we should dig into the concept of npm and understand what’s really behind it.

Even though we only see npm in Visual Studio, it really comes with Node.js. Now you may hear about Node.js, it is a server side JavaScript engine (like Apache, IIS). When we install Node.jsnpm comes as default package manager for Node.js. When it comes to Visual Studio npm integration, we use npm to install developer dependency libraries. For example, we use npm to install both grunt and bower

When we work with npm, understanding package.json is very important. package.json is the file which contains settings for given npm package. In our context, this file contains npm settings for our project.When we use npm with node.js, name and version required and plays a major role, but in our case, even though those are required, it doesn’t matter what the values are. What we have to worry is devDependencies property of the configuration. There are actually two types of dependencies in npm, those are application dependencies (dependencies) and developer dependencies (devDependencies). Difference between these two is, application dependencies will get published to your build output, developer dependencies only work on developer environment, they will not get published to build output.

One special thing to note in npm dependencies is that, we can use nested dependency libraries inside our application. This can cause duplication of libraries inside the application. This can be both advantage and disadvantage given the scenario.

There are few annotations you should know when mentioning version of the package you are going to use. I will describe each annotation below.

Version  Description of version
* any version
“” (empty string) any version
 1.2.5 must match the exact version given
>1.2.5 must be greater than given version
>=1.2.5 must be greater than or equal to given version
<1.2.5 must be lesser than given version
<=1.2.5 must be lesser than or equal to given version
~1.2.5 should approximately equal to given version
^1.2.5 must compatible with given version
1.2.x must be subversion of 1.2 (not 1.3 or 1.4)
1.2.3 – 1.2.7 (range)  must be between given range (>=1.2.3 and <=1.2.7)
range1 || range2 || range3 must satisfy one of range given range
http://…….. url must point to tarball, tarball will be downloaded and installed to project (ex: https://bitsnorbytes.com/packages/abc.tar.gz)
git….. git project will be downloaded and installed to project
 user\repository download given repository from given user at GitHub
file:….. get package inside give folder. Folder must be either relative to project or absolute path

When we use npm in Visual Studio 2015, ASP.NET 5 projects, we only use devDependencies, there isn’t any restriction not to use dependencies in the project, but we have alternative way to manage application or client dependencies.

You can read more about package.json properties and specifically about dependencies property from below URLs.


I think you may have idea about what bower is. It’s simply the tool which we use to install any library which going to need to application itself. This is the description given for library in official site.

Bower works by fetching and installing packages from all over, taking care of hunting, finding, downloading, and saving the stuff you’re looking for. Bower keeps track of these packages in a manifest file, bower.json.

Unlike npm bower designed to work specifically for client side libraries. Still you don’t feel like it doesn’t justify the reason to use bower instead of all other libraries right? Main reason to use bower to client side libraries is because it doesn’t support nested hierarchy of libraries. It only support flat hierarchy and does not allow duplicates. In other words, you never can add multiple versions of same library for one project.

Same like npm, bower also have a configuration file.

In bower.json file, name is the name of the application. Property private is to inform bower that this application is a private application and not to publish it to bower registry (if application get registered in bower registry, other users can download application using bower). We can list all dependencies in dependencies property. We can use same version annotations as npm inside this to mention version of library. What specific to bower is the property exportsOverride. This property tells bower what kind of files should be downloaded from each package. This gives developer flexibility remove unwanted files from the package before deployment.


Grunt is a JavaScript based task runner. We can use task runners to run predefined set of tasks repetitively on a project. A task can be either minifiying JavaScript, CSS files, compiling, unit testing or may be check code for errors (linting). For grunt also we have separate configuration file called Gruntfile. But unlike npm and bower, configuration file for Grunt can be either a JavaScript or CoffeeScript file. In Visual Studio we use gruntfile.js file to configure Grunt.

There are few sections in Gruntfile we need to understand. First part is the wrapper function. This function encapsulates the Grunt configuration.

This function also a comes from node.js, if I quote definition from node.js documentation,

The module.exports object is created by the Module system. Sometimes this is not acceptable; many want their module to be an instance of some class. To do this, assign the desired export object to module.exports. Note that assigning the desired object to exports will simply rebind the local exports variable, which is probably not what you want to do.

In simple terms, if we want to expose something inside script file to use outside of file it self, we can use module.export to do that task. You can learn more about functions of module.export from this blog post.

Second part of Gruntfile to understand is the grunt.initConfig section.

As method name says, this initialize the Grunt configuration for each task. For example in here it configures bower task. Now the question you should have is what is a task and how we configure them. When it comes to Grunt a task can be anything. We can create tasks as we desire. In Visual Studio 2015 web project, it only configure the bower task. If you check little bit below, you can see how it create new task.

From this line it says that Grunt should register bower task passing install parameter to it. Basic syntax of registering task is,

You can enter a task name, this is actually a task collection name, whenever you load tasks with this name, Grunt will run all the tasks registered under this name. Task description is optional. When you name a task, you can name parameters of the task using “:” notation. For example, “bower:install”, in here task name is bower and parameter is install.

And final line of Gruntfile,

This allows up to manage bower packages through Grunt, for example, minifying, testing and testing packages through tasks.

This is the end of the introduction to npm, bower, and Grunt. I’ll talk more about how to use these in Visual Studio 2015 in my next post.

Open GitHub HTML/JavaScript project in Visual Studio 2013

Early morning today, it came to my mind that I never used GitHub integration for Visual Studio in my life. With lots and lots of energy, I started to google about the topic. After going through few results I ended up with reading and trying out Rick Rainey’s blog, it is a really good blog post which summarise all the information needed to start and work with project on GitHub with Visual Studio.

But for me, I wanted to do a slightly different thing, I wanted to fork the jQuery project in GitHub and open it from Visual Studio. Really unlucky for me, this project didn’t have a Visual Studio solution file to open it. I had to create a new solution and the relevant projects which were needed. These are the steps I followed in order to accomplish this goal.

1. Fork JavaScript (in my case, jQuery) project from GitHub

2. Clone the project to the local machine, this will download project to given path. Copy the project path before click clone, this will help you in next step.
When you double-click on the project, you will notice that there aren’t any Visual Studio solutions for the project.

3. Goto File->New Project, search for “blank solution”. Paste path you copied in last step to the location and cut last folder name from it and paste it to solution name. In this way, it’ll add a solution file inside the cloned folder. Select “Add to source control” and create new solution.

4. Now you have a new solution without any content to work with. Now you can add either the whole GitHub project as one project to the solution or you can identify parts of it and create separate projects for those. Next I’m going to create multiple projects for separate sections of the project. Right click on the solution, Add->Existing Web Site. Select folder you consider as section of the project.
Now you have Visual Studio solution for GitHub JavaScript/HTML project.

Happy coding!! 🙂