A couple of months ago I first wrote about an open source project that I started called MSBuild.Sdk.SqlProj. Since then it has gained some traction and I’m happy to say it is probably the most succesful open source project I’ve launched ever. So I though this would be a good time to give an update on the project and share some of the things that are new. If you’re unfamiliar with the project I recommend reading the announcement blog post first.

At my current employer, R&R Workforce Management, we’ve done a pretty big investment on Microsoft’s SQL Server Data Tools (SSDT) to manage our database changes. We made that decision when we migrated off of the Oracle database onto SQL Server which is quite a few years back now. At the time it was probably the most mature tool available that allowed us to version control our database changes much like we version controlled all our source code.

This is the third post in my series on building a pull request bot using Azure Functions. If you haven’t read my previous posts I strongly recommend doing so before diving into this post. Remember that this series is a part of the Applied Cloud Stories initiative. Part 1: Introduction Part 2: How it works Part 3: Operating it In this post I want to give you a feel for how we operate our pull request on a daily basis.

This is the second post in my series on building a pull request bot using Azure Functions. If you haven’t read my first post I strongly recommend doing so before diving into this post. Remember that this series is a part of the Applied Cloud Stories initiative. Part 1: Introduction Part 2: How it works Part 3: Operating it In this post I’ll dive into the details of how the bot actually works, from receiving notifications from Azure DevOps to managing state and posting comments back to the pull request.

About 2,5 years ago I was talking to my fellow team members about some of their challenges. At the time we had recently switched from TFS Version Control (TFVC) to Git, which obviously introduced quite a few changes in the way we worked. For example, we introduced pull requests as a mandatory step in the development flow in order to increase awareness and code quality. However, we found that some things that would need to happen for every pull request weren’t being done (or not done properly) which weren’t always caught by reviewers either.

This post is part of a series: Part 1: Introduction Part 2: Third party dependencies Part 3: Mechanics of porting Part 4: Deployment and packaging options If you haven’t read any of the previous posts I recommend you do this now to get some context that I’ll be referring to in this post. If you have, continue on with the nitty gritty details of porting an app to ASP.

This post is part of a series: Part 1: Introduction Part 2: Third party dependencies Part 3: Mechanics of porting Part 4: Deployment and packaging options If you haven’t read the first post yet I suggest reading that first since it introduces the app that I’m porting and some of the reasons behind it. Are my dependencies available on .NET Core? Most software these days consists of not just the code we write, but a lot of third party dependencies as well.

Last week I took to Twitter and asked if anyone of my followers would be interested in a session about .NET Core for developers that are using .NET Framework today. I wasn’t really expecting all that much by sending that tweet, but with a little help from Immo Landwerth who’s on the .NET team, that tweet seemed to have sparked quite a bit of interest in such a session. Perhaps the announcements that ASP.

It has been a while since I’ve posted something here on my blog. That’s not because I haven’t done anything, just that I’ve been really busy lately with all kinds of things. For example, I’ve been delving into the container world and delivered a hands-on workshop with Kubernetes on Azure as part of the Global Azure Bootcamp 2018 back in April. That was a lot of fun, since I didn’t know much about Kubernetes before I started working on that, so I learned a lot in a relatively short amount of time, but I digress.

As ASP.NET developers we’re fairly used to hosting our code inside Internet Information Services (IIS). However, since ASP.NET Core is cross-platform, hosting inside IIS isn’t always an option. For that reason, the hosting model for ASP.NET Core applications looks quite a bit different. Of course, we can still host our code in IIS, but we also have the option to use Kestrel and run as a standalone application. This new hosting model is visible in code through the WebHostBuilder API from Microsoft.

This week I’ve attended Microsoft’s Build conference in beautiful Seattle. It has a been a very busy week, but we had a lot of fun attending the different sessions as well as talking to some of the members on the various product teams. Of course, during the week, my focus has been on .NET Core. I’ve attended most (if not all) of the sessions on .NET Core (and related technologies such as ASP.

I’ve written quite a few blogs here on how you can use .NET Core in your applications and what to expect when developing for this new platform. But with .NET Core being open source there’s also another story to be told, namely that of extending and improving the platform itself through open source contributions. So when Karel Zikmund from the .NET Core team reached out on Twitter asking the community to help them fix bugs before the .

In my previous blog post I talked about sharing .NET code across the various .NET platforms we now have within the .NET ecosystem (.NET Framework, .NET Core, Xamarin). In that post I also showed the new tooling within Visual Studio 2017 that enables (among other things) cross-targeting a lot easier than it was before. Since then two new versions of the new tooling experience for .NET projects have been released, and things have matured quite nicely.

One of the key things that makes Xamarin such a great platform for developing mobile applications is that you can leverage your existing skills with C# and .NET and use them to create awesome Android and iOS apps. This also meant that you could take existing code written for .NET and use it in your Xamarin apps. Of course, in the early days of MonoDroid and MonoTouch (before Xamarin was even a company) this wasn’t as easy as it is today.

Unless you have been living underneath a rock you’ve probably noticed that yesterday, during Microsoft’s Connect() virtual event, .NET Core 1.1 was released. In addition ASP.NET Core 1.1 and Entity Framework 1.1 have been released. You can read up on the announcements in the following posts: .NET Core 1.1 - https://blogs.msdn.microsoft.com/dotnet/2016/11/16/announcing-net-core-1-1/ ASP.NET Core 1.1 - https://blogs.msdn.microsoft.com/dotnet/2016/11/16/announcing-net-core-1-1/ EF Core 1.1 - https://blogs.msdn.microsoft.com/dotnet/2016/11/16/announcing-entity-framework-core-1-1/ At first sight this doesn’t seem like much of a deal.

In case you missed it, .NET Core RC2 has been released by Microsoft last week along with ASP.NET Core RC2 and a preview of the tooling. Lots of exciting new stuff that I highly encourage checking out. Now that RC2 is out there I guess a lot more people will be checking it out and playing with it and there’s one topic that seems to confuse a lot of people. So I thought I’d write a blog about it to clear things up a bit.

As some of you might have seen on Twitter or Facebook I have attended Microsoft’s Build 2016 conference in San Francisco over the last week. It was an interesting experience with some good announcements, although to be honest I was expecting a little bit more. Then again Microsoft has become a lot more open about what they are doing which kind of takes the thunder away from these conferences. Free Xamarin, Azure Service Fabric generally available, Microsoft Cognitive Services and the Bot Framework are still great announcements though.

For the project I’m currently working on I did some research into the throttling of workflow services using WCF and WF with .NET 3.5. We didn’t have much experience with throttling of services, let alone workflow services so we decided to some simple tests to determine the possibilities and effects of throttling. Before diving into the technical details of how to do throttling I want to look at the scenario we had.

Introduction For the project I’m currently working on we wanted to be able to display an image of a running workflow instance for diagnostic purposes. There are numerous examples of this floating around the internet, but most of them focused on a client side application that would generate the image. This is fine if your client application has access to all the necessary assemblies, but if does not you’re going to run into some problems.

As a follow up to my previous post, I’ve been extending my implementation a bit. In the comments section of my last post you might have read that we were thinking about creating a CorrelationSequenceActivity. I’ve implemented this activity now and it currently accepts only one child activity which should be a ReceiveActivity. This is validated using an activity validator. It has an attached property called CorrelationKey which will then appear on the ReceiveActivity.

When .NET 3.0 was released we got Windows Communication Foundation (WCF) and Windows Workflow Foundation (WF). These were great technologies, but they would have been even greater if they were used together. Unfortunately, Microsoft decided not to include this for .NET 3.0. However, with the release of .NET 3.5 we got the WCF Send and Receive activities that you can use in your workflows in order to implement a WCF service contract by using a workflow.

Part of the project I’m currently working on involves a workflow system we have build ourselves on top of Windows Workflow Foundation. It consist of a WCF service that contains task, a front end that displays these to users and of course several workflow activities for creating tasks and waiting for them to be completed by the users. Last Friday it was finally time to perform an installation of the system on our acceptance environment so the users could test it.

Today we ran into an issue with a Windows Forms application we had written. It was working fine on our development virtual PC’s, but for some reason it failed on the actual host machines that we needed it to run on. The application is written purely against the .NET Framework version 2.0. We do communicate with a service that is using WCF, which is part of the .NET Framework version 3.

Today I was working on an issue in our application that was brought to our attention by one of the users. So I started investigating this issue and soon found out that the problem was situated in our ASP.Net front end. While I was debugging and analyzing the call stack I found out that something went wrong between the page that is being posted and the Mediator, which is responsible for actually saving the data to our back end services.

I thought I’d write a little follow up on my previous post. We found out yesterday that the bug we found in Windows Workflow Foundation which caused us to make a work around, has been fixed in the recently released .NET Framework 2.0 and 3.0 SP1. We haven’t been able to find a mention of this bug in the release notes, but we had a small application that showed the bug was there, so we tested it on our development machine which were using the service packs and then on a test server which didn’t have the service pack installed and it showed that it was working find on our development machines, but it didn’t work on our test servers.

At the beginning of last week a report came in from our users which said that they were experiencing timeout issues while working with the application that has been running in production quite stable since the beginning of this year. Because this was a blocking issue we quickly started investigating what went wrong. After looking at the code for about half an hour we decided we needed to put on tracing to find out what really happens.

Today I was working on a bit of workflow we have in our project. We’ve written a couple of activities to handle some of the processing done in our application (such as sending out emails at a specified point in time). These activities have been working quite well, but they lacked some kind of validation on required properties or how they were used in the workflow. So I was assigned the task to implement some of that stuff.

As my colleague Willem mentioned, Microsoft has finally released Silverlight 1.0. I find it amazing how fast this technology has gone. A year ago nobody heard of Silverlight, and now there is a first release. Although I’m quite impressed by the features of Silverlight 1.0, I think that Silverlight 1.1 has far more potential. Having the power of C# inside the browser, that must be awesome. It is going to open up a lot of possibilities for a richer end-user experience, while a lot of the advantages of web applications are still there.

This week I’ve been spending some more time on this WCF issue I’ve blogged about before. Unfortunately I still don’t have a solution for the problem, and I doubt that I will ever find one. However, I did find some interesting things I thought I should blog about. I found out that the bug isn’t in the actual serialization process, but rather in the generation of the code that is supposed to do the actual serialization.

As I was writing in my previous post there is something interesting going on in WCF. But before I go into the details, let me explain the situation. There are 3 services in our project, one business service, one process service and one front end. We use WCF to communicate between these services. We are using basicHttpBinding and we have a central set of XSD schema’s from which we generate code using the svcutil tool provided with .