Contents tagged with .NET General
-
Optimizing memory usage
In this post I’ll discuss some memory optimization work I’ve done recently on the LLBLGen Pro runtime framework, v5.3.2. This is a popular (commercial) .NET ORM. LLBLGen Pro is on the market since 2003 and has seen a lot of refactoring work internally over the years, among them performance optimizations and memory usage optimizations. With new features come new challenges to make the overall framework perform the same or even faster and still perform the new features as well, so optimizing the core engine is a recurring effort.
-
LLBLGen Pro v5.3 Beta has been released!
We've released LLBLGen Pro v5.3 beta! Since the EAP we’ve added new functionality and tweaked some things too, based on feedback. Below is the full list of what’s new in v5.3 Beta, and this is also the list of new stuff we’ll include in v5.3 RTM, which is expected within a week or two.
-
The .NET support black hole
Today I ran into a bit of an issue. A work-item for LLBLGen Pro v5.1 is to support all the new features of SQL Server 2016. One of the features of SQL Server 2016 is ‘Always Encrypted’. You can enable this feature through the connection string, and after that all data-access is encrypted, no further coding needed. As this is a connection string setting, it’s enabled in every ORM out there out of the box, also in ours. That’s of course not the problem. The problem is adding more control over this feature to the developer writing code which targets SQL Server 2016.
-
LLBLGen Pro v5.0 RTM has been released!
After 1235 commits and 20 months of full time development, the work is done and we’ve released LLBLGen Pro v5.0! To see what’s new, please go to the official ‘New features’ page on our website, or read about them on this blog in the Beta announcement post.
-
Greener grass
This morning I read the blog post 'Life with a .NET' by Jon Wear. It's about leaving .NET / the Microsoft platform for the great unknown 'outside the Microsoft world'-universe, and it's a great read.
-
LLBLGen Pro v4.2 BETA has been released
This morning we've released LLBLGen Pro v4.2 BETA! The beta is available to all v4 customers and can be downloaded from the customer area -> v4.2 section.
-
Jetbrains' InspectCode result file viewer
Yesterday I was looking for some C# analysis tools, but they either were very expensive or came with add-ins like Resharper. Nothing against these add-ins except that I'm not very fond of having loads of extensions in my IDE as it feels like they slow down the IDE too much at times. That can be me, or the solutions I work with, that doesn't really matter, I simply can't stand the slowness. There's however a solution for that, Jetbrains have been so kind to release their Resharper analysis engine as a free commandline tool. This tool does all the analysis solution wide like Resharper but when I want it to do so, which is excellent. The downside is… it produces an xml file which isn't that useful without some tool.
-
re: Create benchmarks and results that have value
Kelly Sommers wrote a blogpost called 'Create benchmarks and results that have value' in which she refers to my last ORM benchmark post and basically calls it a very bad benchmark because it runs very few iterations (10) and that it only mentions averages (I do not, the raw results are available and referred at in the post I made). Now, I'd like to rectify some of that because it now looks like what I posted is a large pile of drivel.
-
Fetch performance of various .NET ORM / Data-access frameworks, part 2
This is the second post about fetch performance of various .NET ORM / data-access frameworks. The first post, which has lots of background information can be found here. In this second post I'll post new results, including results from frameworks which were included after the previous post. The code used is available on GitHub. I'd like to thank Jonny Bekkum for adding benchmark code for many of the frameworks which were added after the previous post.
-
Microsoft and developer trust (or lack thereof)
There has been some talk around several internet outlets about the (seemingly) eroding trust developers have in Microsoft and its techniques (see David Sobeski's piece here, Tim Anderson's piece here and e.g. the Reddit Programming thread here). Trust is the keyword here and in my opinion it's essential to understand what that means in the context of a software developer to understand the problem at hand, or even to acknowledge that there is / isn't a problem. I try to explain below what I think trust means in this context.