When we have to test methods that involves Entity Framework, a typical choice that we have to face is use integration tests, with an effective database, or unit tests.
If we choice the first option, with a database like SQL LocalDB, we’ll have performance problems because the cost of the database creation and the data inserts in the test startup is very high, and in order to guarantee the initial conditions we’ll have to do it for each test.
What we can do is use a mock framework that help us to mockup the entity framework context; it would be an in-memory db context, like the in-memory db context of .NET Core, that we have seen in this post.
In pratice, mocking a class means substitute the real implementation of a method with our custom behaviour; what we can do for every method of the class is…
View original post 482 more words
Stumbled upon this article written by no other than Eric Lippert listing the top 10 design faults of C# language. Here is the summary, the source to the full article is at the bottom.
#10: The empty statement does nothing for me
Reflects on the fact that lone “;” is a legal statement
#9: Too much equality
There are too many ways check for equality: ==, Equals, ReferenceEquals, CompareTo(…).
From personal experience double.NaN == double.NaN is false but double.NaN.Equals(double.NaN) is true
#8: That operator is shifty
Weirdness around << and >> operators
#7: I’m a proud member of lambda lambda lambda
The way C# 2.0 implements anonymous delegates
#6: Bit twiddling entails parentheses
#5: Type first, ask questions later
C# borrows the “type first” pattern from C and many of its other successor languages – something I got used to and the “correct” way now seems illogical to me
#4: Flag me down
The fact that you can create invalid enum values and have to manually check for this in the code
#3: I rate plus-plus a minus-minus
++i, i++, i +=1 etc. how much confusion and the pain it caused.
#2 I want to destruct finalizers
Agree with the author that finilisers in C# are symptoms of a bug. Seen it way too many times myself.
#1 You can’t put a tiger in the goldfish tank, but you can try
“array covariance” and how this could lead to run-time exceptions.
C# 7 provides a very powerful feature from the performance standpoint. This feature is returning by ref. Essentially this allows for value types to be returned without having to copy them.
The guidelines are normally that you shouldn’t use a struct with too many fields. Various sources quote various size guidelines. Whenever the struct was over the prescribed size it was recommended that you pass it by reference.
With the new syntax for returning types by reference, it’s now more convenient (no more methods returning via out parameter) to use structs.
In performance critical scenarios where you need to avoid polluting managed heap with too many Gen #0 objects using structs has now become more natural. In the past dealing with structs was somewhat cumbersome if you dealt with a large number of fields and needed to avoid copying of values.
I have worked on a large application at McLaren – Telemetry Acquisition System that is supplied to all teams. The performance of the application is very critical as it has to process gigabytes of telemetry data. We have used structs extensively to squeeze out every bit of performance from .NET runtime.
I think it’s my second favourite feature after value tuples.
I think it says a lot about the developer what sort of PC he/she has. Back when I was in my early 20 I had several:
So despite me getting older I am still a geek
The Task Parallel Library (TPL) was introduced in the .NET Framework 4, providing core building blocks and algorithms for parallel computation and asynchrony. This work was centered around the System.Threading.Tasks.Task type, as well as on a few higher-level constructs. These higher-level constructs address a specific subset of common parallel patterns, e.g. Parallel.For/ForEach for delightfully parallel problems expressible as parallelized loops.
While a significant step forward in enabling developers to parallelize their applications, this work did not provide higher-level constructs necessary to tackle all parallel problems or to easily implement all parallel patterns. In particular, it did not focus on problems best expressed with agent-based models or those based on message-passing paradigms. These kinds of problems are quite prevalent in technical computing domains such as finance, biological sciences, oil & gas, and manufacturing.
For TPL Dataflow (TDF), we build upon the foundational layer provided in TPL in .NET 4. TDF is a complementary set of primitives to those primitives delivered in TPL in .NET 4, addressing additional scenarios beyond those directly and easily supported with the original APIs. TPL Dataflow utilizes tasks, concurrent collections, tuples, and other features introduced in .NET 4 to bring support for parallel dataflow-based programming into the .NET Framework. It also directly integrates with new language support for tasks and asynchrony provided by both C# and Visual Basic, and with existing language support in .NET 4 for tasks provided by F#.
The idea is very simple, you cherry-pick the applications, click on get installer and you get the installer with all the latest applications you selected as one file.
Next time you reinstalling Windows go to https://ninite.com/ and create yourself and installation package
In all previous versions of C# (with the exception of C# 6.0 maybe) new features have revolved around a specific theme:
C# 7.0 is no exception to this rule. The language designers were focusing on three main themes:
View original post 1,825 more words
I’m not the only one who got burnt by ThreadStatic
To measure the efficiency of our analyzer, and also to promote the methodology of static analysis, we regularly analyze open source projects for bugs and write articles about the results. 2016 was no exception. This year is especially important as it is the year of the “growth” of the C# analyzer. PVS-Studio has obtained a large number of new C# diagnostics, an improved virtual values mechanism (symbolic execution) and much more. Based on the results of our teamwork, I compiled a kind of chart of the most interesting bugs, found in various C# projects in 2016.
View original post 1,367 more words