I spent some time looking for a simple compound interest calculation function in .NET today. I couldn't find anything usable, so I grabbed the source formula and reduced it to .NET.

Here's the formula:

A = P * (1 + r / n) ^ n * t
A = final total amount
P = principal amount
r = interest rate (decimal)
n = number of periods per year
t = number of years

The C# code:

decimal CalculateTotalWithCompoundInterest(decimal principal, decimal interestRate, int compoundingPeriodsPerYear, double yearCount)
{
    return principal * (decimal)Math.Pow((double)(1 + interestRate / compoundingPeriodsPerYear), compoundingPeriodsPerYear * yearCount);
}

For example, you can calculate the total loan amount for $10,000.00 (principal and interest), compounded daily for 2 years like so:

decimal total = CalculateTotalWithCompoundInterest(10000m, 8.5m, 365, 2);

I upgraded an ASP.NET MVC 3 project to MVC 4, and upgraded to VS 2012 at the same time. Everything compiled fine, and worked fine in the browser, but the intellisense was totally broken.

I couldn't for the life of me figure it out. Everything in web.config looked right, the correct assembly versions were referenced, etc.

Finally, I realized that the issue was in the Views\Web.config. The version numbers of assemblies there were pointing to MVC 3 and WebPages 1, rather than MVC 4 and WebPages 2.

To solve the issue, change all the version numbers in that file appropriately (4.0.0.0 for System.Web.Mvc references, and 2.0.0.0 for System.Web.WebPages.Razor references).

I just ran into an issue where DataBinder.Eval was exploding with an exception like this:

'System.Dynamic.ExpandoObject' does not contain a definition for 'Id'.

The problem here is that DataBinder.Eval uses either reflection and type descriptors to bind to properties. ExpandoObject (and dynamic types) don't support reflection. ExpandoObject doesn't implement ICustomTypeDescriptor either, leading to an exception when attempting to bind to an ExpandoObject.

After half an hour of googling, I found Bertrand Le Roy's excellent example of building custom type descriptors: Fun with C# 4.0's dynamic. I'm not sure why it took me so long to find it, so I figure I'll give him a bit of google juice and add some more keywords.

Also, that sample is rather out of date, so you'll have to do a couple of tweaks to make it work in .NET 4/4.5 (see below). Once that's done, you will have a bindable wrapper object that takes an ExpandoObject and can be directly bound to. Given and ExpandoObject "dyn" with a property named "Id", you can do this:

var bindableObj = new DynamicTypeDescriptorWrapper(dyn);

var value = DataBinder.Eval(bindableObj, "Id");

Changes required

First, change DynamicHelper.cs to the following:

public static class DynamicHelper {
    public static object GetValue(object dyn, string propName) {
        // Warning: this is rather expensive, and should be cached in a real app
        var GetterSite = CallSite<Func<CallSite, object, object>>.Create(
                Binder.GetMember(CSharpBinderFlags.None,
                    propName, 
                    dyn.GetType(),
                    new [] { CSharpArgumentInfo.Create(CSharpArgumentInfoFlags.None, null) }
                    ));

        return GetterSite.Target(GetterSite, dyn);
    }

    public static void SetValue(object dyn, string propName, object val) {
        // Warning: this is rather expensive, and should be cached in a real app
        var SetterSite = CallSite<Func<CallSite, object, object, object>>.Create(
                Binder.SetMember(CSharpBinderFlags.None,
                    propName, 
                    dyn.GetType(),
                    new [] { CSharpArgumentInfo.Create(CSharpArgumentInfoFlags.None, null),
                                CSharpArgumentInfo.Create(CSharpArgumentInfoFlags.Constant |
                                            CSharpArgumentInfoFlags.UseCompileTimeType, null) }
                    ));

        SetterSite.Target(SetterSite, dyn, val);
    }
}

Then, change GetValue and SetValue in DynamicPropertyDescriptor as follows:

public override object GetValue(object component) {
    if (component is DynamicTypeDescriptorWrapper)
        component = ((DynamicTypeDescriptorWrapper)component).GetPropertyOwner(this);

    if (_owner != component) throw new InvalidOperationException("GetValue can only be used with the descriptor's owner.");
            
    return DynamicHelper.GetValue(component, _propertyName);
}

public override void SetValue(object component, object value) {
    if (component is DynamicTypeDescriptorWrapper)
        component = ((DynamicTypeDescriptorWrapper)component).GetPropertyOwner(this);

    if (_owner != component) throw new InvalidOperationException("SetValue can only be used with the descriptor's owner.");
            
    OnValueChanged(component, EventArgs.Empty);

    DynamicHelper.SetValue(component, _propertyName, value);
}

I haven't found a way to do this with TortiseGit yet, so you have to drop into the actual git command prompt and do (at the root of the repo):

git submodule -q foreach git pull -q origin <branch>

The WiX docs on the topic (Integrating WiX Projects Into Daily Builds) give a good starting point, but are incomplete, at least for the recent builds. Two additional things they forget to mention: WixToolPath needs to be an absolute path for the Wix.targets project to function properly, and WixExtDir needs to be set to WixToolPath.

To build WiX from the binaries with MSBuild, do the following (requires MSBuild 4):

1. Snag the binaries from the latest weekly build: WiX Weekly Releases
2. Extract them into a folder you can access with a relative path inside your source control root
3. Edit all of your .wixproj files and do the following snippet before the <Import Project="$(WixTargetsPath)" > tag:

     <WixToolPath>$([System.IO.Path]::GetFullPath('RELATIVEPATHTOWIX\wix\'))</WixToolPath>
     <WixTargetsPath>$(WixToolPath)Wix.targets</WixTargetsPath>
     <WixTasksPath>$(WixToolPath)wixtasks.dll</WixTasksPath>
     <WixExtDir>$(WixToolPath)</WixExtDir>
   </PropertyGroup>
   

4. Update the RELATIVEPATHTOWIX to be a relative path that points to the WiX binaries you extracted in step 2.