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

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.

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.

In the previous post we finished the runtime side of the SSIS task. It’s time to work on the design side. The design consists of a standard Winforms form and controls. If you already know Winforms then you are halfway there. If not then you should read up on it first.

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.

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.

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.

Code duplication is eliminated.

The need for a script task goes away and is replaced by a reusable task.

A custom task is easier to use in packages then script tasks.

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.

A while back I posted an article on how to extend the existing help pages generated by Visual Studio for Web API projects to use reflection instead of XML documentation. One of the limitations of that approach was that you could not test the APIs directly. You had to use SoapUI or equivalent. Since then I have started using Swagger for documentation. As a documentation/testing tool it fills the need. In this article I will demonstrate how to integrate Swagger into a Web API project. Additionally I will continue to use the reflection provider from the previous article.

Recently I had the need to create a couple of custom tasks for SQL Server Integration Services (SSIS) at work and I was shocked at how few the resources were for doing this. There are a lot of blogs and articles about creating SSIS custom tasks, but most of them are outdated or wrong. Even Microsoft’s own documentation has clearly been promoted from older versions and is no longer accurate. This leads to a lot of wasted time and scratching of your head trying to figure out what is wrong.

In this series of articles I’m going to demonstrate how to create a custom task for SSIS 2014. This information is also applicable to SSIS 2012 but doesn’t necessarily work with earlier or later versions of SSIS. In this first article we will set up a simple SSIS package that we can use for the remainder of the series.