That's an explanation any developer dealing with end-users very likely have heard. In fact almost always it can be translated as "the stupid thing is not working; I have changed something that I'm not aware of; I cannot find yet a suitable person or entity to blame for; fix it fast because I'm already two days late with my report!".
Very nice, then today I am such an end-user. The data part of a .NET WinForm application throws an exception. One of the following postulates for sure must be false:
- "this morning everything worked"
- "I swear I did not change anything"
To make it short, in app.config I have created the appSettings section preceding the connectionStrings section. It is not my first visit into this little trap.
Once I remember I heard from a user that "we did not change anything really, just installed new Office version".
Tuesday 31 May 2011
Tuesday 24 May 2011
Wow6432Node, accessing Windows Registry from ASP.NET app
My old ASP.NET application reads part of its configuration data from the Windows Registry. Certainly a questionable approach, but that's how it is. The application is currently running on W2K server. Soon enough it will be moved to Windows 2008 64-bit server.
During recent tests on the new hardware I found that the application was no longer able to read from the Registry. First I guessed that the new system's stricter security was a reason. Changing registry key's permissions did not help. Creating a separate IIS application pool and running it under a privileged user account did not help either.
Meanwhile a test application had not trouble enumerating subkeys inside HKEY_LOCAL_MACHINE\SOFTWARE, but strangely it could not access HKEY_LOCAL_MACHINE\SOFTWARE\[MyApplicationRoot]. Strangely it was until I noticed that the enumerated subkeys were not exactly the subkeys the Regedit displayed.
A quick search using the Regedit revealed that HKEY_LOCAL_MACHINE\SOFTWARE enumeration on 64-bit system actually enumerated subkeys inside HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node. That's where I moved the keys of my application and finally had this issue resolved. No source code changes were required.
Read more about registry redirection:
http://msdn.microsoft.com/en-us/library/ms724072(v=vs.85).aspx
Private Sub ListRegistryKeys(ByVal strKey As String)
Dim rk As Microsoft.Win32.RegistryKey = _
Microsoft.Win32.Registry.LocalMachine.OpenSubKey(strKey)
Response.Write("Subkeys:<ul>")
Response.Write(String.Format("<li>{0}", _
System.Security.Principal.WindowsIdentity.GetCurrent().Name))
For Each skName As String In rk.GetSubKeyNames()
Dim sk As Microsoft.Win32.RegistryKey = rk.OpenSubKey(skName)
Response.Write(String.Format("<li>{0}", sk.Name))
Next
rk.Close()
Response.Write("</ul><hr>")
End Sub
During recent tests on the new hardware I found that the application was no longer able to read from the Registry. First I guessed that the new system's stricter security was a reason. Changing registry key's permissions did not help. Creating a separate IIS application pool and running it under a privileged user account did not help either.
Meanwhile a test application had not trouble enumerating subkeys inside HKEY_LOCAL_MACHINE\SOFTWARE, but strangely it could not access HKEY_LOCAL_MACHINE\SOFTWARE\[MyApplicationRoot]. Strangely it was until I noticed that the enumerated subkeys were not exactly the subkeys the Regedit displayed.
A quick search using the Regedit revealed that HKEY_LOCAL_MACHINE\SOFTWARE enumeration on 64-bit system actually enumerated subkeys inside HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node. That's where I moved the keys of my application and finally had this issue resolved. No source code changes were required.
Read more about registry redirection:
http://msdn.microsoft.com/en-us/library/ms724072(v=vs.85).aspx
Private Sub ListRegistryKeys(ByVal strKey As String)
Dim rk As Microsoft.Win32.RegistryKey = _
Microsoft.Win32.Registry.LocalMachine.OpenSubKey(strKey)
Response.Write("Subkeys:<ul>")
Response.Write(String.Format("<li>{0}", _
System.Security.Principal.WindowsIdentity.GetCurrent().Name))
For Each skName As String In rk.GetSubKeyNames()
Dim sk As Microsoft.Win32.RegistryKey = rk.OpenSubKey(skName)
Response.Write(String.Format("<li>{0}", sk.Name))
Next
rk.Close()
Response.Write("</ul><hr>")
End Sub
Subscribe to:
Posts (Atom)