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.

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.

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…

When I encountered this warning during compiling, I went searching what this warning really caused. It happened that somehow I had two separate files, having the same name. Due to this, the compiler warned me about this design flaw. When I searched on the internet on this warning, I saw a lot of posts of people who suggested to change the project settings of Visual Studio. Read More…

When compiling one of my C++ projects, the compiler displayed the error “error d8016 ‘/clr’ and ‘/mtd’ command-line options are incompatible”. I had checked all both the options for “CLR” (Common Language RunTime Support) in “Configuration Properties”->”C/C++”->”General”->”Common Language RunTime Support” and the options for “MTD” (Multi-Threaded Debug) within “Configuration Properties”->”C/C++”->”Code Generation”->”Runtime Library”, the places the compiler complained about. However, I didn’t see anything conflicting options here. CLR was disabled for my project.

After some time, I saw that only one of the files had a different setting. So in case of these errors, and you can’t solve them via the global project properties, check also the properties of the individual files. They might have a different setting!

My problem was solved by going in the project properties to “Configuration Properties”->”C/C++”->”General”->”Common Language RunTime Support” and set it to “No Common Language RunTime support”.