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

Creating a REST API Project Template

While web API and MVC tend to go together, there are cases where you want a pure web API project. This is most common with REST services that have no UI. You would think that this should be easy to set up but, surprisingly, the default web API project in Visual Studio includes MVC. MVC brings in a lot of stuff that you simply don’t need including styling, MVC routing and client libraries. For a REST service where there will be no UI this is wasteful. In this article I’m going to discuss how to create a basic project template for REST services without the need for MVC.

Read More

.NET Core 1.0.0 VS 2015 Tooling Preview 1 Uninstall

With the recent announcement that .NET Core 1.0.0 is officially released, Microsoft also announced that Preview 2 for .NET Core 1.0.0 is available. However to install it you must first uninstall Preview 1 if you have it installed. The issue is that to uninstall you have to have the original setup program. If you go to any current links they will take you to the Preview 2 installer so you are in a catch-22. Fortunately Barry Dorrans tweeted a link to the Preview 1 installer here. So if you need to uninstall Preview 1 first then use that link to get the installer. I also recommend that you keep the Preview 2 installer around for the inevitable uninstall later.

Creating an SSIS Custom Task, Part 6

It is time to wrap up this series on creating a custom task for SSIS. We are going to finish our discussion with some advanced, but common, UI needs including:

  • Support for viewing and creating connections
  • Support for viewing and creating variables
  • Support for dynamic properties
  • Support for enumerating reports in SSRS
Read More

Creating an SSIS Custom Task, Part 4

In the last article we set up some infrastructure for creating tasks. We then implemented the shell of the task to generate SSRS reports. In this article we are going to finish up the runtime side of the SSRS task. To do that we need to talk about task parameters, persisting the parameters, getting access to connections at runtime and how to work with variables at runtime.

Read More

Creating an SSIS Custom Task, Part 3

In the first part of this series we generated an SSRS report using an SSIS script task. In the second part we created a custom task to display “Hello World”. In this article we will combine the work to create a custom task to generate an SSRS report. For this post we will simply get the runtime side of the task working. Design time support will be added in a later article.

Read More

Creating an SSIS Custom Task, Part 2

In the last article we created a simple SSIS package to generate an SSRS report and save it to disk. For a single report this is fine as it didn’t require a lot of code but imagine if we wanted to write new packages and reuse this code. This is where script tasks break down. Each script task is a standalone block of code, basically its own .NET project. Code in one script task has no access to any other script, even in the same package. The only way to share code is copy/paste. This is error prone and unmaintainable.

One way to work around this is to create code outside the script task and copy paste the source files into each script task. This works but can be difficult to maintain over time. The ideal solution is to move this code into its own assembly and then reference the assembly in each script. Unfortunately SSIS requires that all script references be in the GAC. This complicates deployment as we’ll see later but is doable.

This is where SSIS custom tasks become useful. When you want to use the same script task in several different places or packages then it is time to promote it to a custom task. This provides several benefits.

  1. Code duplication is eliminated.
  2. The need for a script task goes away and is replaced by a reusable task.
  3. A custom task is easier to use in packages then script tasks.
  4. The custom task can access functionality that is difficult or impossible to do inside a script task.

For this article we will replace the existing script task to generate SSRS reports with a custom task. Creating the task and building the UI is straightforward once you get past the initial learning curve. Surprisingly though working with Winforms proves to be the most challenging aspect of the process. Before continuing be sure that everything is setup as discussed in the previous article.

Read More