Saturday, October 31, 2009
I believe that many of us find ourselves writing a code that checks if object already exists in collection before we add it. The purpose of this check is creating a collection which holds unique objects, or simply a math set.
A HashSet is a collection that contains no duplicate elements, with no particular order. It was introduced in .NET framework 3.5 and provides high-performance set operations.
Since this object was modeled as mathematical set, it supports common set operations like Union and Intersection.
A HashSet has Add method which returns a boolean result indicating whether an element was added to collection or not (in case it already exists).
HashSet Using Example
HashSet<int> set1 = new HashSet<int>();
set1.Add(1); //won't be added
HashSet<int> set2 = new HashSet<int>();
//Produces an united set by using Union method.
HashSet<int> unionSet = new HashSet<int>(set1.Union(set2));
//UnionWith - modifies set1 itself.
//Produces an intesected set by using Intersect method.
HashSet<int> interectSet = new HashSet<int>(set1.Intersect(set2));
//IntersectWith - modifies set1 itself.
You can see the complete HashSet documentation here.
Wednesday, October 28, 2009
1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?
The nice thing about this test is that it's easy to get a quick yes or no to each question.
Give your team 1 point for each "yes" answer.
A score of 12 is perfect, 11 is tolerable, but 10 or lower and you've got serious problems. The truth is that most software organizations are running with a score of 2 or 3, and they need serious help, because companies like Microsoft run at 12 full-time.
Of course, these are not the only factors that determine success or failure: in particular, if you have a great software team working on a product that nobody wants, well, people aren't going to want it. And it's possible to imagine a team of "gunslingers" that doesn't do any of this stuff that still manages to produce incredible software that changes the world. But, all else being equal, if you get these 12 things right, you'll have a disciplined team that can consistently deliver.
You can read the complete Joel's post here.
Wednesday, October 21, 2009
As we all know,Microsoft is coming to release the new version of Visual Studio and .NET framework - Visual Studio 2010 with .NET framework 4.0.
If you're interested to get an early look of C# 4.0 upcoming features, this post is for you.
Generally, there are four main additions introduced in the new version:
2.Named and Optional Arguments
3.Improved COM Interoperability
4. Variance and Contravariance
We will take a look at first two features: Dynamic Lookup & Named and Optional Arguments
Dynamic lookup allows you to write method, operator and indexer calls, property and field accesses, and even object invocations bypass the C# static type checking and instead gets resolved at runtime.
With dynamic lookup, when you have an object in your hand you do not need to worry about whether it comes from COM, IronPython, the HTML DOM or reflection.
A dynamic object is assumed at compile time to support any operation, and only at runtime will you get an error if it wasn’t so.
The dynamic type
C# 4.0 introduces a new static type called dynamic.
When you have an object of type dynamic you can “do things to it” that are resolved only at runtime:
dynamic d = GetDynamicObject(…);
Not only method calls, but also field and property accesses, indexer and operator calls and even delegate invocations can be dispatched dynamically:
dynamic d = GetDynamicObject(…);
d.M(7); // calling methods
d.f = d.P; // getting and settings fields and properties
d[“one”] = d[“two”]; // getting and setting thorugh indexers
int i = d + 3; // calling operators
string s = d(5,7); // invoking as a delegate
Named and Optional Arguments
Named and optional parameters are really two distinct features, but are often useful together. Optional parameters allow you to omit arguments to member invocations, whereas named arguments is a way to provide an argument using the name of the corresponding parameter instead of relying on its position in the parameter list.
A parameter is declared optional simply by providing a default value for it:
public void M(int x, int y = 5, int z = 7);
Here y and z are optional parameters and can be omitted in calls:
M(1, 2, 3); // ordinary call of M
M(1, 2); // omitting z – equivalent to M(1, 2, 7)
M(1); // omitting both y and z – equivalent to M(1, 5, 7)
C# 4.0 does not permit you to omit arguments between commas as in M(1,,3). This could lead to highly unreadable comma-counting code. Instead any argument can be passed by name. Thus if you want to omit only y from a call of M you can write:
M(1, z: 3); // passing z by name
M(x: 1, z: 3); // passing both x and z by name
M(z: 3, x: 1); // reversing the order of arguments
Named and optional arguments affect overload resolution, but the changes are relatively simple:
A signature is applicable if all its parameters are either optional or have exactly one corresponding argument (by name or position) in the call which is convertible to the parameter type.
You can find the detailed description of the rest of the features in this document.
Tuesday, October 20, 2009
It might be useful in order to prevent exceptions, caused by entering a text, which exceeds specified maximum field size within your data source.
All you should do is to subscribe to DataBindings.CollectionChanged event of your control and put this simple code:
private void DataBindings_CollectionChanged(object sender, CollectionChangeEventArgs e)
if (e != null && e.Action == CollectionChangeAction.Add)
int bindedFieldMaxLength = this.MaxLength;
Binding bindingObj = (e.Element as Binding);
if (bindingObj != null)
if (bindingObj.DataSource != null &&
bindingObj.BindingMemberInfo != null)
DataTable sourceTable = (bindingObj.DataSource as DataTable);
DataView sourceView = (bindingObj.DataSource as DataView);
BindingMemberInfo bindingMemberInfoObj =
if ((sourceTable != null sourceView != null) &&
bindingMemberInfoObj != null)
string bindedFieldName = bindingMemberInfoObj.BindingField;
if ( sourceTable != null &&
sourceTable.Columns[bindedFieldName].MaxLength > 0)
if(sourceView != null &&
sourceView.Table.Columns[bindedFieldName].MaxLength > 0)
if (this.MaxLength != bindedFieldMaxLength)
this.MaxLength = bindedFieldMaxLength;
Monday, October 19, 2009
The error was:
System.IO.FileLoadException was unhandled by user code
Message="Could not load file or assembly 'Microsoft.Practices.EnterpriseLibrary.Logging, Version=220.127.116.11, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference.(Exception from HRESULT: 0x80131040)"
I had similar error in the past which I somehow solved and I remembered it was related to the location of the configuration file.
After reading the above bolded error description I've changed the version number in the configuration file thinking that was the problem - but couldn't pass this error.
Searching for a solution I found a nice & simple tool from Microsoft that clearly tells you what the problem is (if all problems were solved so easily...).
The tool name is Assembly Binding Log Viewer.
Running the application when this tool is in the background will log every assembly binding (you can choose between any and/or only exceptions).
Double clicking the 'bad' binding will open up a detailed log looking something like this:
LOG: This bind starts in default load context.
LOG: Using application configuration file: D:\...\DiegJukeboxManagerLoader.vshost.exe.Config
LOG: Using machine configuration file from C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\config\machine.config.
LOG: Post-policy reference: Microsoft.Practices.EnterpriseLibrary.Logging, Version=18.104.22.168, Culture=neutral, PublicKeyToken=31bf3856ad364e35
LOG: GAC Lookup was unsuccessful.
LOG: Attempting download of new URL file:///D:/../Microsoft.Practices.EnterpriseLibrary.Logging.DLL.
LOG: Assembly download was successful. Attempting setup of file: D:\...\Microsoft.Practices.EnterpriseLibrary.Logging.dll
LOG: Entering run-from-source setup phase.
LOG: Assembly Name is: Microsoft.Practices.EnterpriseLibrary.Logging, Version=22.214.171.124, Culture=neutral, PublicKeyToken=null
WRN: Comparing the assembly name resulted in the mismatch: PUBLIC KEY TOKEN
ERR: The assembly reference did not match the assembly definition found.
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
As you can see in plain english the error was that the dll was without the publicKeyToken (since I downloaded the sources of EL & the installation program compiled it...) - so the binding failed since the configuration file contained Microsoft's publicToken (remained there from previous version...).
Concuslion: next time you encounter any kind of assembly binding error - don't work too hard, download this tool and use it!!
Saturday, October 3, 2009
Going through the 'right' way to implement this, I encountered many samples where the queing & message stuff were embeded in the bussiness logic - I couldn't understand how this meets WCF goal to seperate transport from bussiness logic.
Finally I encounter this article.
The interesting part of the sample was the elegant way the writer shows how to narrow the MSMQ code to the binding code (configuration) & leaving the code nice and clean allowing to change transport without touching the bussiness logic - this maybe sounds easy when moving from TCP to HTTP or similar, but since MSMQ is message oriented it is more of a challenge.
For the full story, including a short & sweet video - see:
SOA'izing MSMQ with WCF (and Why It's Worth It)