Debug Builds with xprojs

I recently switched an older project that was using the VS2015 .csproj file to the newer VS2017/“xproj” style file that came about with dotnet. I love the new xproj style files because they are so much cleaner/simpler and they integrate the nuget package information. It’s also fantastic that you can open and edit those files in Visual Studio without have to unload the project. Just update the file and watch as Visual Studio dynamically reloads the interface with the new information. Fantastic!

But, something that I didn’t expect to happen was losing line number information in my stack traces when exceptions occurred. So, it was surprising when our Test environment didn’t return the line numbers of an exception after switching over to the xproj style file.

What was missing?

I didn’t use an auto-conversion tool to do the conversion, so I mistakenly dropped a few important details from the file. The critical piece that dropped was the <DebugSymbols> and <DebugType> flags. The older style csproj file looked like this:

One of the key things in that Conditional is that the BuildConfiguration is named “Int” (rather than “Debug”).

This just needed to be replicated in the new csproj:

As you can see they are pretty much the same.

What if you don’t want to set those values in your .csproj?

When I was trying to figure out what happened, I ran across a really cool piece of functionality that is in the new msbuild system. If you set the BuildConfiguration to “Debug” (instead of “Int”, like I had), it will automatically set the <DebugSymbols> and <DebugType> to values that will produce line numbers in your StackTraces/Exceptions. Very friendly!

ExceptionDetailConverter Example

Thanks to Alan’s sharp eyes, he saw that I had forgotten to put in examples for the IYourBussApiExceptionDetailConverter and YourBussApiExceptionDetailConverter into the post called ExceptionHandler Needed. Which was a follow-up post to Create a Custom ProblemDetailsFactory.

So, here are some examples, which should definitely be customized to fit your environments needs:

Again, Thanks for catching that!

Book Review: The Art of Business Value

Mark Schwartz’s The Art of Business Value (itrevolution, audio) doesn’t feel as similar to other DevOps books because it focus’ is on a different aspect, the CIO/MBA analysis of Business Value. It’s a shorter book than others, but that’s mostly because it takes a hard look at mathematical analysis of value propositions. And, he also has a way of bringing together ideas from multiple sources that is compact and directly associates there values for comparison.

Because the book is focused on the definition of Business Value, it needs to discuss the history of prior works which define and guide thought leadership on that topic. He goes into details on ROI, NVB, PV and others. Giving examples of how they can be applied, and in what situations they can be misleading. It can feel a bit like when The Machine That Changed the World’s started describing the equations that could put dollar values to every step and aspect in the supply chain. This is important to do, and difficult without having seen it done before. But, ultimately, his point is that the prior works don’t quiet fit right because of lost opportunity costs. And, that he hopes the work being done on new models, like Beyond Budgeting, can help teams/companies figure out the model that works for them. (There is no one size fits all approach.)

The part of the book that stuck with me was “Learning Bureaucracy vs Authoritative Bureaucracy”. Bureaucracy isn’t a bad thing, it can just go bad really fast. You have to have a balancing act between the stability and efficiencies that Bureaucracy provides and creativity and improvements that Generative cultures provide. When bureaucracy’s define standards and best practices they remove some of the chaos, but it soo easy to over-step just a little bit and create unnecessary slow downs (in the forms of approvals, reviews, audits, testing overhead) which don’t provide Business Value at the cost that they come for.

(picture from Scaling Agile @ Spotify with Henrik Kniberg)

In the end, Mark Schwartz does give some prescriptions of what could be used to help improve the understanding of business value. And, I interpret that advice as creating a Learning Culture and building knowledgeable team members (he has a lot more detail). There seems to be an overarching theme of moving away from a single person that defines what Business Value is and into a team of people that can define and test for Business Value; he even mentions Eric Reis’ Lean Startup as describing a starting model. These are some of the ways to help connect the implementers understanding of what creates business value with managements understanding. Which he notes is one of the areas that Lean Management and Agile are lacking in detail; how does management best perform it’s role in leadership and guidance and connect that vertical information flow into the horizontal business process flows?

(PS. Also check out Henrik Kniberg’s notes on Trust. In my opinion, Trust is the most important factor in creating efficiencies. And Trust vs Security is the classic debate that just does not seem to have a good solution.)

Reading ApiVersion with ASP.NET Core Versioning

ASP.NET Core Versioning is the red headed step child of the ASP.NET Core family. Unlike Dependency Injection, Routing, and HealthChecks, Versioning doesn’t have a page on the official ASP.NET MSDN documentation. What makes that odd is that Microsoft has internal REST Versioning Guidelines that they follow (AzureDevOps REST API). And, most API companies strongly suggest using versioning with APIs. But, again, Microsoft doesn’t have a page for it in their official MSDN documentation?

So, what does the ASP.NET Core API Versioning team have in the way of documentation? Their github repository, a good wiki guide, and a set of examples that can help you get started right away.

While the examples can help you get started, it does get a bit tougher when you want to do a little more advanced scenario. Here’s an example:

• Url: https://somesite.company.com/apis/v1/hr/jobs
  
• Optional header: x-comp-api-version: 1.2
  
• In the example, the /v1 part of the url segment indicates the major version of the API to use. And, the API will return the result of the latest minor version implementation of that major version. Optionally, you can override the minor version used with the optional header.

So, the ASP.NET Core Versioning team did setup a way to do a fallback. Where if the url segment didn’t contain the api version, then it could fall back and inspect the headers for an api version. But, they didn’t foresee using one convention to override or refine another convention. But, really, who would pre-plan for that scenario?

What they did do was setup an interface, IApiVersionReader, which you can use to implement your own custom logic.

But, here’s where the real problem comes in. The ASP.NET Core Versioning Team started their work back when ASP.NET was the standard language of the day. So, the .NET Core side feels a lot more like a bolt on for an ASP.NET Versioning system, rather than a subsystem specifically designed to work with the Dependency Injection subsystem of ASP.NET Core.

One of the places where this “after-thought” seems to stick out is when you try to implement an IApiVersionReader in ASP.NET Core. In ASP.NET Core …

• You do not define your IApiVersionReader within the Dependency Injection System
• You do not tell the ApiVersioning system of the type that you would like generated for each request
• Nor do you create a factory
• You do define your IApiVersionReader as a singleton instance within the ApiVersionOptions class
• And, you can only define your ApiVersionOptions class during ConfigureServices with AddApiVersioning, not in the Configure method with UseApiVersioning.

So, what if your IApiVersionReader needs a new instance of another class for each request that’s processed? Well … you can pass an IServiceProvider to your singleton instance at creation time. Just make sure you’ve got everything wired up in your IServiceCollection before creating your provider: