P3.NET

Office 2016: Selective Installation

A while back I posted about the Office 2016 release and why I wasn’t going to run it. One of the biggest complaints I had was the fact that there were no setup options. It installs everything whether you use it or not. Fortunately that has now changed, sort of. This post is discussing the steps you can take to install only the apps you want to install. It still is not perfect, it still makes no sense whatsoever and it still doesn’t make me want to recommend Office 2016. But at least I can now run it without all the wasted space.

Read More

Writing a Context Provider for CodeRush for Roslyn

Several years ago I wrote an article about creating a custom context provider for CodeRush. In that time CodeRush Classic, as it is called, has been replaced by CodeRush for Roslyn which relies on Roslyn. Now seems like a good time to update the provider. Rather than having to read both articles I’m going to repost the old article with updated changes for Roslyn. The code is semantically similar but had to be rewritten to use Roslyn.

Read More

Generating _PublishedWebsites in TFBuild

We have slowly been migrating our XAML builds to TFBuild. After having blogged about how we created custom build tasks we were finally ready to start transitions our builds. At our company we have basically 3 different kinds of builds – ASP.NET apps, console applications and REST APIs. Using XAML builds our deployment process was configured to look for the _PublishedWebsites directory for ASP.NET apps but that doesn’t get created in TFBuild. Hence I spent some time looking for a solution.

Read More

Create a Build Task for TFBuild, Part 2

In the last post I demonstrated how to create a build task for TFBuild that showed the build variables. I also demonstrated how to wrap the task in a build extension that could be installed in TFS, on-premise. In this post we’ll add another task to the extension. This serves two purposes. Firstly it demonstrates hosting multiple tasks in a single extension. Secondly it demonstrates a more common build task, versioning assemblies.

Read More

Custom Naming Styles in Visual Studio 2017

One of the great new features in Visual Studio 2017 is the ability to define naming rules for code and then let the IDE notify you when they are violated. Depending upon what options you choose the IDE can suggestion, warn or flat out fail compilation because of violations. In this release the options are limited but since the rules are using Roslyn, the options can only improve in later releases.

Read More

Identifying Slowdown in Visual Studio 15 Preview 5

As Visual Studio has become more extensible there are more and more extensions that developers like to install. Unfortunately not all of them are well behaved. The more extensions you install the more likely VS will crash or slow down. When this happens most people tend to go to the forums and complain about VS bugs and/or performance. Yet the culprit is likely an extension. Up until VS 15 preview 5 there has been no easy way to diagnose this. Generally, when responding to a forum post, a user is recommended to run in safe mode to eliminate the chance that it is an extension. But doing this doesn’t really help narrow down the problem that much because: 1) the problem may not occur very often and 2) many extensions are critical to doing real development. In VS 15 Microsoft has finally added some performance monitoring to VS. VS has had perf monitoring for a while but none of that was visible to the average user. In VS 15 you can now go to Help\Manage Visual Studio Performance and get a window that provides some basic information about extensions and tool windows, the two most likely causes of a slowdown. This window allows you to see if an extension or window is slowing things down. If so then you can disable it and report the issue to the author. Hopefully this will cut down on forum posts but we’ll have to see how this feature evolves until release.

VSHost Bug is Squashed

Way back in Visual Studio 2005 Microsoft added a new debugger host, VSHost. The purpose, as advertised, was to speed up debugging by taking the hit for starting a debug session. The idea was that the host was started when you first began debugging and continued to run until you closed VS. This allowed VS to keep debugging information cached which sped up repeated runs of the debugging session. It only worked for managed applications but, for the time, greatly increased debugging startup. But there were problems with this approach. Firstly was that some apps simply didn’t work correctly with it. Microsoft provided a project debug setting that allowed you to disable the host in this case. Secondly it mucked with the whole debug process because VS started the host which emulated your process (it even had a config that matched your config). Thirdly, since it was a separate process, it would occasionally stop responding or crash which caused issues with the debugger. Starting with VS 15 preview 5, the VS host process is gone. Microsoft has wisely optimized debugging startup times making the need for this process mute. So now running your app in the debugger is going to behave more naturally and, in theory, VS shouldn’t run into any more issues of disconnected processes. You can read more about this decision here.here

Light Switch Is Off (Deprecated)

As part of the Visual Studio 15 preview 5 release, Microsoft has announced that Lightswitch is officially deprecated. VS 15 will not ship with it. Microsoft is recommending that everyone switch to PowerApp or equivalent. Note however that Microsoft will continue to provide security fixes and support existing Lightswitch apps for the foreseeable future. However Microsoft does not recommend any new development use Lightswitch. Read the full announcement here.here