One of the better changes in Visual Studio 2017 is the moving of the NuGet packages out of packages.config and into the project file via package references. Unfortunately all the documentation that I’ve seen seems to assume that this is a new project or at least one that was created in Visual Studio 2017. In my experience this is unlikely to be true. This article will discuss the steps I use to migrate an older project to using package references.
Last year I posted a series of articles about creating custom SSIS tasks to cleanly wrap some common work you may find yourself doing in SSIS. You could do this with script tasks but if you need this same functionality everywhere then it becomes a maintenance issue. In that series of articles we created a framework for adding new tasks easily and created one task to generate SSRS reports. Since that time my company has been using these tasks successfully but we did identify a couple of issues. Since that series of blog posts was based upon the lessons we learned it makes sense to update the code with the changes we’ve made over the past year.
Many times when you are adding a new item to a project you probably find yourself changing the generated item to line up with your coding or company styles. Often this includes a copyright, perhaps the ordering of members in a type or even completely replacing the item with something else, like an enum. Visual Studio is designed to be extensible. Item templates allow you to create your own templates and have them available in VS so you don’t have to keep making the same changes over and over again. In VS 2017 templates are even easier to create than before. I will discuss how easy it is to add new templates in this article.
Recently I was writing some code for one of my personal projects and I ran across this error in the first Entity Framework call I made – System.ArgumentException ‘DbLimitExpression’ requires a collection argument. Haven’t seen that one before. For anyone running into this issue here’s how I figured it out.
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.
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.
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.
Now that VS 2017 is ready it is time to update the template extensions I provided for previous Visual Studio versions. However this time the templates themselves don’t really need to change. Instead the VS extension that I wrote to wrap them needs to be updated to take advantage of the newer VS extension features.
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.
There are many articles around how to build tasks for TFS 2015’s newer build system (TFBuild). This is yet another one that tries to consolidate the information floating around into a central location and includes information for deploying to an on-premise TFS server.