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.
Next in the series on migrating from TFS to VSTS we will work on moving the areas, iterations and queries. This will set us up for migrating the work items next.
The last article in this series discussed how to use the migration tool to move from TFS to VSTS. In this article we will discuss the code, why things work the way they do, suggestions for improvements and areas that can be modified to customize the tool for your specific needs.
My company recently migrated our on-premise TFS 2017 server to VSTS. There were a variety of reasons for doing so including faster updates, less maintenance for us and cleaning up a system that has been upgraded for years and had a lot of baggage. This series of posts is going to discuss the approach we took, the issues we had and (most importantly) provide code to help anyone else who has to go through the same process.
I was recently having issues with CodeLens not showing all the data in Visual Studio 2017. Thanks to Rosen Dash and the TFS team at Microsoft I was able to get my issue resolved. Here’s the problem, and solution, I was having for others that may be experiencing the same issue.