Did You Forget to Create a Nuget Package Again?

The biggest problem with managing Nuget packages for internal applications is creating and publishing the correct versions for others to consume. It’s not hard, but it does require manual steps to update the Nuspec file, create the package, and publish it. For Nuget packages which are only occasionally updated, this probably isn’t a problem. There is adequate time to develop and test it, but when using packages to keep multiple solutions in sync by using the same libraries, and all of them are under active development, it can be easy to miss one of several steps.

Automating the process is relatively easy. The Nuget Package Explorer is great for creating packages through a GUI, but it doesn’t help with automating the process of creating packages after a build. For that, there is the Nuget Command Line.

When I install it, I put it in the following location:

The following scripts assume it will be located here. If not, simply modify them to point to the correct location.

Post Build Event

In the post build events text box under the Build Events tab in the project file place the following code. It needs to be all on one line with no carriage returns.

Create the CreateNugetPackage.ps1:

Modify the AssemblyInfo.cs file and change the AssemblyVersion to have a * to increment the build number (the last zero in the series). As future versions of the assembly are created in new branches, the other numbers should be changed to reflect the current version. (2.8.1.* for Major version 2, Minor Version 8, Patch Version 1)

Now everytime Visual Studio makes a successful build, a new Nuget package will appear in the appropriate folder next to the newly created assembly:

Nugets

A full example project with it can be found on GitHub at this repo.

Are you finally going to do something about this?

There is often a lot of questions about the execution of finally statements in C#. It is a common assumption that finally blocks reliably execute, but even in the C# Reference concerning the finally block it explicitly notes this is incorrect.

Within a handled exception, the associated finally block is guaranteed to be run. However, if the exception is unhandled, execution of the finally block is dependent on how the exception unwind operation is triggered.

So what does this mean? In the event of an exception not getting caught, the finally block executing isn’t guaranteed. How does the following piece of code react?

The finally block executes, because the exception process is still being handled by the CLR and the exception information is passed to the underlying operating system…..in most scenarios. The instances where this finally example doesn’t execute is not the fault of the application, but the operating system and the user.

When the debugger isn’t attached, and the system allows the program to continue its execution path until completion, the finally block executes. With the prompt from the operating system to attach the debugger and the user’s intervention, interaction subverts the application’s ability to run it. Furthermore, any abnormally terminated program has the same issue (.NET applications don’t terminate by the operating system issuing a shutdown command and allowing the application to finish cleanup tasks). Any application killed in Task Manager, power failure, etc. won’t execute the finally block.

Outside of this, there are two other scenarios where a finally batch won’t execute (there could be other scenarios where it is prevented also, but these two absolutely won’t allow it). The first is during a Stack Overflow Exception. The program’s stack gets corrupted and the application, or thread, crashes.

There is nothing that will prevent an overflow from corrupting the stack, and the most you can do is have windows generate a dump file on crash and go through it to find the issue. (Set the following registry key to produce a dump file: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps)

The second is calling Environment.FailFast. This creates a dump of the application and terminates the process. The concerning part about this is that there is no restriction on its use. If a third part assembly accidentally invokes it (or does it on purpose for stop a security breach), the host application will close with no hope of recovery. The only upside to this is it creates a dump file and logs information to the Windows Event Log, so it can be tracked down if that appears to be the case.

Outside of the examples where the finally block doesn’t execute, a great way of catching most unhandled exceptions in code is by adding an event listener to the UnhandledExceptionEvent. This will at least allow one last chance at logging if for some reason an exception wasn’t caught.

Assuming the finally statement will run is a bad practice, but depending on what executes in the finally block, it not may not be an issue. If the application crashes before executing the code to clean up resources or log an event, this probably isn’t a problem. It however can be one if the finally block is used to manually reset state (like an account status of paying an invoice) used by other applications.