Running .NET 3.5 Application on .NET 4 (And Beyond)

Few days ago I tried to get my VHD Attach to run on Windows Thin PC.

Initial diagnosis was easy - there was no .NET Framework installed. While there is no way to install .NET Framework 3.5 on Windows Thin PC, .NET Framework 4.0 installs just fine.

Next run gave us another clue with System.IO.FileNotFoundException: Could not load file or assembly 'System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies. The system cannot find the file specified.

While .NET 4 is backward compatible, Microsoft made intentional decision that it will not run applications made with earlier runtimes. This is not a big issue in Windows 7. There you have 2.0, 3.5 and 4.0 installed side-by-side and each application can pick whatever it needs. However, in Windows Thin PC there is only 2.0 and 4.0. Notice that one version is missing and it was the one I needed.

To make long story short, there is solution that does not involve recompiling. Just add Application Configuration Files (App.config) and put following text into it:

<?xml version="1.0"?>
<configuration>
    <startup>
        <supportedRuntime version="v4.0" />
        <supportedRuntime version="v2.0.50727" />
    </startup>
</configuration>

This will tell application to run on .NET 4 if possible and to fallback to 3.5, 3.0 and 2.0 as a backup solution. This might not be most beautiful solution but it is a solution that works.

P.S. Yes, supportedRuntime cannot distinguish between .NET 2.0, 3.0 and 3.5.

VHD Attach 3.02

This is very small update to VHD Attach. I removed application config files introduced with last version. Of course that means that both Thin PC users will hate me. For them, there is FAQ with separate download.

I do plan to sort things out in later version.

Highly Improbable

Welcome to my new web server. And for the first time ever, it is Linux-based.

I haven’t moved because Windows were unstable (haven’t had any issues). I haven’t moved because of bugs (PHP is buggy on any platform). I haven’t got tired of .NET (C# rules!).

I moved because of SSH. I grew tired of plain-text FTP where any kid with Wireshark could get my password.

My hosting company made sure that server change went smoothly. They just switched DNS records and, poof, my website on new server started. It is true that, for a while, there was no CSS or JavaScript but culprit was found in W3 Total Cache plugin. It just didn’t like being copied around and quick uninstall sorted that out. :)

There were few other minor issues with upgrade service for VHD Attach and QText but they had more to do with subtle differences between Windows and Linux hosting than with any real error.

Now let’s just hope that I don’t break everything. :)

IPv6 in Your Local Network Via DD-WRT

After sorting out tunneling on my computer, there came time to setup my router too. Idea is not to configure each client with separate tunnel but to have one tunnel on router and all computers connecting to it should use it transparently. Hurricane Electric gives /64 prefix and that ought to be enough.

As a router I will use my trusty DD-WRT. Exact version used in this example is DD-WRT v24-sp2 (12/08/11) std-nokaid (SVN revision 17990M NEWD-2 Eko). Your mileage may vary depending on version of your choosing.

Obvious first step is to enable IPv6. It is easy enough to do. Under Administration -> Management find IPv6 support and enable IPv6 and Radvd. Radvd is configured as simple as it can be:

interface br0
{
   AdvSendAdvert on;
   prefix ^^2001:db8:9:10ee::/64^^
   {
   };
};

Notice that prefix is same text “Routed /64” under your tunnel details.

Unfortunately this will not do. There is need for small script:

insmod ipv6

SERVER_IPV4_ADDRESS="^^216.66.22.2^^"
SERVER_IPV6_ADDRESS="^^2001:db8:8:10ee::1^^"
CLIENT_IPV4_ADDRESS=$(ip -4 addr show dev eth0 | awk '/inet / {print $2}' | cut -d/ -f1)
CLIENT_IPV6_ADDRESS="^^2001:db8:8:10ee::2^^"
ROUTED_IPV6_ADDRESS="^^2001:db8:9:10ee::1^^"

if [ -n $CLIENT_IPV4_ADDRESS ]
then
    ip tunnel add he-ipv6 mode sit remote $SERVER_IPV4_ADDRESS local $CLIENT_IPV4_ADDRESS ttl 255
    ip link set he-ipv6 up
    ip addr add $CLIENT_IPV6_ADDRESS/64 dev he-ipv6
    ip route add ::/0 dev he-ipv6
    ip -6 addr add $ROUTED_IPV6_ADDRESS/64 dev br0
    kill $(ps | awk '/radvd / { print $1}')
    radvd -C /tmp/radvd.conf
    wget "http://ipv4.tunnelbroker.net/ipv4_end.php?ip=AUTO&pass=^^9fc4d3d26b6ba921226c53e6c664c1ab0^^&apikey=^^tb4f139f1c342fgbd4.44123289860^^&tid=^^5511235463^^"
fi

Script sets some variables, brings interface up, adds some routes and restarts radvd daemon in order to pickup latest settings. Last line is needed only for users with dynamic IP (full explanation can be got once you load page in browser). This script needs to be saved with Save Firewall (under Administration -> Commands).

Once router gets restarted you will notice that all clients get IPv6 address alongside IPv4 (they have to support IPv6, of course). Easiest way to check it to run ping -6 ipv6.google.com. Or load it or one of many IPv6 test pages.

Windows 7 works just beautifully with IPv6.

P.S. In case you are wondering where I pulled those IPv6 addresses from, here is what Hurricane Electric gave me:

IPv6 Tunnel Endpoints
    Server IPv4 Address: __216.66.22.2__
    Server IPv6 Address: __2001:db8:8:10ee::1/64__
    Client IPv4 Address: __174.78.144.123__
    Client IPv6 Address: __2001:db8:8:10ee::2/64__

Routed IPv6 Prefixes
    Routed /64:          __2001:db8:9:10ee::/64__

IPv6 in IPv4 World

In order to get into modern era I decided to teach my computer to talk IPv6. Windows 7 already comes with IPv6. I mean, how hard can it be?

Well, since my Internet provider does not give a **** about IPv6 first step is to get a tunnel. And there are quite a few IPv6 tunnel providers. In my case I decided to go with SixXS since they have support for both Windows 7 and (via black magic) my DD-WRT router. For Windows 7 you do need to have their AICCU client installed (and probably OpenVPN). Slight nuisance but bearable.

Once my account was ready (it took them less than a day) I created an Dynamic NAT-traversing IPv4 Endpoint using AYIYA (now repeat this really fast). All eager I awaited for confirmation. Instead of it I got “SixXS has discussed your request regarding a tunnel but have decided not to approve this request”. Nothing in mail pointed to what I did wrong. My guess was that they noticed I am trying to use Ashburn, VA (where I currently live) with my Croatian address (where I usually live). I elaborated my situation and waited for response. And waited. And waited. No response (10 days and counting).

Thus I decided to see what other brokers are out there and I found one that would work for me - Hurricane Electric. They give you up to five /64 tunnels and upon that you can additionally request /48 prefix. Their tunnel endpoints are not that numerous but I think that they offer satisfactory range.

But that is not the best thing. After reading guides for setting up SixXS I was pleasantly surprised that my configuration consisted of 4 lines:

netsh interface teredo set state disabled
netsh interface ipv6 add v6v4tunnel IP6Tunnel 192.168.1.2  10.20.30.40
netsh interface ipv6 add address    IP6Tunnel 2001:db8::1:0:0:2
netsh interface ipv6 add route ::/0 IP6Tunnel 2001:db8::1:0:0:1

And you do not need to remember those 4 lines since they will be generated automatically for you and available on Tunnel Details page. Just take care to fill first IP correctly (192.168.1.2 in this example) No additional software, no new drivers - Simplicity at it’s best.

So far I think I am convert. While SixSX has a little bit better support for dynamic IPs, things are not too bleak for Hurricane. And keep in mind that Hurricane does tunneling over protocol 41 so there is need for your network to support this (almost each one does).

In short, I would say that Hurricane Electric is much better choice if you have normal provider who does not block any traffic. In any case, I am IPv6 (and so can you). :)