It appears that a client proxy instance for and out-of-process ServicedComponent expects the client to have a compile-time reference to the ServicedComponent assembly, unless ServicedComponent is either of different CLR version or has different bitness (either client or server is x64 while another one is x86). This creates a bizarre problem: if the client has no design-time reference to the ServicedComponent, Activator.CreateInstance(compoentClsID) fails if the component is of the same bitness and CLR version with a cryptic "Cannot load type" RemotingException, while working perfectly fine when ServicedComponent is of different bitness or compiled targeting different .NET Framework version. Google offered no insight, so I started thinking of why matching CLR and bitness would lead to failure. I started suspecting that when client and server have mismatched CLR/bitness attributes, runtime must be doing cross-process marshalling in somewhat different manner than when attributes match. Now what I needed is to ensure that same "deep proxying" is taking place when client and server have matching CLR/bitness. On the hunch I decided to use overloaded Type.GetTypeFromCLSID(clsID, "localhost"), and lo and behold, it worked! Now I have a client that at design time is only aware of ServicedComponent's interface, but does not hold a direct reference to it, and yet it is able to talk to multiple out-of-process ServicedComponent implementing same interface while having different CLR and bitness attributes. At the end of the day it turned out to be possible to instantiate ServicedComponent while knowing neither its CLSID at the design time nor having a hard reference to the assembly implementing ServicedComponent.

Update: here's a very good walk-through of setting up BIOS on Intel chipset motherboard for OCZ SSD RAID array.

Since I was about to clean up my system anyway, I decided not only to install Windows 7, but also bite the bullet and get two SSD drives and put them into striped RAID configuration. I did it last weekend and yes, rumors are true: the performance boost you get from SSDs, especially from RAID-0 SSDs is by far the most noticeable and exciting in a generation. (From this point on, spindle hard drives are entering their twilight years, and pretty soon they will be where CRT displays are now.) It's kind of perverse, but perf improvement is so drastic that it now takes less time for Windows to boot than for the motherboard to finish the POST!

Here are points that might be useful for those trying to do similar setup.

- Not every SSD drive can be used in RAID configuration. At this point you need to stick with SSD drives having Indilinx controller. 60GB MLC drives like OCZ Vertex, Corsair Extreme, and OCZ Agility (the one I got, see the review) - are all reasonably priced and will work well with mainstream motherboards-based RAID controllers, like Intel Matrix RAID. Two of these drives cost just a little over what single 128GB drive costs, but two 64GB drives give you two controllers, twice the amount of on the drive cache, and connection to two separate SATA channels, all of which delivers much better performance than a single 128GB drive for about the same amount of money.

- Windows 7 does have Intel Matrix RAID driver, so no need to do the F6 thing to load it during windows installation.

- If you are putting your drives into a desktop machine, you will need mounting brackets to fit 2.5" drives into 3.5" bays.

- Since both Windows 7 and SSD drives are relatively new products, load the latest BIOS for your motherboard before you even connect your drives for the first time. It's also a good idea to get a relatively recent motherboard and ensure your mobo does indeed have RAID functionality. For example, if your motherboard has Intel chipset, letter "R" in ICH10R "south bridge" chip name seems to indicate presence of RAID support.

- If your motherboard has Intel Matrix RAID, change BIOS settings to make sure you put your on-board SATA controller into RAID mode. It actually should be called AHCI+RAID, because RAID is still AHCI. Non-RAID SATA drives may still be used when SATA controller in RAID mode with no problem at all.

- Even though Windows 7 comes ready for SSD drives, tweaks like disabling SSD drive indexing will improve either drives' longevity or system performance. Also, Windows 7 may not see the RAID group as 100% SSD. What it means is that when Win7 realizes there is an SSD drive in the system, it's supposed to automatically turn off superfetch and disk defragmentation. In my case it did turn off disk defrag for my SSD RAID volume, but didn't turn off superfetch - maybe because I have a couple of regular hard drives also connected (although not members of the RAID array).

- If you wonder whether ATA Trim command (that helps to maintain SSD drives' performance) is going to work in RAID configuration, then the answer is not yet. Currently, the choices for SSDs connected to Intel matrix raid controller are either RAID, or TRIM, but not both together. The reason for that is Intel Matrix Storage Manager (MSM) driver does not pass through TRIM command - only MS SATA and IDE drivers for Windows 7 do. So for TRIM one needs to use Microsoft drivers, which do not support MSM RAID. So if you do RAID, you will need to use Intel MSM driver, and wait for some future version of MSM that can support TRIM in at least in RAID-0 and RAID-1 configurations.

- Next version of OCZ firmware for Agility and Vertex SSD drives is expected to have background "garbage collection" built in, which is supposed to reset NAND cells while drives are idling.

Here's a very good post about SSDs on Windows 7, plus an absolute must-read article about most popular SSD drives from AnandTech.com.

ATTO benchmarks:
Take a look a all-important 4KB transfer rates (most common case for non-server scenarios) - it does astonishing 178MB/s writes and 180MB/s reads:

Compare it with 53MB/s writes and 35MB/s reads of $440-worth, fastest 120GB MLC drive - OCZ Vertex Turbo:


...or with arguably the best SSD drive there is - $800 Intel X-25E SLC drive - it does 104MB/s writes and 120MB/s reads on 4KB block size:

Today I downloaded both iTunes 8.2 and iPhone OS 3.0. After installing everything, syncing the iPhone with my 64-bit Vista failed at the end of the process with this message "The iPhone cannot be synced. An unknown error occurred (13019)." I had to read through several pages of Apple forums to find the solution, which turned out to be unsyncing the music and then re-syncing it back again.

Twice I tried to update iPhone 3G firmware using iTunes 7.7 running on 64-bit Windows Vista, and both times I was getting cryptic error with code (-1) somewhere in the middle of the process. Oddly, firmware would seemingly get upgraded before the crash, but I would still have to restore the iPhone from the backup - a process (was buggy on its own) that would not restore the applications I installed from Apple app store.

Thankfully, after I got iTunes 8, my latest upgrade to 2.1 version of iPhone software went without a problem. 2.1 was worthy upgrade: the most obvious change was improved battery life.

(Updated 7/4/2008). Unlike Windows XP or Windows Server 2003, changing a motherboard on a machine running Windows Vista (in my case Vista Ultimate x64 with Service Pack 1) is not mentioned in the Microsoft Knowledge Base article addressing the MoBo upgrade. I tried a couple of approaches described below, but the bottom line is that the same process worked for Windows Vista, with one important difference: Vista upgrade process takes many hours. Waiting for that first reboot - the point where you replace the board - took close to two hours! And then it took a few more hours to complete the upgrade process. In the end the machine booted up and most of applications seem to be working fine.

Applications that didn't fare well are:

• Daemon Tools
  Symptoms: When system is booting, a cryptic error message is displayed, complaining about Windows version or something. Worse, an attempt to uninstall Daemon Tools failed. However, deleting the folder with Daemon Tools made the problem go away.
  Solution: Uninstall Daemon Tools before upgrading the system, and reinstall it after upgrade is complete.
  
  
• Windows Mobile Device Center
  Symptoms: Connecting a smartphone caused Windows Mobile Device Center to crash.
  Solution: Repair Vista installation again. After I ran an upgrade installation of Vista again (overnight, because it takes untold hours to complete), this problem went away. Please note that unlike XP, Vista does not have a separate Repair Installation option. You must run Upgrade installation (for that start installation from Windows) in order to repair existing Vista installation.
  
  
• Microsoft Visual Studio 2008 Dataset Editor
  Symptoms: Opening and XSD schema or a Dataset in Design mode in VS 2008 resulted in opening the file either as a text, or as XML.
  Solution: Please check this post.
  

Now a little more about how the first upgrade attempt went down.

Having to watch the upgrade screen for hours in order to intercept the first rebooting is no fun, and ironically can be mitigated by the bug on the "Vista x64 with SP1" DVD, which makes a rebooting process always stop indefinitely waiting for user input. This bug is a mixed blessing, because you can go about your normal life while waiting for the first reboot while the existentially-named "Gathering Files" step of the Vista upgrade sequence is running, but after you have replaced the main board you want the upgrade process do its reboots without your involvement, and that's where the bug turns from being a help to being a hassle. Anyway, you would be wise to allocate half-day for the motherboard upgrade on the Vista system, and by all means back up your system before the upgrade.

Failed Mobo upgrade approaches included uninstalling board-specific drivers before turning the PC off and replacing the motherboard. It didn't work at all - machine went into reboot loop. Attempts to boot in the Safe Mode stopped at BTHidMgr.sys, which I later found could be related to having Nero's InCD installed. I don't have InCD, but I do have Daemon Tools, which incidentally is the only application that stopped working after the upgrade. I never tried to remove Daemon Tools before trying the Vista upgrade path, so the next time I would recommend trying the quick "uninstall drivers, uninstall Daemon Tools/InCD, Reboot" approach first. Only if that does not work, get the huge bag of popcorn and do Vista upgrade.

Upgrading or replacing a motherboard on a machine running Windows Server 2003 (in my case it was Windows 2003 R2 Standard Edition with Service Pack 2 x64) is relatively straightforward, and more or less works as described in the MS Knowledge Base article: you start upgrade process by running Windows setup while old motherboard is in-place, and once upgrade process reboots the machine, you intercept it by turning the computer off and replacing the MoBo, and then allow upgrade process to continue. It worked alright, and wasn't too long a process.

What the KB article didn't mention is that after the upgrade a few things may be broken or missing. In my case there were two big things broken:

• IE was corrupted in a way that prevented downloading files by clicking a link. Page browsing still worked and "Save target as..." worked, but clicking a link that redirects to a file download resulted in the strange error message: "The requested look-up key was not found in any active activation". My way to fix it was to upgrade IE6 to IE7, but since IE7 download links were those redirect links that didn't work, I had to install FireFox, which had a link accessible via "Save target as", and then I used FireFox to download and install IE7.
  
  
• .NET Framework 2.0 has disappeared, wracking havoc making pretty much all applications (SQL Server Management console, ASP.NET apps in IIS) not working. Fixing it was not too bad though - I downloaded and installed .NET Framework 2.0 x64, then made a couple of runs of Windows Update to ensure the server won't try to reboot soon after being brought online, rebooted the machine just in case, and that was it.

Overall entire process, although not completely seamless or worry-free, took only about an hour, not counting time required to physically replace the board.

After downloading and installing just-released Visual Studio 2008 on Vista x64, I got compilation error while trying to build the "Hello, World" application. The error was "fatal error CS0014: Required file 'alink.dll with IAlink3' could not be found."
It seemed to be a fairly common error during the Beta cycle of the Visual Studio 2008, but apparently it was not fixed - at least not for the 64-bit version of Vista. Similar to 32-bit versions, the solution was to install two Windows Update items found on the Visual Studio 2008 DVD in the "<dvddrive>:\WCU\dotNetFramework\dotNetMSP\x64" folder (for 32-bit version look in the "<dvddrive>:\WCU\dotNetFramework\dotNetMSP\x86" folder):
1. NetFX2.0-KB110806-v6000-x64.msu. Run it, wait forever, reboot when it's done.
2. NetFX3.0-KB929300-v6000-x64.msu. Run it, wait forever, reboot when it's done.

After those two updates were installed, the problem went away.

Update: This issue may have been fixed as of April 2008: http://support.apple.com/kb/HT1426.

I spent approximately a week researching iPhone and everything related to it. Not a single time did I see anything that would suggest that iPhone does not sync with 64 bit version of Windows - not even on the back of the iPhone box, where system requirements are spelled out. So all the anticipation of playing with iPhone came down crashing when I put it in the cradle and got "Please connect iPhone to a computer running a 32-bit version of Windows XP (SP2) or Windows Vista." message:


This was the first Apple product I ever bought, and what a wonderful F-U I got. Apple is indeed not an engineering company, but a designer shop making cool-looking accessories - a Luis Vuitton of IT. The only thing remaining for Apple is to figure out that technology thing.

Quick Internet search established without a doubt that iPhone won't sync with x64 Windows systems and tech support rep confirmed that there is absolutely nothing they can do other that suggesting to install 32 bit operating system.

Anyway, the iPhone is going back. To be fair, Apple customer support was fast and helpful, and the rep who processed my return request waived restocking fee on the unit (I bought it from Apple online) and they promised to send prepaid FedEx shipping label.

I need to test my software on a variety of 64-bit Windows versions. I hoped I would be able to use Microsoft Virtual Server, which I've been successfully using for a while for 32-bit tests (including German, Russian and Korean flavors of Windows - quite a feat for a Ukrainian with English as a second language), but to no avail - at this point even latest MS Virtual Server is unable to host 64-bit guest operating systems. So despite enjoying being lazy, I was forced to check out free VmWare Server. I hoped to run it on my main Vista x64 dev box, but VmWare Server did not install correctly on Vista x64. That was quite a setback for my product delivery schedule, because I realized I needed another box with 64-bit Windows 2003 Server on it to be sure I could run VmWare Server. I dug through my closet with PC parts and after combining what I had with $200 worth of parts bought from NewEgg.com I had a modest 64-bit box with Pentium D 805 and 1GB of DDR memory. VmWare has installed without a problem, but when I attempted to install Windows XP x64 VmWare Server told me that my Pentium D CPU is no good because when it comes to Intel CPUs, 64 bit guest OSes can run only on EMT64 units with Virtualization Technology (VT) support! Fortunately, my dev desktop had Core 2 Duo E6300, which does have VT support, and both Pentium D and Core 2 Duo use the same LGA 775 package, so I was able to simply swap CPUs and ta-da! - after that VmWare finally started cooperating and is installing XP x64 guest OS as I'm typing this article.

Conclusion: If you want to run 64-bit guest OS in VmWare using Intel CPU you will need a box with a processor supporting Virtualization Technology, and run Windows 2003 x64 as a host OS.

After installing VmWare Server on 64-bit Windows 2003 Server R2, I was unable to access VmWare Server's web admin page due to Service Unavailable error. VmWare support forum suggests to remove .NET Framework 2.0, which seems to help some people, but I fixed the problem by repairing .NET Framework 2.0 installation after VmWare server was installed. To do that go to Control Panel -> Add/Remove Programs, select .NET Framework and hit Change/Remove button. In the dialog select repair and let it run. After that both Default Web site and VmWare web site were running fine.

In the brave new world, where nearly all CPUs are 64 bit, and Vista x64 is poised to have a large market share, how many ASP.NET 1.1 developers will find themselves in the situation where IIS7 running on x64 OS can't create an application pool for .NET Framework 1.1, therefore making it impossible to debug ASP.NET 1.1 applications under IIS7 using Visual Studio.NET 2003? All because when looking for available ASP.NET versions, IIS7 is probably looking into 64 bit .NET Framework folder - "C:\Windows\Microsoft.NET\Framework64", which only has 2.0 and 3.0 versions in it. Not knowing this would be the case, I recently installed Vista x64 on my newly upgraded Dev box and almost fainted when I realized I can't use VS.NET 2003 to debug legacy ASP.NET 1.1 apps. It took me a while to realize that our own Cassini Web Server for ASP.NET 1.1 may work just fine, because it has its own routines for discovering location of .NET Framework 1.1 files, and it can be used for debugging of ASP.NET 1.1 application in VS.NET 2003. I tried it a few days ago, and sure enough our little Cassini saved the day - Visual Studio.NET 2003 ran an ASP.NET 1.1 app on our Cassini in Debug mode without a hitch!

Microsoft Virtual Server R2 SP Beta works really well on Vista x64 and Intel Core 2 Duo E6300 CPU, which has Virtualization support. Installer was not completely hands-off - I had to add CGI module to IIS7 manually - otherwise VSWebApp.exe was treated as downloadable file and not as CGI module. MS needs to update VS installer to automate this step.

Please note that although MS Virtual Server R2 Beta can run on Vista x64, it can't host 64-bit OSes. To host 64 bit OSes you would need free VmWare Server installed on x64 Windows 2003 Server, and either AMD 64 bit CPU or Intel EMT64 CPU with Virtualization Technology (VT) support (like Core 2 Duo E6300 or E6400 CPUs).

[July 16, 2007 UPDATE:] After downloading Nero 7 Ultra Edition Update I was able to upgrade my original dysfunctional Nero 7 Essentials. I tried to uninstall Nero 7 Essentials, but uninstallation failed. I had to use Windows Installer Cleanup Utility to get rid of Essentials first. The good thing was that after Essentials was gone, Ultra Edition upgrade found registration key of Essentials and used it to get installed. Naturally, after it was installed it still only had functionality of Essentials, not Ultra. Nero 7 Ultra came as a ridiculous 120+ MB download, with tons of junk, like ASK.com toolbar, so I had to spend time making sure it won't get installed. Funny, but help system is not included into the 120 MB download. To my surprise there was no "Burn DVD Files" option in Nero Start Smart, which used to be there since Nero 6. Fortunately, I found "Burn DVD Files" in the Nero Express UI itself. At this point I haven't burned any dual-layers, but single layer DVDs burned at 16x speed on my NEC 3550A drive just fine. Hopefully days of no decent software for DVD burning on Vista x64 are over.
Success: Nero 7 Essentials with Ultra Edition Update.
[END OF UPDATE]

[ORIGINAL POST:]
Tried to burn Dual-Layer ISO image on Vista x64 with a few different pieces of software. These are the results:

Success: (with caveats) ImgBurn - does the job, but created a few dual-layer coasters, and almost invariably fails the burned disk verification at the end, even if disk is perfectly playable.

Failed : Nero 7 Essentials - filed to start after installation.
Failed : ISO Recorder V3 64 Bit - failed after finishing the first layer.
Failed: Active ISO Image File Burner - failed after finishing the first layer.