Posts

Showing posts with the label C#

Entity Framework Core, SQL Server, and Deadlock victims

The application I am currently working on loads text files, transforms them, and then saves them as relational data. I use Entity Framework Core with SQL Server for my persistence. Unfortunately, when inserting so much data I keep experiencing exceptions because SQL Server is throwing deadlock exceptions and preventing my data from being saved. The insert involves data for 4 related tables, every access to the DB is an insert, which is why I was so surprised to see SQL Server couldn't cope with it - especially as Firebird SQL didn't struggle (nor did PostgreSQL).  It seems that adding OPTION (LOOP JOIN) to the end of SQL Statements prevents this problem, so I wrote an extension to ensure it is appended to Entity Framework Core generated SQL. It is used like so: protected override void OnConfiguring(DbContextOptionsBuilder options) { base.OnConfiguring(options); options.UseLoopJoinQueries(); } and the extension code you need is: public static class UseLoopJoinQueriesExte

Generating globally unique mostly-sequential keys for DB rows across multiple processes

Note: This agorithm was co-authored by Phillipa Berresford. I wanted my domain classes to be able to reference each other by Id without having to add association properties - as I felt having all of this navigation in the model made it messy. I'd much rather have association properties within my aggregates (PurchaseOrder to PurchaseOrderLines) but not elsewhere. This was okay when I needed to add a reference to an object that already existed in the DB, but when I was adding a reference to a new object I needed to know the object's Id before Entity Framework Core saved it to the DB. As my tables were using DB assigned incrementing INT columns this was not possible, so it become obvious I was going to have to switch to GUID Ids. The problem with using GUIDs as clustered primary keys is that GUIDs are designed to be random. Whereas an auto-incrementing INT key will always result in new rows being appended to the end of a table, GUID keys would result in new rows being inserted

Silent errors

I'm working on an app which uses a 3rd party library for producing SWF and FLV files. For some reason the trial worked perfectly but when I switched my app to the full version there was no audio output. We'd been looking at this problem for a while, emailing support etc, but just couldn't see what was wrong. It wasn't until I went back to my proof of concept app and ran it that we realised the full version did produce audio, it was just my main app that wouldn't work properly. Then I spotted the error... var compressor = new TVE4(); compressor.LoadSettings(SettingsPath); compressor.SetOutputFile(outputFileName); compressor.EncodeSequenceAudio(Composition.EffectiveProductionAudioFileName); compressor.Key1 = 12345; compressor.Key2 = 54321; (loop to encode frames) Do you see the error? It was only as I switched between the proof of concept code and my app code in the IDE that I noticed the two following lines moving up and down... compressor.Key1 = 12345;

Perceived speed

I'm writing an app which basically performs the following steps in a wizard-like interface: Select an audio file of someone speaking + loads a text script in. Process the audio file and the script, can take about 5 seconds for a minute of audio. Select a character to use in the animation. Select some additional graphics and scene settings. Use the data generated in step #2. Sitting there for 5 seconds wasn't really a problem, not to process a 1 minute audio file. A longer audio file would take a little longer, but 10-15 seconds is okay, isn't it? Well, what if I could make it take no time at all? Obviously I can't, but I can make it look like it takes no time at all. The fact is that I don't need the processed data until Step 5. The user will probably spend at least 30 seconds twiddling settings in each Step 3 and 4. How much processing power does a bit of GUI interaction take? Hardly any at all! So I made Step 2 run in a separate thread. As soon as the user

Data Transfer Objects

My observations on data transfer objects They should not be a one to one representation of your domain classes. Sometimes you want a subset of the information of a single instance, sometimes your DTO will collect data from various instances (starting with an aggregate root ). You might create different types of DTO from the same domain classes based on what the user needs to do. Sometimes the user only wants OrderNumber + DateRaised + TotalValue (to show as a list of orders), sometimes they want the entire order details (including lines) for editing. The domain classes should have no knowledge of your DTO classes. So you shouldn't have any methods such as pubic PersonDto CreateDto(); public UpdateFromDto(personDto); DTO's are not part of the business domain, so you should never do this! The DTO you send out might not be the same type as you get back. For example you don't want the user to edit the order number or the date raised. If there are only a couple of properties

How often should I test?

I am lazy.  I don't mean that I don't work, I mean that I like to get my work done with as little effort as possible.  Writing tests before my code used to look like too much extra work, but I've realised just how much time they actually save me. When you make a small change to something it's very easy to think to yourself "That's such a small change, I can't see how it can possibly fail", what I have also realised is this really means "Despite this being a small change, it will fail and I can't possibly see how". I recently observed a change to some code that introduced a simple if statement, and all existing tests passed.  The problem is that the existing tests only checked the expected behaviour worked (which it still did), but by introducing the "if" statement (and an additional parameter on the method) the developer had changed the expected behaviour under certain circumstances .  Thinking it was so simple it couldn't p

How I would like to write code

Image
Aspect Oriented Programming looks great. It's something I have always wanted to use, but I avoid it because it doesn't work exactly how I would like it to. The first thing I want to avoid is lots of reflection at runtime (compile time is fine), it is for this reason I have mainly been interested in PostSharp . PostSharp looks great! You decorate your class with attributes that you create yourself. After compiling your assembly PostSharp inspects the result for Attributes that are descended from one of its own special PostSharp AOP classes. When it sees these attributes it modifys your code in a specific way. To use the same example as everyone else in the world (yawn) you could create an attribute from the method-boundard attribute. Override the methods declared on that attribute for entry/exit of the method, and write some code in there to write to the IDE's output window using System.Diagnostics.Debug.WriteLine(). Now when I add that attribute to a method on one of my cla

Sufficient architecture

I have a friend who once decided to teach himself VB. We had a mutual friend who was the manager of a video shop so he decided to write some new software for him. He started off by creating an MS Access database to hold the data for his application. Each week I'd pop around to his house and he'd have MS Access open, reworking his tables etc. After a few months I asked "Have you started to write the app yet?". "No, not yet." He replied, "I am trying to get the DB right first, then I will get onto writing the application". I asked what he meant by getting the DB right. He explained that he wanted to make this the best video-hire software ever, and that I should hear about some of the features that are going into it as a result of the DB structure he has made. Record the cast of the film. Record the director, producer etc. Record the genre; horror, comedy, etc. Record film information for films due to be released in the future. All sorts of stu

Accommodation manager - runtime error

I've just spotted something I omitted before zipping up my AccommodationManager app and making it available. When you run the app in Release mode you will experience SQL errors. These errors are intermittent, and a query that worked only seconds ago might not always work. The reason for this is that ECO executes all queries within a transaction; SQLite creates a journal file for every transaction and then deletes it when done; and my anti-virus decides it wants to take a look at this new journal file to see what's inside it; resulting in SQLite not being able to open its own journal file exclusively. This was something I noticed a while ago in another ECO+SQLite app of mine and the guy who writes the library spent a couple of hours with me on MSN trying to work out what the problem was (he had a fix to me by the next morning!). Anyway, I have updated the project so that the connection string tells SQLite not to delete the journal file when it has finished with it, as a conse

ECO, Winforms, ASP.NET, and WCF

The technologies I used in an app I wrote for friends recently. The app manages properties at different locations, bookings, and tariffs. In addition to this the application (which uses SQLite) connects to their website using WCF and updates their database so that people can check prices and availability. I need to get them using it now so that there is data available by the time I put up their website .

Implementing complex unit testing with IoC

I have a method that looks something like this public void DoSomething(SomeClass someInstance, User user) {   var persistence = someInstance.AsIObject.GetEcoService<IPersistenceService>();   persistence.Unload(someInstance.AsIObject());      if (someInstance.CurrentUser != null)     throw new ..........;   someInstance.CurrentUser = user;   persistence.UpdateDatabase(someInstance); } This unloads the local cache before ensuring someInstance.CurrentUser == null, it then sets someInstance.CurrentUser and updates the DB. The unit test I wanted would check what happens when two users try to perform this at the same time. What I wanted was User A: Unload User B: Unload User A: Check == null, it is User B: Check == null, it is User A: Change + update DB User B: Change + update DB + experience a lock exception What I didn't want was User A: Unload User B: Unload User A: Check == null, it is User A: Change + update DB User B: Check == null, it isn't To achieve two things runnin

Unit testing security

Following on from my previous post about using(Tricks) here is an example which makes writing test cases easier rather than just for making your code nicely formatted. Take a look at the following test which ensures Article.Publish sets the PublishedDate correctly: [TestMethod] public void PublishedDateIsSet() {   //Create the EcoSpace, set its PMapper to a memory mapper   var ecoSpace = TestHelper.EcoSpace.Create();   //Creat an article   var article = new Article(ecoSpace);   //Create our Rhino Mocks repository   var mocks = new MockRepository();   //Mock the date/time to give us a predictable value   var mockDateTimeService = mocks.StrictMock<IDateTimeService>();   ecoSpace.RegisterEcoService(typeof(IDateTimeService), mockDateTimeService);   //Get a date/time to return from the mock DateTimeService   var now = DateTime.Now;   using (mocks.Record())   {     //When asked, return the value we recorded earlier     Expect.Call(mockDateTimeService.Now).Return(now);   }   //Check mo

Single instance application - revisited

Not so long ago I posted a solution to having a single-instance application. Rather than just preventing secondary instances from running the requirement was to have the 2nd instance pass its runtime parameters onto the 1st instance so that it can process them. My solution used remoting on the local machine. This appeared to work very well until recently when I needed an OpenFileDialog. Attempting to show the dialog resulted in an error about COM thread apartments. So, it wasn't THE solution. After a bit of research I decided to use named pipes instead. This meant I had to upgrade my app from .NET 2 to 3.5, but I think it is worth it. To implement the feature in an app you need to do 2 things. First you need to realize the interface ISingleInstanceApplicationMainForm on your app's main form in order to accept command line arguments from any subsequently started instances. Next you need to change your Program.Main method like so: [STAThread] static void Main(string[] ar

using(TricksToFormatYourCodeNicely)

I've been writing a data importer which takes a specific data input format and outputs XML, this XML is then imported within my application. What annoyed me was the way in which the source code was formatted.... writer.WriteStartElement("data"); writer.WriteAttributeString("1", "1"); writer.WriteAttributeString("2", "2"); writer.WriteAttributeString("3", "3"); writer.WriteStartElement("systemData"); writer.WriteAttributeString("a", "a"); writer.WriteAttributeString("b", "b"); writer.WriteEndElement();//systemData writer.WriteEndElement();//data It just didn't look nice. I thought about splitting it into separate methods, but most of the time this would have been overkill as the methods would have been very short. Instead I wrote an extension method on XmlWriter: public static class XmlWriterHelper {   public static IDisposable StartElement(this XmlWriter wr

Validating NumericUpDown on compact framework

A customer requested that instead of my NumericUpDown controls silently capping the input value within the Minimum..Maximum range it instead showed an error message telling the user their input is incorrect and that they need to alter it. I was a bit annoyed to see that NumericUpDown.Validating is never called on the compact framework, in addition there was no way to get the input value and either accept or reject it before it is applied to its data bindings. There's an article here which shows how to implement auto-select text when the NumericUpDown receives focus and I have been using it since Feb 2006. I decided to extend upon the techniques within it to implement the Validating event. My goal was to fire the Validating event before the value is applied to all data-bindings, but also to allow the programmer to read NumericUpDown.Value in order to determine the new value. To do this I had to replace the WndProc of the control so that I could handle the WM_UPDOWN_NOTIFYVALUECH

Single instance application

An app I am working on needs to be a single instance. It is associated with certain file extensions so that when I select a character or license file it will be imported automatically. When the user buys a character or license (etc) from the website it will be downloaded and opened, and then imported. Obviously it is a pretty poor user experience if they have to close the app, download, close the app, download... So what I really needed was a way to have the 2nd instance of the application to invoke the first instance and pass the command line parameters. Here is a simple solution I implemented using remoting. 01: An interface public interface ISingleInstance { void Execute(string[] args); } 02: A class that implements the interface public class SingleInstance : MarshalByRefObject, ISingleInstance {   private static object SyncRoot = new object();   private static Form1 MainForm;   static SingleInstance()   {     Application.EnableVisualStyles();     Application.SetCompatibleText

More leak fixes

I have changed the DirtyObjectCatcher so that it initially only hooks Form.Disposed - Automatically disposes the DirtyObjectCatcher Form.Closed - Unhooks all additional form events (below) Form.Shown - To hook additional form events (below) ==Additional form events== Form.Activated Form.MdiParent.Activated Form.MdiChildActivate The additional events are to ensure that the DirtyObjectCatcher's undo block is moved to the top. The reason that these events are now unhooked is so that there is no strong event references from the application's main form (Form.MdiParent) to this component, keeping it alive. Now we only have long-term event references from the owning form itself. Really though this is just an added precaution against something I may not have thought of :-) The true memory saver comes from only holding a WeakReference to the owning form. Otherwise in an MDI application we have the following MainForm.MdiChildActivate->DirtyObjectCatcher->Form In such a case c

Memory leaks

As a follow up to yesterday's post here is a list of problems I found... 01: The following code for some reason causes the form holding the DirtyObjectCatcher to remain referenced. if (Owner.MdiParent != null) { Owner.MdiParent.Activated += new EventHandler(MdiParent_Activated); Owner.MdiParent.MdiChildActivate += new EventHandler(MdiParent_MdiChildActivate); } The odd thing about this is that it really is the events that matter! I subscribe Shown, Disposed, Activated on the Owner (which is a form) and that doesn't cause the same behaviour. The reason is that the Owner normally gets disposed and takes out the DirtyObjectCatcher with it, however, if I have Owner.MdiParent events referencing DirtyObjectCatcher then the form will never get disposed because DirtyObjectCatcher has a strong reference to Owner. Maybe I should change it, but for now the Shown and Activated events seem to be doing the trick. 02: This one was a real pain! DirtyObjectCatcher creates its own Undo

DirtyObjectCatcher

Oh boy, what a nightmare! After days of messing around I finally found where the memory leak is in my app, it was in DirtyObjectCatcher! The DirtyObjectCatcher used to subscribe to the DirtyListService, so that it was notified whenever an object was made dirty. I experienced this problem... 01: User creates a "Call" to a customer site. 02: User edits a purchase order. 03: Save purchase order (merges the undo block to the Call undo block and closes the form) 04: Edit the purchase order again from the Call form The PurchaseOrder is already dirty so it wont get triggered again, this used to result in no constraints being checked etc and the possibility of entering dodgy data. The solution at the time was to have a static list in DirtyObjectCatcher private List Instances; whenever a new instance was created it would be added, whenever Dispose was called it would be removed. I then hooked into the cache chain and whenever a value changed I would call a static method on DirtyObjec

Making a generic type from a Type

List<Person> p = new List<Person>(); This works fine, but what about this? Type someType = typeof(Person); List<someType> p = new List<someType>(); Nope! But you can do this... Type genericType = typeof(List<>).MakeGenericType(someType); Why would I want to? Because I am creating a tool that generates plain old .NET objects from an EcoSpace's model, and I wanted to implement multi-role association ends as public List<Building> RoleName; rather than just public Building[] RoleName;