If you aren’t aware, Kraken is my personal class library that I’ve been using since the early days of .NET. It has evolved over the years to support new featuers as .NET and my needs have changed. The entire source code is available on Github and I have recently been pushing builds to NuGet. Prior to that I ran my own private NuGet server where I hosted the packages and used them in my projects. Now that .NET Standard 2.0 is out and my company is looking at moving to .NET Core it is time for me to upgrade Kraken to .NET Standard. I’m going to document that process here because I think my upgrade path is going to be very similar for others.
It seems so simple. Someone posts an example of how to do something using a cool, new feature in C# and you try to use their code and it fails to compile. Or you see something documented as working and you try it and it fails to compile. Why is that? It actually is quite simple but probably not at all obvious to the average developer.
If you are not aware yet Visual Studio 2017 shipped with support for a newer project format (informally known as the SDK project format). The newer format came about for a variety of reasons including:
- The traditional project format is very verbose.
- The traditional project format is hard to read and edit.
- The traditional project format requires the file to be modified for every change made to the project.
- The .NET Core
project.jsonformat did not easily map to the traditional project format.
While the focus on the new format has been to support .NET Core applications it can be used with many other project types as well, with restrictions discussed later. In this article I will discuss how to migrate a traditional project file to the newer SDK format. There are numerous other blogs on this same topic if you want to get different viewpoints.
PowerShell has become the defacto scripting language for Windows platforms. It brings the power of .NET to the command line. One of the benefits of PowerShell is creating scripts or functions that can be shared with others. This allows teams to simplify repetitive tasks by putting them into scripts and then sharing them with each other. The downside to this is that PowerShell, by default, makes it hard to run scripts (for security reasons). Additionally each user has to copy the scripts someplace where PowerShell will find them. In this article I’ll talk about an easier way to deploy scripts such that they can be run just like the built in commands. Unfortunately it requires a little more effort upfront but once you have the pattern down it is really easy.
If you’ve never used a C# iterator before then it may seem like magic. But under the hood it isn’t doing anything you can’t already do yourself. It is a time saver and as such there are quick actions and analyzers to recommend that you use them. If you’re like me you use them without even thinking but it is still important to remember they are generated code. It really shouldn’t be necessary to understand the underlying implementation of how they work but sometimes you have to. Here’s an interesting oddity that I saw recently with iterators.
If you use .NET to talk to an Oracle database then you most likely are using ODP.NET. This is a .NET package provided by Oracle for communicating with their database. But using it has been historically difficult because of the dependencies. My company uses Oracle in a couple of applications and therefore uses ODP.NET but recently, as we are moving to .NET Core, we revisited this code and have been able to successfully upgrade to the newer ODP.NET Managed Driver.
Are you a C++ developer? Have you heard about vcpkg? Vcpkg is a package manager for C++. The goal is to allow C++ developers to take advantage of packages like we have in other languages. Gone, in theory, are the days of downloading SDKs, setting up include and lib paths and copying binaries around. vcpkg is an open source solution that Microsoft is integrating into Visual Studio.
Note: Everything in this post is my own opinion on the topic. It in no way represents the opinions of any one else or any company. Everything stated here should be taken as simply one person’s opinion.
A big announcement out of MSBuild was the support for Windows desktop applications (Winforms, WPF) on .NET Core 3. This came as a surprise to many because Microsoft had deemed UWP to be the Windows platform of choice. It seems that Microsoft has changed their mind but if you look at the history of Core this really shouldn’t be much of a surprise.
In the final post on our migration from TFS to VSTS we will focus on the build components of TFS. This includes build definitions and task groups.
In the last post we migrated the areas, iterations and queries. With that out of the way we can now migrate the work items. This is by far the most difficult and time consuming part of the process. For our migration we had some pretty stringent requirements which made the migration harder. Things to consider include the items to migrate, the links to include, the changes in the IDs, the user identities, attachments and images and whether history needs to be retained.