Friday, May 28, 2010

Windows SDK 7.0A and automated builds

We altered our solution and project files to work with Visual Studio 2010. After changing the path to MSBuild.exe and altering ToolsVersion in the ccnet.config file to accommodate the framework change, CruiseControl.NET reported the following error:

C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets (1917,9):
errorMSB3086: Task could not find "LC.exe" using the SdkToolsPath "" or the registry key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A".
Make sure the SdkToolsPath is set and the tool exists in the correct processor specific location under the SdkToolsPath and that the Microsoft Windows SDK is installed

Various posts indicate that the 7.0A SDK ships with Visual Studio 2010. With that knowledge I copied the directory "Program Files\Microsoft SDKs\Windows\v7.0A" from my development machine to my build server. I then exported the "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A" registry key from my development machine and merged into the registry of the build server. Problem solved.

Wednesday, May 12, 2010

TNSNAMES.ORA and spaces

Just when Oracle database and I had forged an uneasy peace, my day was derailed by my mistake.

When Oracle tells you that "[t]he service name must begin in the first space of a line to be parsed correctly" they are not kidding. I received a request from one of our DBA's to change a server's TNSNAMES.ORA file and copied and pasted the new entry. The three (3) leading spaces on that entry caused me to get "ORA-12154: TNS: could not resolve the connect identifier specified" errors for an hour until I realized my mistake.

Don't let this happen to you. Heed the warning of Oracle.