Move X-UA-Compatible Tag to the Top

Now Internet Explorer 9 Beta is out, a lot of websites are broken again. For example, this site itself does not even work with IE9 if you try to post a new blog entry. Even IE 8 compatible sites are affected. IE9 interprets CSS styles differently from everyone else, including all existing IE versions. Some AJAX javascripts are broken, including Microsoft AJAX .NET.

A quick fix to a current website would be to simply add the following to the page header:

<meta content="IE=8" equiv="X-UA-Compatible">

Please remember: this must be the first item in the header.

However, the "styleSheetTheme" setting of an ASP .NET webiste always places its CSS file in the header at the top before anything else. This makes the meta tag fail completely.

To move the "X-UA-Compatible" before it, you would have to do the following:

• Make the meta tag accessible from the server code by giving it an ID and add the "runat" attribute:
  
  <meta id="FirstCtrlID" content="IE=8" runat="server" equiv="X-UA-Compatible">
  ...
  
  
• Add the following pre-render event handler to your page (or master page):
  
  protected void Page_PreRender(object sender, EventArgs e)
  {
  Control MyFirstCtrl = Page.Header.FindControl("FirstCtrlID");
  Page.Header.Controls.Remove(MyFirstCtrl);
  Page.Header.Controls.AddAt(0, MyFirstCtrl);
  }
  
  

Actually, you can move things around in the header this way for anything that you explicitly define in there.

Removing "Rootkit" Virus

Recently my twelve-year old son managed to infect a couple of computers in my house with a very nasty virus. Both Microsoft Security Essential and McAfee failed to detect the virus. Full scan with both yielded no results.

When infected, the computers cannot connect to Microsoft update sites. Every attempt would yield an 0x800..EEF error. Links on Google search result pages all point to random sites that look very suspicious.

Luckily, Kaspersky Antivrus was able to detect a virus called "Rootkit.Win32.TDSS.d". I downloaded Kaspersky AVP Tool. It detected this virus. I then had to download another program from Kaspersky, called "tdsskiller". It did the job.

Thanks Kaspersky.

Install SharePoint 2010 on a Windows 7 Workstation

When installing SharePoint 2010 on a Windows 7 laptop, Windows security system can create some unexpected problems.

My laptop belongs to a Windows domain. But I was not connected to the domain during the installation. The SharePoint setup program completed without any complaints. But when I ran the configuration wizard, it would complain that the user was not found in the SQL database.

I checked the SQL Express server. I could login as the machine's local administrator. But if I tried to run the configuration program as the machine's local administrator, I would get an error saying that there was a data error.

So I used the simplest solution: install everything as the machine's local administrator. Of course, I would have to adde the domain user into the SharePoint sites as an administrator afterwards.

Error 2349

When installing Microsoft Office 2010 and Sharepoint 2010, I ran into some problems. The installers for each product gave the same error: "Error 2349. An internal error has occurred. ( ) Contact Microsoft Product Support Services (PSS) for assistance. For info...".

I search on Google, Bing, and Yahoo. I tried may things. None helped. Then I read the installation log in the temporary folder. Apparently the installer ran into a permission issue. It tried to write into "C:\Program Files\Common Files\Microsoft Shared". Somehow this directory is owned by "Trusted Installer", and no one has permission to write into it, not even the "Trusted Installer" itself.

So Microsoft has managed to secure the machine against its own installer, while viruses like "AV Security Suite" can install themselves even when "Microsoft Security Essential" is running. Good Job M$.

You can change the permission easily on the folder. First you would have to take the "ownership" away from the "Trusted Installer" and give it to the administrator. If you don't, everthing in the properties dialog box is disabled. Of course, this kind of "security measure" is only meant to make the ignorant feel secure. Once you take ownership, everything is enabled.Then you can change permissions on just about everything. Please may sure that you change ownership on all subfolders and "child objects" as well.

I gave full permission to the "Trusted Installer" to this folder. Actually, Sharepoint 2010 stores data files in this folder, so you really should give full permission to the current user as well. Otherwise, when you try to deploy Sharepoint packages, there will be more headaches.

After the permission chages, the installations went all the way without any problems.

Office 2007 Error: "There is not enough memory or disk space to run Word"...

When you are thousands of miles away from home, and Microsoft Office 2007 "Ultimate Edition" starts to tell you that "There is not enough memory or disk space to run Word" and "There is not enough memory or disk space to run Outlook", things can be a little hectic.

The root of this problem is in Microsoft Office Word. Outlook uses Word to edit and view emails, so Outlook would yield the same error. I searched on Google for answers. Most referred to older versions of Office. Some suggested that one should remove "Normal.dot", other suggested that one should clear the "STARTUP" folder, or delete the "Data" registry key, or delete the "Options" registry key. Some of the suggestions even came from Microsoft.com. By the way, Word 2007 does not have a "safe" command line switch.

I tried them. I ran Windows "System Restore" to various dates. None helped.

It turned out that the solution is simple: From Windows 7's Control Panel, go to Program and Features, selection Office 2007, and click on "Change". One of the two options in the popped up dialog box is "Repair".

So I ran "Repair".

That fixed my problem. I wonder why Microsoft' own knowledge base webpage for this exact problem did not memtion this fix.

Why Does the Modal Popup Control of AJAX Control Toolkit Always Re-Positions Itself After You Move It?

There is a problem with the Modal Popup control in the AJAX .NET Control Toolkit. The fix is not documented very well.

When the popup is shown, you can drag it around in the browser window if you specified its "PopupDragHandleControlID" in your code. However, when you release your mouse button, the poup box moves back to its original position automatically, --with animation, too!

It turns out that in their example, they added a piece of javascript to fix just this problem. The function is called "setBodyHeightToContentHeight", and it is specifed as a window resize handler. Even though the window is not resized when you move your popup box in the browser window, this will fix your problem.

The End of Load-Store Computing Is Coming

It is in the news that HP scientists is getting close to be able to produce devices based on memory resistors. One of them, Stan Williams, claims that we will see devices based on memory resistors working better than current NAND based devices in three years.

This is the beginning of a revolution. Besides the fact that memory resistors may potentially be used as more than just storage devices, fast static memory will change how computer software operate.

Currently, all application software, even including operating system and hardware drivers, follow a "load - execute - store" model. Data is loaded from permanent storage into RAM, processed, and then stored back to permanent storage. Faster static memory will make this model obsolete. A new model should be a "go to - execute" model. Nothing needs to be loaded. Software can execute exactly where it is stored because there will be no such thing as RAM anymore. Results need not be stored, because the results are already stored where they are in memory!

Because so much of our current software manage the load - store process of data, a new generation of software simply using "go to" without load/store will be needed to efficiently utilize the new hardware. All OS's, such as UNIX, LINUX, and Windows will all need to be re-written. After that, we will look back at the current "load - store" model software age as the "stone age".

Of course, some moving around of data will still be necessary from time to time, and data access to slow legacy storage will still need to follow the old model, at least partially. But that is different from the way things are now because to the new computers, connections to these devices will be treated almost like the way current computers handle phone dial-up modem connections. These devices can be "memory-mapped", but they are essentially "shadowed" with local static memory. So the loading process become a "shadowing process".

WCF with MSMQ

WCF over MSMQ can be difficult to setup. There are just too many layers. Frankly, in my opinion, it would be easier to implement fail over mechanisms without so may layers. Without all these extra layers, the chances of failures would be reduced, and the need for fail over is smaller at the first place.

When MSMQ throws an exception, the WCF host goes into a faulted state. You must handle the "Faulted" event of the service host in order to get any information on the fault. Without such an event handler, the service host just sits there quietly, as if there is nothing wrong. It will not handle any messages, and it will not give you any indication whatsoever that something is wrong.

Even if you do handle this event, there is little can be learned other than the service host entered faulted state. If you are lucky and you are in a debugger, you will see the exception that MSMQ threw, otherwise there is no way to retrieve the exception, especially if the service host runs in a service application.

One common MSMQ exception is that "An error occurred while receiving a message from the queue: The transaction specified cannot be imported. (-1072824242, 0xc00e004e). Ensure that MSMQ is installed and running. Make sure the queue is available to receive from." The error code is MQ_ERROR_TRANSACTION_IMPORT (0xC00E004E), which typically means that the transaction coordinator is not available. It turns out that you would have to allow MSDTC on the service host machine to access the network if the queue is not local.

Turning on network access for MSDTC requires the use of some tools. They are hidden at some not-so-obvious places: you would have to run dcomcnfg, open "Component Services". In some versions of Windows "Component Services" is on the "Administrative Tools" menu, but in some other versions, it is not.

Once you have found "Component Services", you need to go to the properties dialog box of "My Computer". On the "MSDTC" tab, check "Use local coordinator".

We are not done. Under "My Computer" in "Component Services", go to "Distributed Transaction Coordinator", "Local DTC", and go to its properties dialog box. Go to the security tab, and check "Network DTC Access".

All this is too complicated to maintain for a simple WCF service, not to mention the security implications. If you really love MSMQ so much that you have to have it, then this would get it to work. But WCF can work with simpler protocols. These simpler protocols are more reliable and more secure. After all, what MSMQ does is simple, we can live without it.

ReorderList in AJAX .NET Control Toolkit Requires ClientIDMode="AutoID"

When using "ReorderList" from AJAX .NET Control Toolkit, I found that it has a "hidden requirement": its "clientIDMode" attribute must be set to AutoID.

If you look at the AJAX .NET Control Toolkit sample website, its ReorderList sample does not have this attribute set. But the ReorderList sample works fine. How is that possible? It is because this sample site has "clientIDMode="AutoID" set in its web.config file:


<system.web>

...

<pages ... clientidmode="AutoID">

...

</system.web>

In other words, all controls in this sample website have this attribute set automatically!

What happens if you do not have this attribute set on a ReorderList control? Well, you will not be able to drap and drop items to reorder them. If you look at the HTML code that is generated, the "_behavior" attributes that are supposed to go to each "li" element in the item list all get piled onto a single "div" element on the outside, along with the "DraggableListItem" attribute. So when you try to drag an item in the list, you will either get no response, or a stop-sign icon.

Running Remote Desktop Connection in XP Mode of Windows 7

Many VPN clients would lock up network connection so that all traffic goes to the VPN gateway. You cannot browse the internet or make other internet connections from your computer without going through the VPN gateway.

To get around this restriction, we can use Windows 7's XP mode. We can run the VPN client and a remote desktop connection on Windows 7's desktop from the XP mode virtual machine. The XP mode virtual machine will then hold the exclusive connection to the VPN gateway.

However, setting up such an arrangement is far from easy. Normally, if you go into the XP mode virtual machine, and add a shortcut to a program in the folder
\Document and Settings\All Users\Start Menu\Programs,
the shortcut will show up in the Windows 7 host's start menu under "Windows Virtual PC", "Windows XP Mode Applications".

This does not work for Windows XP's Remote Desktop Connection. If you add a shortcut to \Windows\system32\mstsc.exe in that folder, the shortcut does not show up in the Windows 7 host's start menu.

There are a couple of suggestions on the internet that can fix this: one is to create a batch file that calls \Windows\system32\mstsc.exe, and then add a shortcut to this batch file in the folder
\Document and Settings\All Users\Start Menu\Programs
The other involves editing the shortcut file on the Windows 7 host.

I would like to offer another alternative. If you save your connection to another machine in a .rdp file, you can create a shortcut to this file in
\Document and Settings\All Users\Start Menu\Programs,
and this shortcut does show up in the Windows 7 host's start menu.

However, Windows XP's Remote Desktop Connection does not work well on Windows 7 host's desktop. It shows two windows for one. One is a local input capture window, and one is the remote desktop. When you minimize the remote desktop, the local input capture window stays, and cannot be hidden easily.

The solution is to install a Windows 7 virtual machine. The Windows 7 virtual machine can integrate with the Windows 7 host the same way as a XP mode virtual machine. The path for the shortcut is a little different. It is \ProgramData\Microsoft\Windows\Start Menu\Programs, not \Document and Settings\... as it is under XP mode virtual machine.

The virtual Windows 7's Remote Desktop Connection works flawlessly on the Windows 7 host's desktop.

Please note that you must install VPN client in the virtual machine, and you may need to run the VPN client from the Windows 7 host's start menu before starting the Remote Desktop Connection from the same menu folder.

AJAX Control Toolkit and .NET 4.0

If you would like to build a .NET 4.0 web application with Visual Studio 2010, and you would like to build the AJAX Control Toolkit from its source with .NET 4.0 as well, you may run into a little problem. Even though you can build the AJAX Control Toolkit itself just fine, but when you build your web application, the compiler will give an error: "Inheritance security rules violated by type: 'AjaxControlToolkit.TabPanelDesigner'. Derived types must either match the security accessibility of the base type or be less accessible."

A quick solution to this problem is to add the following to the "AssemblyInfo.cs" file of the AJAX Control Toolkit project (not your own web application project):

[assembly: SecurityRules(SecurityRuleSet.Level1)]

Of course, at the beginning of this file, make sure that you have

using System.Security;

After you have made these changes, rebuild the AJAX Control Toolkit, and then your web application. Your web application should build fine.

Update: A later build of AJAX Control Toolkit now works with Visual Studio 2010 without modification.

MySQL .NET Connector and .NET 4.0

Whe building a .NET 4.0 application with MySQL .NET Connector 6.2.2, you may get an 0x80131515 error from the SGEN utility, saying that the operation is not supported.

Apparently Visual Studio 2010 does not like the fact that the MySQL DLLs are pulled from the global assembly cache (GAC). If you add file references to these MySQL DLLs in your project, everything works.

To remove MySQL .NET Connector 6.2.2 from the GAC, you have to uninstall it. That is right: you have to uninstall it to use it!

After you uninstall MySQL .NET Connector 6.2.2 from the control panel, you can unzip the MySQL .NET Connector 6.2.2 zip file that you download from MySQL, and then place the files at a location that you can reference from your project.

Add references to these files in your project by browsing to them, you can then build your project with .NET 4.0 without errors.