Some inconveniences of Visual Studio

I like Visual Studio and I got used to it. When I started to use VS2010 it seemed to me worse than previous version, but now I feel fine with it. But sometimes some annoying bugs happen. The most annoying thing is that some of them can cause serious damage for the project.

Some approximate list of inconveniences I have faced to:

1) Bugs with WPF editor. 

Actually, WPF editor in VS is rather bad even without any bugs. It's slow and sometimes it can fail to make a view for no reason so you should restart VS. But by my feelings it's also one of the most sensitive parts of VS which can be affected by some changes of VS. Once I had a situation when WPF editor failed to create the view and moreover failed to build a project even if it evidently had no errors. After some investigation I've found that this happened after Windows auto update which somehow affected VS. It took almost a day to figure out where the problem is and to fix it.

2) Some inconveniences with autogenerated files.

For example, for code library if I try to create new settings file, VS creates file named Settings1 and it doesn't allow me to rename it to settings because it exists allegedly. Really there is no file named Settings in the project. If you create linq to sql file (dbml) it can create Settings file automatically. Additional inconvenience appears when you try to copy and paste settings file or dbml file to another project, because VS recreates autogenerated .designer.cs files.

3) Sudden crushes of VS. 

This is one of the most annoying things which happened several times during 2 years of using VS (and my colleagues encounter the same problems). The reason of failure is usually unknown: you may have tried to change target version of .NET or something similar but absolutely legal. You are lucky if VS will work after it's restarted. 

Once I had a situation when my project had lost all compilation constants and pre- and post-build events. Several times I had a situation when solution just hadn't comliled and produced some nonexistent errors. The only way that helped was to create new solution and include existent projects into it. 

The last error that I encounter now is similar but worse: solution can be built with no errors but cannot be debugged from VS. It just throws general "Visual Studio has encountered a problem and needs to close" exception and reopens. And it happends even with blank console project within a solution. What is bad here is that the solution is in the repository and when built on the other computer it behaves the same way. Nothing including deleting .suo file and recreation of solution helped. After some time the problem was fixed by itself! I don't know what happened. 

But after the problem was fixed the new problem occured: after some changes in target platforms (x86/x64) of projects (settings have returned to initial state finally) the solution doesn't build project in the order it should. Project build order as it's shown in solution properties is right, but when I rebuild the solution, it actually doesn't rebuild projects. The way to deal with it now is to build projects one by one manually.

CodeProject

Complexity and Flexibility #2

What are the ways to balance complexity and flexibility? How do you manage the growing comlexity of your application?

There is a common situation that I met several times in my work: imagine that you have a class for object manager, say ObjMgr, and items that are stored in list inside it. Items can do some specific things and store some specific data. The code is approximately like this:

class ObjMgr
{
    List<Item> _items = new List<Item>();
    .......
    public void SetPrice(string id, double price) { _items.First(x = > x.Id == id).Price = price; }
}

class Item
{
    public string Id { get; }
    public double Price { get; set; }
    .......
}

Imagine further that the logic of setting price can be complicated. For example, you should check whether it is not negative.

Choice#1: There are several ways of doing it: in the SetPrice function of ObjMgr or in Price property of Item.
What would you prefer? It's worth doing it in the Item class, because, first, the logic can be much more complicated and it can differ for types of items. Well, it may be worth extracting the logic of setting price into separate class using Strategy pattern. If you use this approach you gain a flexibility by the price of comlexity (cause just checking for != 0 in SetPrice(...) is much simpler). Also if you do it in SetPrice(...) it doesn't satisfy dependency inversion principle from SOLID set of principles.

In the further work you may want to track if something is going wrong with new price you have set. For example, you may want to introduce some critical price difference and to log whether new price differs from the old too much. So you should log some events and thus there is a reference to some Logger in ObjMgr class.

Choice#2: There are several ways of doing it: the simplest one is to simply check the difference in ObjMgr's SetPrice function and to log the result using ObjMgr's logger, the second one is to check it inside the item.
Again, what would you prefer? For the same reasons, it's worth doing it in the item class and may be to use Strategy pattern again. And here another problem arises: Item doesn't include a reference to Logger. So you should solve this problem.

Choice#3: How to add logger reference to an Item? Here are some ways: first, you can add a reference directly and to make it the same reference as ObjMgr's one in the constructor; second, you can make a ref to ObjMgr's logger public and to add ref to ObjMgr itself; third you may make Logger class singleton or even a static class; forth you may add event to an Item and handle it in ObjMgr (or do the same thing using Observer pattern).
Again there is an option. Two first approaches are comparatively simple, but there is no need for Item to know about the existence of ObjMgr and logging is not a natural part of Item. Third approach also has a disadvantage - if it's a singleton, it cannot contain some info specific for current ObjMgr (for example, path to log into). Fourth one seems the most flexible but it is also the most complicated.

These choices are domain-specific (fo example current domain precludes that for all types of Items price should be checked not to be 0 with no special cases, so there is no need for Strategy pattern), but even with knowledge of domain this choice is fuzzy.

As a result, if you use the way of simplicity, the code becomes a total mess after some iterations of changes. The problem as I see it is that the way of flexibility turns the initial clear code turns into much bigger and more comlicated code which consists of many classes and hierarchies and which is in fact a different type of mess. There is a problem to reach a subtle balance between complexity and flexibility within current domain.


CodeProject

On simplicity

Simple solutions are better in many cases. In fact, with experience comes feeling that flexibility is often overestimated. Sometimes this is hard to choose the best value of flexibily.

Here is one example of unnecessary flexibility.
In one of my projects there is some working algorythm running on server which is managed from client side. There are different ways to establish such a management:
1) Client sends new parameters to server and server immediately changes parameters that are in use.
2) Client changes data in DB (directly or through server). Then data is loaded by the server.

In the project I'm talking about I've chosen the latter. And I've decided to make immediate renewal of these parameters using some service that notify about the change in DB. In SQL Server there is Service Broker for this case which should be turned on to allow such a notification.

In the code (for C#) you can use SqlDependency class. Here are great tutorials for it:
SqlDependency example
Also, there are some limitations for it.
Limitations of SqlDependency

Usage of SqlDependency seems a little bit clumsy for me so I've found some open source wrapper (that was a good wrapper, but unfortunately I can't find the reference), changed it for my needs and used it in my project.

Well, the way described now doesn't seem to be the best way.
First of all, all of this seems to be overcomplification of the problem.
Second, if something changes in the DB, the notification comes immediately. When data is changed you should decide whether the data change should stop execution of algorithm or changes are such that you can replace some parameters on the fly.
Third, if client makes some substantial changes consequentially, every such change will affect the base and algorythm.

For my current experience, it's better to:
1) Not to use SqlDependency in such scenario (but this doesn't mean that this technique is not useful, there can be situations where it's necessary).
Here DB plays a role of proxy between client and server. It better to make some other type of connections between them.
2) Divide parameters of the algorythms into several groups:
Static parameters (settings) which are the most essential parameters of the algorythm.
Dynamic parameters which can be changed on the fly.
Optionally one can introduce also observable only parameters which cannot be changed be client.
3) Divide client application into two parts:
Settings part, where static parameters can be changed.
Management part, where dynamic parameters can be changed.
4) Introduce a "reset button" for a client to manually reload server if some settings are changed.

Using shared function from different blocks II

I've decided to use simple way to share a function which presumes that block B uses parameter space P. This can be implemented in the easiest way just by sharing value p. In this scheme block A uses a known parameter space P, so does block B. Block B includes some class which incapsulates calculation with known algorythm which uses parameter p received from block A.

This way is much less interesting and not so "fuzzy", cause it uses some predefined algorythm for creating value p in block A and predefined algorythm of using this value.

But a task with serializing function with dependencies from outer scope is still interesting problem to solve.

Using shared function from different blocks I

Now at my work I face an interesting problem: I should provide a solution with a mechanism of generating functions dynamically and to transfer it to some another algorythm. The scheme of the solution isn't clear enough by now, so I don't know how I will create these functions, but here I'd lie to talk about function transfer.
Here is a robust scheme of the problem:

x = incoming data (space X)
y = transformed data (space Y)
[Block] A -----> creation of function F: x -> y
[Block] B -----> applying F: F(x) = y

The decision to break solution into these two blocks comes from the fact that creation of F can involve great amount of data and CPU time. On the contrary, block B should work as fast as possible using current function F for transformation. Actually, block A and block B can even work on different servers. So function F should be serialized somehow and transfered to the block B.

Creation of F involves creation of some value in parameter space and it acts using some parameter p, which is created based on some stored amount of data {x}, so, actually, there exist some function W: {x} -> p (from space P) and F: x, p -> y. The question is whether block B should know about the parameter space or not (In my opinion it shouldn't cause of black box principle).

To be exact I'll describe an example for what I'm trying to do:

x = 1,2,3.....
y = 0,1

The algorythm stores some 10 values of x and then it creates a parameter space, which consist from only one value p=2 (W: {1,2,.....10} -> p=2). Then function F is created in such a way: F x, p -> y = x mod p. If block B doesn't know about the parameter space then F is transformed into F': x -> y = x mod 2 and then trasfered to block B. If it knows about parameter space then one can leave F as it is and transfer it without transformation + transfer value p = 2.

The second question is how to implement this architecture in C# (as it is primary language solution uses). Concerning delegate serialization one of the features of .NET is that Func<...> delegate is serializable, but it is so only if Func doesn't use variables from outer scope. For example:


        private void FuncTest()
        {
            // will serialize OK with binary formatter
            Func<object, object, int> func = (o1, o2) => o1.GetHashCode() | o2.GetHashCode();

            // fails to serialize
            int i = 10;
            Func<object, object, int> func2 = (o1, o2) => (o1.GetHashCode() | o2.GetHashCode()) + i;
        }


Assuming block B knows about the space P, one can consider the following solution: in block A you just accurately create a Func<P,X,Y> or some wrapper around it, insisting that P is serializable. Then one can serialize this function and some p from the space P and then create Func<X,Y> which always uses deserialized value p and deserialized Func<P,X,Y>.

This is what is needed here, but the situation can be more complicated if there are many spaces of P. That's the reason (besides some considerations of beauty and black box) I don't want block B to know about some inner spaces for block A.

If one assumes that P is hidden in the block A then situation becomes more sophisticated. The way to move on is, in my opinion, Expressions and ExpressionVisitors from System.Linq namespace. Actually, I've never used them and even didn't know about them until now. But (Linq impresses!) they seem to be powerful and flexible instruments. The way I'm currently thinking at is to make an expression (note that lambda syntax for Expressions is not equal to that for Delegates, so some conversion from Func to Expression might be needed, I was rather surprised by this) and then (when serializing) to replace all expressions in it with current values of parameters if the expression doesn't use exact parameters for the Func<X,Y>.

The task that seemed an easy thing initially is not finished yet.

A little unobvious error

Here I describe one error I've done which might seem not obvious at first sight. (The code in this post is C#)

The following situation occured at my work recently. Some class was declared approximately as follows:

    public class SomeClass
    {
        private volatile int _x1; 
        private volatile int _x2;


        public int X1
        {
            get { return _x1; }
            set
            {
                System.Threading.Interlocked.Exchange(ref _x1, value);
                CheckForDone();
            }
        }
        public int X2
        {
            get { return _x2; }
            set
            {
                System.Threading.Interlocked.Exchange(ref _x2, value);
                CheckForDone();
            }
        }
        public int X { get; set; }


        public bool IsCompleted { get { return X1 == X && X2 == X; } }


        private void CheckForDone()
        {
            if (IsCompleted)
                RaiseDone(new EventArgs());
        }


        public event EventHandler Done;
        private void RaiseDone(EventArgs args)
        {
            if (Done != null)
                Done(this, args);
        }
    }

Here is the situation: variables _x1 and _x2 are incremented in some unknown order (from different threads) until both of them reach value X. When each variable achieves new value, CheckForDone function checks whether both values have reached X and if they had then some event is fired. Thus last variable which reaches X fires this event.

The problem is that Done event fires twice sometimes (this is undesirable behavior). This often happened with first actuation of Done event - due to jitter lags, I think. The reason is, of course, that IsCompleted and setters of X1 and X2 are not some atomic operations. Then first thread calculates X1 == X (which is, say, true), X2 changes (X2 == X becomes true) and fires another CheckForDone function. In this case IsCompleted returns true in both cases and event fires twice.

There are several ways to solve the problem and I've chosen the simplest one: I added a variable which indicates whether Done event had already fired or not.

        private volatile int _doneFired = 0;
        public bool DoneFired
        {
            get { return _doneFired == 1; }
            set { System.Threading.Interlocked.Exchange(ref _doneFired, value ? 1 : 0); }
        }

Then CheckForDone is modified in following way:

        private void CheckForDone()
        {
            if (IsCompleted && !DoneFired)
            {

                // problem zone
                DoneFired = true;
                RaiseDone(new EventArgs());
            }
        }

It was obvious enough but here are some errors and, surprisingly, the problem occured again.

The error here is that both threads can occur in the "problem zone" before one of them had set DoneFired to true. The solution is to use CompareExchange instead of Exchange method that guarantees that both comparing to true and setting to true is performed as atomic operation. So the code for DoneFired has to be written in the form:

        public bool DoneFired 
        { 
            get { return System.Threading.Interlocked.CompareExchange(ref _doneFired, 1, 0) == 1; } 
        }

        private void CheckForDone()
        {
            if (IsCompleted && !DoneFired)
            {
                RaiseDone(new EventArgs());
            }
        }

Sure, the problem can be solved in another, more obvious way - by introducing a lock on some object that guarantees that DoneFired will check for true and change only once, but lock works significantly slower and this can be crucial in some scenarios.