Sunday, April 21, 2013

How do the C# operators |, ||, & and && differ?

|| and && are "short-circuit" operators for "OR" and "AND" operations respectively.
For instance, consider the below conditional check.
           if(predicate1 || predicate2 || predicate3)
           {
                // Some code.
           }
Here, if predicate1 is true, predicates 2 and 3 will not be checked. If predicate1 is false and predicate2 is true, then predicate3 will not be checked.

Similarly,
           if(predicate1 && predicate2 && predicate3)
           {
                // Some code.
           } 
Here, if predicate1 is false, predicates 2 and 3 will not be checked. If predicate1 is true and predicate2 is false, then predicate3 will not be checked.

| and & mean different based on the type of the operands.
If they are used on non-integer operands, then they act as normal logical operators. However, not short-circuited, i.e., All the conditions/predicates in a conditional statement are checked, irrespective of the result of any of the predicates.
           if(predicate1 || predicate2 || predicate3)
           {

                // Some code.

           }
the above checks all three conditions, even if predicate1 is true.

 If they are used on integer operands, then the act as bitwise operators, for instance,             A = 01010101                B = 10101011          A | B = 11111111A & B = 00000001

 
Please comment if this served your purpose by any chance. Happy coding :)

Saturday, January 26, 2013

4 easy steps to auto-merge configuration settings as part of package installation

Usually, installing a package through NuGet corresponds to a set of assemblies whose references get added to the consuming system. However, some packages contain more than mere assembly references. They may also expose certain configuration settings that are required for the assemblies to work. Creating .nupkg packages (either using project reference or .nuspec file) for such applications isn't straightforward. We should let NuGet know that it has to pack certain additional content when it creates the .nupkg file.
 
So, here are 4 easy steps to auto-import configuration settings as part of package installation -
  1. Add a folder names 'content' and place it in the same folder as where the .nuspec file resides.
  2. Add an empty .config file to the content folder
    • If all the consumers are web-based, then, name it web.config.transform.
    • If all the consumers are non-web (Ex: Console Apps, Desktop apps, etc..), then, name it app.config.transform.
    • If consumers are a mix of both the above, then, name it web.config.transform and add a new file named app.config.transform --- in this case, NuGet will decide which one to pick at the time of installation, based on the consuming application.
  3. Pick the configuration settings required from the project configuration file and copy such values to the new file(s) created.
  4. Now, carefully, pick all the parent tags of those values copied above from the project configuration file and add as parents in the new file(s) created(in step #2) --- make sure you add closing tags corresponding to whatever node is newly added.

Once these 4 steps are done, then use the .nuspec file to create the package. Now, when consumers try to install such package, then, their configuration files would get auto-merged (Not replaced) with the settings present in the .config.transform files we created in step #2.

While this looks to be a cool feature, it is actually a much wider feature of NuGet, where you can even add transforms to source code, add PowerShell scripts to be auto-run, etc.. Refer this section on the official NuGet documentation on this for its full power.

PS: Please comment if this served your purpose by any chance. Happy coding :)

Tuesday, September 11, 2012

Oledb and sql provider parameter treatment




SQL provider - The creation of the parameters is name-dependent and not order-dependent.

OleDb provider - The creation of the parameters is order-dependent and not order dependent.
 
 
 
 
PS: Please comment if this served your purpose by any chance. Happy coding :)

Using parentheses with object initializers

public class ClassWithDefaultConstructor
{
    public string Property { get; set; }
}
public class ClassWithConstructorWithParameters
{
    public ClassWithConstructorWithParameters(string property)
    {
        this.Property = property;
    }
    public string Property { get; set; }
}
   
Correct usages -
var c = new ClassWithDefaultConstructor { Property = "value" };
var c = new ClassWithDefaultConstructor() { Property = "value" };
var c = new ClassWithConstructorWithParameters() { Property = "value" };
 
Wrong usage -
var c = new ClassWithConstructorWithParameters { Property = "value" };
 
Reason -
If you are using a parameterless constructor, as shown, the parentheses are optional, but if you are executing a constructor that requires parameters, the parentheses are mandatory, o/w, the compiler would cry as below -
 
Compile error -
'LINQProcessing.ClassWithConstructorWithParameters' does not contain a constructor that takes 0 arguments

PS: Please comment if this served your purpose by any chance. Happy coding :)

Joins-to-C# Query Extension Methods Mapping

Joins and their corresponding LINQ Query Extension methods
Type of join
Query extension method
Example
Example Result
(By enumerating through the query variable and displaying the details on console)
Inner Join
Join
var makes = new string[] { "Audi", "BMW", "Ford", "Mazda", "VW" };
var cars = GetCars();
var query = makes.Join(cars,
make => make, car => car.Make,
(make, innerCar) => new { Make = make, Car = innerCar });
Make: Audi, Car:ABC456 Audi TT
Make: BMW, Car:DEF123 BMW Z-3
Make: Ford, Car:ABC123 Ford F-250
Make: Ford, Car:DEF456 Ford F-150
Make: VW, Car:HIJ123 VW Bug
Left Outer Join
GroupJoin
var makes = new string[] { "Audi", "BMW", "Ford", "Mazda", "VW" };
var cars = GetCars();
var query = makes.GroupJoin(cars,
make => make, car => car.Make,
(make, innerCars) => new { Make = make, Cars = innerCars });
Make: Audi
Car VIN:ABC456, Model:TT
Make: BMW
Car VIN:DEF123, Model:Z-3
Make: Ford
Car VIN:ABC123, Model:F-250
Car VIN:DEF456, Model:F-150
Make: Mazda
Make: VW
Car VIN:HIJ123, Model:Bug
Cross Join (Cartesian product)
SelectMany
var repairs = new List<Tuple<string, List<string>>>
{
Tuple.Create("ABC123",
new List<string>{"Rotate Tires","Change oil"}),
Tuple.Create("DEF123",
new List<string>{"Fix Flat","Wash Vehicle"}),
Tuple.Create("ABC456",
new List<string>{"Alignment","Vacuum", "Wax"}),
Tuple.Create("HIJ123",
new List<string>{"Spark plugs","Air filter"}),
Tuple.Create("DEF456",
new List<string>{"Wiper blades","PVC valve"}),
};
var query = repairs.SelectMany(t =>
t.Item2.Select(r => new { VIN = t.Item1, Repair = r }));
VIN:ABC123 Repair:Rotate Tires
VIN:ABC123 Repair:Change oil
VIN:DEF123 Repair:Fix Flat
VIN:DEF123 Repair:Wash Vehicle
VIN:ABC456 Repair:Alignment
VIN:ABC456 Repair:Vacuum
VIN:ABC456 Repair:Wax
VIN:HIJ123 Repair:Spark plugs
VIN:HIJ123 Repair:Air filter
VIN:DEF456 Repair:Wiper blades
VIN:DEF456 Repair:PVC valve

Extension method syntax - [source collection].[extension method].[extension method]…;

PS: Please comment if this served your purpose by any chance. Happy coding :)