Sunday, March 19, 2017

Current state of Visual Studio releases [March 2017]

HI guys! We all know that Visual Studio 2017 has been released! Not jus that, at the time of the release of Visual Studio 2017, Team Foundation Server 2017 (on-premise) is reaching Update 1. There are also some news about Visual Studio 2017, TFS 2017, and the whole tooling and ecosystem as well.

On Visual Studio releases from January 15 to March 15, 2017, these are the notable news:

  1. Visual Studio 2017 is reaching RTM (or RTW, release to web) on March 7 
  2. Visual Studio Team Foundation Server 2017 is now at Update 1 on March 7
  3. General release of Azure Functions support of F# on March 16

Now, let’s start from the latest.


Visual Studio 2017 is reaching RTM

Yes! Visual Studio is reaching RTM! The launch is 2 days event: March 7 to 8. It was broadcasted live, and this is also the 20th anniversary of Visual Studio since the first release of Visual Studio 97. Yes, Visual Studio is reaching more than maturity, if you follow Visual Studio history itself and also one year of iterations/releases can mean more than one year in actual maturity of a software product!

This is the original page of Visual Studio 2017 launch: https://launch.visualstudio.com/

The plan for the launch is already announced at Visual Studio’s blog team on February 9: https://blogs.msdn.microsoft.com/visualstudio/2017/02/09/visual-studio-2017-launch-event-and-20th-anniversary/

The original version “1” of Visual Studio is released in around early 1997, it is dubbed as Visual Studio 97. The blog shows the VS 97 setup display:

Previous Visual Studio releases has took quite long unpredicted schedule, especially from Visual Studio 6 (also called Visual Studio 98) to Visual Studio .NET. It takes more than 4 years! Since year 2000, one year in software development can mean anything especially when the other IDE competitors such as Eclipse, Netbeans and Jetbrain’s IntelliJ have been racing to have its own unique/distinctive features as competitive advantages.

So we can safely say that the release is not so surprising, because of the previous VS 2017 release candidates from RC1 to RC4. This announcement also has proven that Visual Studio has very tight cadence, and be prepared to see the next release of Visual Studio 2017 for every 18 months!

Visual Studio 2017 is basically contains these remarkable new features:

  1. Installation is defined as “workload”, categorize common scenarios of Windows development, game development, UWP development, Unity development, Data science, etc
  2. This is the initial release of Visual Studio to use CPS as its project system instead of legacy MSBUILD project system. But MSBUILD is still used to build almost all of the project within Visual Studio, especially .NET related projects (including full .NET Framework, .NET Core, .NET Standard)
  3. This is the initial release of Visual Studio to support .NET Standard. This tooling support is supposed to be available in VS 2015 too, but now all of the effort of .NET Standard support is focused on VS 2017.

For a detail list of what’s new in Visual Studio 2017 RTM, I will describe in a separate blog post after this.

Some things in Visual Studio 2017 are still not addressed/solved

Looking at the long history of Visual Studio releases, these are the remaining interesting issues still remain:

  1. Portability of installation of Visual Studio (since the beginning of Visual Studio)
  2. Full support of .NET Native in F# (since VS 2015 Update 3)
  3. Some of the tools are not mature enough, such as tooling for developing Azure Functions in F# (since VS 2015 Update 3)

Now, let’s start to discuss some of those points below.

Portability of Visual Studio installation

There is one thing for sure, Visual Studio cannot beat Eclipse full portability download. This issue is still tracked as feedback in Visual Studio uservoice feedback: https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/6669672-wouldn-t-it-be-nice-if-visual-studio-could-work-li

Unfortunately, this feedback has been going under indefinite status of “UNDER REVIEW” for more than 3 years:

VisualStudio_portable_feedback

Look at the number of votes! More than 2000 votes, this means this proposal should be heard and considered. Any rejection to this proposal has to be strongly reasonable, otherwise the unreasonable rejection will bring harm to the Visual Studio community as a whole.

Having a portable installation or setup of Visual Studio means that we should have less worry about installation setup, settings, registry, and many others. This also means that any toolings/extensions for Visual Studio must not depends on registry as well, just like Eclipse ecosystem and Eclipse PDE.

No .NET Native full support for F#

Yes, this is crucial and it’s often overlooked. No full support for .NET Native toolchain means that we cannot develop UWP (Universal Windows Platform, the Windows 10 store application) applications using F#.

This might be a strong statement, but I’ll try to explain this to you:

  • .NET UWP application is usually distributed on Windows Store
  • Any .NET UWP application submission to Windows Store is checked against .NET Native release binary
  • Currently in VS 2015 Update 3 and VS 2017, there is no .NET Native toolchain support to support F# generated IL.
  • Therefore, it can be considered impossible to implement all UWP applications in F#

Fortunately, the whole dev team at Microsoft has been aware of this since VS 2015.

We know that F# tooling and compiler is open source, and there has been heroic efforts by F# community members and MIcrosoft’s F# and other .NET team members to solve this by closing the gaps of F# feature with .NET Native.

One big major setback of .NET Native lack of features is the availability of tailcall optimization.

To track the update of the .NET Native support for F#, this is the GitHub issue link under Microsoft Visual F# repository:

https://github.com/Microsoft/visualfsharp/issues/1096

 


Visual Studio Team Foundation Server 2017 Update 1 is released

Yes! Visual Studio TFS 2017 Update 1 is released at the same time with Visual Studio 2017. It is also mentioned at the launch page.

There is also official announcement from Brian Harry, although it is a little bit late: https://blogs.msdn.microsoft.com/bharry/2017/03/08/team-foundation-server-2017-update-1-available/

This is the official link to the release notes: https://www.visualstudio.com/en-us/news/releasenotes/tfs2017-update1

This Update 1 cannot be ignored, because it has quite tons of new features! In my own personal opinion, these are the most notable additional features of TFS 2017 Update 1:

  1. Personalized welcome page. This is very refreshing and it’s now easier to navigate if we have many team projects.
  2. In the Git support, we can now search for commit in a branch
  3. In the Git support, administrative privileges are now becoming more granular, especially when dealing with repo creation and repo deletion.
  4. In the Git support, we can now have nice preview of markdown editing.

The personalized link of TFS 2017 Update 1is currently the same web page of the page of my own VS Team Service account:

VS2017_TeamService_2017February

All of the team projects you have will be listed based on your customized list, and if you hover on the team project name, it will display all of the additional link such as the Dashboard, Code, Work, Build and Release, Test.

In the PR comments, it’s a welcome addition to see basic editing tool and preview available:

NOTE:

  • on TFS 2015, Build and Release are under separate page.
  • TFS 2015 Update 3 can accommodate markdown in the PR comments, but the basic editing tool is not available.

While this release of TFS 2017 Update 1 is so promising, I believe many companies are not ready yet to move from TFS 2015 Update 3. Because again, the TFS cadence is becoming shorter than before, and now the race to always have updated TFS might be solved by always using the online Team Services, although some companies are not willing to go to this path because their code is very precious.


The official release of Azure Functions support for F#

Yes! Now we can create Azure Functions using F#, although F# support has been previewed before.

Azure Functions is a serverless application, it is actually a simplified model of already existing Azure Web Jobs. But this serverless model means that we are not dealing with the detail of how the function is deployed, on what platforms, and other things. We are only focusing on the correctness of the functions, and how we are executing it.

Azure Functions itself is generally available since November 2016, according to this Azure’s official blog article: https://azure.microsoft.com/en-us/blog/announcing-general-availability-of-azure-functions/

The initial launch of Azure Functions only support C#, Powershell, Bash, Python. At that time, F# support was still in preview and a little bit unstable.

Fortunately support for F# is now officially stable: https://blogs.msdn.microsoft.com/appserviceteam/2017/03/16/azure-functions-f-support-is-now-generally-available/

They also have this picture of love relationship of Azure functions and F#:

This is soooo cool!

I have discussed and presented Azure Functions in F# at the meetup of Lambda Jakarta on March also, and the reaction is so priceless although some of the invited and joined guests weren’t there.

This was the picture of myself presenting and demoing Azure Functions in F#:

LambdaJakarta_2017_March_present

Here’s my Azure Functions sample (edit and test it directly):

AzureFunctions_Demo_LambdaJakarta

I know that the demo is so simple, but this Azure Functions is much more powerful than Amazon AWS Lambda compared to the readiness of toolings and the full Continuous Integration that Azure has.

This is the landing page of Azure Functions: https://azure.microsoft.com/en-us/services/functions/

The Azure Functions template and the inclusions of libraries are open source! This is the official GitHub landing of Azure Functions: https://github.com/Azure/Azure-Functions

We have GitHub’s Azure functions page, and therefore we can contribute as well!

Next blog entry: the full journey of the new features of VS 2017.