Contents tagged with .NET Fx Programmierung
-
Code instrumentation with TraceSource - My personal vade mecum
When writing more complex code you cannot really step through during debugging, it´s helpful to put stud it with statements tracing the execution flow. The .NET Framework provides for this purpose the System.Diagnostics namespace. But whenever I just quickly wanted to use it, it turned out to be a hassle to get the tracing running properly. That´s why I wrote down the following, to make it easier next time.
-
Software Transactional Memory VII - Automatic retry of failed transactions
My previous posting on Software Transactional Memory (STM) I concluded with the remark, NSTM was not finished. How true! Here is the next release of NSTM with a couple of improvements. You can download it from Google´s project hosting site. Here´s what´s new:
-
Software Transactional Memory VI - Becoming Aspect Oriented with PostSharp
The API for my .NET Software Transactional Memory (NSTM) I´ve described so far is straightforward, I´d say. It´s close to what you´re used to from transactional dabase access and it´s even integrated with System.Transactions: open a transaction, do some stuff with transactional objects, commit the transaction. All very explicit.
-
Software Transactional Memory V - Integration with System.Transactions
So far I´ve described my own .NET Software Transactional Memory´s (NSTM) API for managing transactions. It´s close to what you are used to from relational databases, I´d say. But still, it´s my own API and it stands beside what .NET already provides in terms of transactions. With System.Transactions there is already a general way to work transactionally across different resources like database and message queue, so it would be nice if NSTM was another such resource.
-
Software Transactional Memory IV - Thread-Bound Transactions
I´ve explained in my previous posting, how a single transaction weaves its magic of isolating changes to transactional objects (txo) and atomically making them visible on commit. But what´s the "reach" or "scope" of a NSTM transaction? How many transaction can be open at the same time?
-
Software Transactional Memory III - Making Transactions Atomic
Now that the basic data unit of my .NET Software Transactional Memory (NSTM) has been introduced - transacational objects (txo) aka INstmObject - who implement the Isolation property of transactions, the question is, where Atomicity comes from. Enter: the transaction log.
-
Software Transactional Memory II - Isolation of Changes to Transactional Objects
In yesterday´s posting I introduced my C# implementation (NSTM) of the Software Transactional Memory (STM) concept. It is supposed to make concurrent programming easier than it is today using explicit locking of shared in-memory resources. With NSTM multithreaded processing becomes as easy as accessing RDBMS from multiple applications isolated from each other with transactions.
-
Software Transactional Memory - Making multithreading easier
A while ago Carl Rosenberger - chief architect of db4o - mentioned in a personal conversation the concept of Software Transactional Memory (STM) [1, 8]. I was immediately intrigued by the idea - but the conversation went on. So I sat down later and read up on STM. And what I found made me very confident, STM was a very useful idea. Microsoft has recognized this too and is working on two versions of STM: a Haskell implementation [2, 3] and a more palatable version for mere mortal C# programmers called SXM [4].
-
A truely simple example to get started with WCF
Recently I needed to set up some simple code to demonstrate WCF (as an alternative to some other means of communication in distributed applications). But when I googled around, I could not find a really, really simple WCF example. Sure, there are lots of WCF introductions, but they all explain a lot of stuff I did not really want to know at that time. Also they most often spread the code across many files and even across languages (C# and XML). And that´s what I really, really hate! When I first try out a new API like WCF I want to have everything needed in one (!) place. I want all that´s required to be the minimum and in my favorite programming language. This way I can focus best on what´s really essential without getting distracted by syntax and unnecessary (but cool) "fluff".
-
Single Assembly Deployment of Managed and Unmanaged Code
.NET developers love XCOPY deployment. And they love single assembly components. At least I always feel kinda uneasy, if I have to use some component and need remember a list of files to also include with the main assembly of that component. So when I recently had to develop a managed code component and had to augment it with some unmanaged code from a C DLL (thx to Marcus Heege for helping me with this!), I thought about how to make it easier to deploy the two DLLs. If this were just two assemblies I could have used ILmerge to pack them up in just one file. But this doesn´t work for mixed code components with managed as well as unmanaged DLLs.