The build broke again. It seems to have been the same root cause as the last break. The build machine has something different about its configuration which caused it to reject code which was allowed on a developers clean installation of Visual Studio 2008 and the Microsoft.NET framework.
The moral of this story: Don't ignore the first failure, since the root cause of the failure won't "just go away" until it is understood and repaired.
Tuesday, May 12, 2009
Thursday, May 7, 2009
End of day anti-pattern
I made a foolish mistake today. I should have known better... Now it is time to resolve to make new and different mistakes tomorrow, instead of making this same mistake yet again.
Wait For Green
Two of the programs used for our installation only make sense when run as an administrator. The Windows Vista and Windows Server 2008 user account control (UAC) code does not allow administrator privileged users to run programs as an administrator unless they explicitly select "Run as Administrator", or if the program has been marked with a manifest which tells the operating system to always run this program as an administrator.
Those two programs were using the default manifest, and one of the two was adding itself to the "Start Programs" menu. When a Windows Server 2008 user clicked the program with user account control enabled, it crashed painfully and offered to send a report of the problem to Microsoft. We didn't want that.
Visual Studio has an easy way to add manifests to applications, and it seemed simple enough that even a manager could do it...
I made the change, compiled the code, reviewed the code with a real programmer, and let it sit for a few days. This evening, just before leaving for home, I submitted it to the source master and left the building for the swim team dinner.
Don't Do That!
That was a mistake. The compilation failed on the production build machine, even though it had worked flawlessly on my machine. Apparently the production build machine has a different version of one of the compiler components in its path, and that different version did not recognize the options inserted by my version of the Visual Studio IDE. Ugh.
Check the Continuous Integration Server After You Commit!
I've reverted my change, but not after keeping someone else up late into the night because I was not paying attention to the results of my code change.
(There's another thing which is "have fast continuous integration", but we're still working on that...)
Wait For Green
Two of the programs used for our installation only make sense when run as an administrator. The Windows Vista and Windows Server 2008 user account control (UAC) code does not allow administrator privileged users to run programs as an administrator unless they explicitly select "Run as Administrator", or if the program has been marked with a manifest which tells the operating system to always run this program as an administrator.
Those two programs were using the default manifest, and one of the two was adding itself to the "Start Programs" menu. When a Windows Server 2008 user clicked the program with user account control enabled, it crashed painfully and offered to send a report of the problem to Microsoft. We didn't want that.
Visual Studio has an easy way to add manifests to applications, and it seemed simple enough that even a manager could do it...
I made the change, compiled the code, reviewed the code with a real programmer, and let it sit for a few days. This evening, just before leaving for home, I submitted it to the source master and left the building for the swim team dinner.
Don't Do That!
That was a mistake. The compilation failed on the production build machine, even though it had worked flawlessly on my machine. Apparently the production build machine has a different version of one of the compiler components in its path, and that different version did not recognize the options inserted by my version of the Visual Studio IDE. Ugh.
Check the Continuous Integration Server After You Commit!
I've reverted my change, but not after keeping someone else up late into the night because I was not paying attention to the results of my code change.
(There's another thing which is "have fast continuous integration", but we're still working on that...)
Subscribe to:
Posts (Atom)
