Bruno Peeters Technical Blog

NuGet packages eases the reuse of components. A NuGet package can contain different kinds of resources, like libraries, or header files. These resources are packed in a NuGet package. You can use a package in your solution and refer to one of the resources in the package.

During development, it can be convenient to just create your NuGet package locally and test it locally. Therefore you don’t need to set up your own hosting environment, like for example Artifactory, you just can host your packages on a local disk. Although the scenario where you publish your package to an external host is rather described everywhere, the latter one is a scenario that is interesting as a workaround not having to publish your package you are developing directly to an external source.

We will look at how to define the content of your NuGet package, create it, store it locally and eventually consume it.

In an older post, I suggested that constructors never should call methods, which possibly can throw exceptions. What also that blog entry explained, is that this idea mainly came from unmanaged languages like C++, where you could easily introduce memory leaks when a constructor throws an exception.

I however came back from that idea, since it also pollutes a lot of your code having to have initialization methods. You add hereby a unspoken contract that, after calling the constructor, you have to call the initialization method in order to use the class properly.

RhinoMocks is a framework for creating mocked instances, that can be used within unit tests. Since the framework is not to be maintained anymore (last version was in 2010), you can’t use RhinoMocks for example within .Net Standard or .Net Core projects.

A project I was working on was having the same struggle; we had quite a large set of unit tests that where using RhinoMocks. For several reasons, we decided to migrate our projects to .Net Core, which made it impossible to use RhinoMocks anymore. We decided to switch to the Moq framework. In this blog I summed up the most used RhinoMocks constructions and how to port them to Moq.

When running a task asynchronous in an asynchronous environment, you can catch exceptions as you just using asynchronous code. When an exception occurs, C# will catch any exception and put it into the Task that will be returned to the caller. Furthermore, the Task becomes Faulted. The exception will be thrown now at the place where the await is put to wait for the result of the asynchronous call which caused the exception.

This changes however when calling a asynchronous task in a synchronous way.

Assume you have a layered system, build-up using the separation of concerns principle. We have a UI layer, a services layer and a database layer. The UI layer communicates with a service layer, which communicates with a database layer. As the names describe, the UI layer is responsible for showing an UI to the user, the services take care of main logic of the application and the data access layer communicates internally with a database.

Some argue that you shouldn’t have multiple return paths within our code. What are the benefits of having just one entry and one exit point?

Readability

You will keep the flow simple by having just one entry point and one exit point where the result is returned. In this case the code will be easy to read: you can simply read where the value is changed and where the end result is expected.

Controlling your object lifetime cycle

The main origin of the argue having only one return path, has its origin at languages like C or C++. In these languages you actually have to allocate memory when you want to use an instance of an object and deallocate it when you don’t need it anymore. If you forget the last one, you end up with memory leaks. Let’s say you create the instance and after that you return a value when some condition isn’t met. In this case, the line where your object is deallocated will not be called anymore.

A valid use: checking preconditions

A valid point where you could enter multiple return paths is at the beginning of a method, where you check the preconditions of your method. If a user of your method passes invalid arguments, you can quickly return a default value then have additional checks in your code.

Events in C# use the observer pattern, where an observer can subscribe itself to event generated by a subject. Within C# the observer can subscribe itself multiple times to the subject. When the subject fires the event, the observer gets multiple events.

The best way to prevent is to be keen on the life-cycle of your events; subscribe at the right place at an event en un-subscribe from the event also at the right place. How can we have a defensive mechanism, that prevents us subscribing multiple times at an event?

Read More…

With the release of Visual Studio 2017, C# 7.0 saw the light. By downloading the community edition of VS 2017, you can use the new .Net version right away. In this post, I will walk through the new language features, which mainly focus on data manipulation.

Read More…

Within C++, you have the const keyword, that can be used to say to the one which calls the method that the argument which passed through the const parameter won’t be changed within the method. This is merely adding a contract. Sure, the compiler does some checking for you, but still it is possible to change the value of your const parameter. See for example this nice example (obtained from https://isocpp.org/wiki/faq/const-correctness#aliasing-and-const):

Read More…

Sometimes your application requires to run with administrator rights. For example to access some restricted resources on a computer. Within .Net we can adjust our application in such a way, the user is asked to run the application with elevated administrator rights. In this way the application is executed with administrator rights, hence has less restrictions. Downside of this is that also more harm can be done with bad written code (think of erasing all files on the harddrive of a user).

Read More…