Skip to main content
A quick look at the Visual Studio 2017 RC installation and first impressions on the look and feel of the new IDE

My first impressions are really good. The web install genuinely took around 7 minutes and I was up and launching a new Asp.Net Core boilerplate application in a further 2 minutes, allowing for first time customisation and profile configure. That’s zero to hero in under ten minutes which is finally a wait time I can work with and will no doubt encourage non Microsoft Developers to just give it a try. I decided to go for the community edition for simplicity.

The new setup experience
The installer has been written from the ground up and it certainly feels nicer than the typical Microsoft Installer experience of not so long ago. I really like the select what you need approach and add later, which has always been possible but is a cleaner approach where you are selecting your intent rather than a host of individual features typical of a custom install.

It then picked up my profile settings and applied the ‘Dark’ theme that I mostly use.

My first observation from the out of the box experience is that the balance is pretty much right. Familiar enough to navigate without any problems but the new features are available when your interest takes you there. I like the fact that the configuration has added the common elements you would expect to see out of the box. For example, Static Files and IIS Integration. The initial beta release really went for fast start-up of .Net Core but was a pain to keep adding the common initialisation, especially as the namespaces and project configuration types were ever moving.

Out of the box, ‘Use Static Files’ is configured. I must admit, it is a better way round, rather than adding to almost every project as nine times out of ten we will require serving static html files some point. It also offers a quick and easy way to start developing from any other framework.

I also like that ‘UseIISIntegration’ is alo in by default as that is going to be the most familiar to seasoned Asp.Net web devs.

It’s worth showing all files to see everything residing in the project

As you can see below, we are back to .proj files again and project.json is no longer the central configuration item

What is nice is that intellisense now kicks in for the project file. As you start typing the namespace, service calls are being made to show available packages


A very quick look and I can say interest and confidence is high with the new offerings.
Definitely worth a keeping an eye on the Visual Studio Blog for frequent updates in this space at the moment.

If you would like some hands on expertise for your business feel free to reach via my company assemblysoft



Popular posts from this blog

.Net TDD (Test Driven Development) by example - Part 1

Introduction In part 1 of this mini-series, we will develop a trivial business logic layer from scratch with a TDD approach with the goal of achieving the following:

Better code quality through Red, Green, RefactorDocumentation that grows as we develop and remains up to dateAutomatic regression test harness
This will primarily involve creating unit testsfirst, having them fail, making them pass and then refactoring the code to be of better quality and then re-running the tests. When using tools such as resharper to aid in refactoring code, having the tests in place right from the beginning really gives you peace of mind that you haven't broken anything. It also helps the thought processes while designing and developing an application or feature to be more targeted.

We will further develop the application in part 2 to add an MVC4 web client and continue the TDD story... 

Some BackgroundTest First or Test Driven development is a valuable software engineering practice. It c…

Azure Devops - Pull Request Merge Conflicts

Before a Git pull request can complete, any conflicts with the target branch must be resolved. Out of the box, at the time of writing this article, Azure DevOps requires this to be resolved locally. Following best practices to not allow direct commits to our release/master branches further exasperates the problem as we need to effectively clone the branch or go with a rebase approach, both of which break the natural flow of resolving the conflicts as part of the pull request.

With this extension, from the Microsoft DevLabs team via the Marketplace, you can resolve these conflicts online, as part of the pull request process, instead of being forced to break flow and resolve locally.

Online Experience After adding the extension the new conflicts tab is visible which enables conflict resolution in the familiar side by side review page as shown below:

Really nice extension, which should make resolving merge conflicts a much more straightforward part of the DevOps workflow. 

Additional - Ad…

Simple Git branching strategy for release cycles

Coming up with a branching strategy that works well can be challenging when working with multiple developers and managing release cycles. A simple approach is presented here to manage release cycles, with a small to medium sized team of developers while still being able to react to production issues and fix bugs. The primary goal being to isolate work streams without impacting development progress. BackgroundGit does not enforce any particular strategy when it comes to branching which is partly what makes it such a great and flexible repository. The problems start to arise though as you move into different stages of your development process. As an example, you have a release almost complete but don’t want to impede progress on the upcoming release cycle which is where the majority of effort is required. The Basic ApproachThe focus is around producing a release while still being able to react to hotfixes or production issues without impacting on going development of features. The branches…