February 2004 - Posts
An interesting read on how developers prioritize various information resources.
Steven Smith of ASPAlliance gave a presentation about caching last night at the Vermont .NET Users Group last night. It was a no-nonsense, productivity focused presentation which I found useful. I'm not yet spending any time with Whidbey personally or even thinking about it, but I really liked how Steven showed how caching works today and how it will work (better!) in Whidbey, both with SQL7/2000 and Yukon. Thanks, Steven!
As always, a big thanks to Julia Lerman and INETA for making last night happen.
Code Magazine has become my favorite technical magazine. This month's issue
is a focus on Office 2003. Anyone doing any Office development (like I have just begun to do) needs to check this out. Thanks Code Magazine!
The InfoPath SDK had good setup documentation. As a Windows Server 2003 I have spent energy (and several weblog post sessions) on IIS configuration issues. I found the following excerpts particularly dear to my recent W2K3 experiences.
...For IIS 6.0 in Windows Server 2003, the Application pool list box should be set to DefaultAppPool. The default user for that application pool is the local Network Service.
...In Windows Server 2003, you must add the IIS Worker Process Group, with the permissions check boxes selected for Modify, Read & Execute, List Folder Contents, Read, and Write. This group includes the local NT Authority\Network Service user. Click Add, and then select the local system name (the computer name) for the Location in which to search for the user. Enter IIS_WPG, and then click Check Names. The group [system name]\IIS_WPG should then be added.
I spent the day with the InfoPath SDK. Hey, great rhyme.
Several months back when I first began exploring .NET support for Office 2003 I posted my wish for more .NET support in Outlook along with advertised support for its Word and Excel 2003 counterparts. An MS MVP who I won't impune here was kind enough to respond that it didn't happen because there are only 24 hours in a day. He also gave his opinion that he felt the implementation of .NET in Word and Excel was “hoaky” anyway.
Since its now gettin' real and I am obligated to have a working InfoPath form online with data populated and processed via Web Services sometime this week, I'm getting a taste for that “hoakiness” first hand. Whenever I see a whole bunch of jscript and vbscript code to make a product perform its basic functions, I resent it. InfoPath reminds me of Sharepoint 1.0. If you wanted to do anything with a webpart, it was time to whip out some VBSCRIPT, baby! Geee-zus.
I didn't find the InfoPath SDK very accessible either. Smart people provided some good code, but making the leap from the samples provided to a real world eform was not an easy one. The SDK did help me though, certainly, and I recommend it. I also highly recommend a PerfectXML InfoPath article (though dated at April 2003) which after a long day of pouring over the SDK I did find accessible and is what I will base my Day Two InfoPath investigations in the AM.
I was banging my head against the wall trying to resolve this incident yesterday but had to step away from it only because my little girl's pre-ballet class had a recital. (Other than my video camera battery dying halfway through the dancing it was great.)
I hated to leave my problem though. Oh, I knew it would be waiting for me to fix later, which I did around 11:30 last night, but I thought at the time how I so much thrive on working through a problem until its resolved. I find no advantage in “stepping away from a problem” to see it in a different light or anything. Then I saw this excellent (and funny!) post from Julie Lerman this morning, where even bathroom breaks are avoided.
I have for a long time believed that a characteristic of a good developer was their drive and obsession with completing a task or fixing a problem. Just doin' it until its done. No excuses, no distractions, head down, think it through, fix the damned thing, figure it out. Anyway....
This falls under the “another W2K3 butt-kicking” category as well as “looking at the process and not the error to resolve the error.”
I was trying to save a file to a W2K3 directory and kept getting the error below, telling me I could not write to the c:\inetpub\uploads\docs folder. Or so I thought...
Access to the path "C:\Inetpub\uploads\Docs\003006000019.txt" is denied.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.UnauthorizedAccessException: Access to the path "C:\Inetpub\uploaded\Documents\003006000019.txt" is denied.
Complete error page is here.
I went through my entire trickbag of IIS_WPG, Local System Policy updates on the Application Pool identity, ensuring NETWORK SERVICES and the app pool identity had write access to the folder, spinning my wheels.
Then I looked again at the stack trace.
System.IO.File.Move(String sourceFileName, String destFileName) +305
Wait a minute. If the code is MOVING a file, then write/modify permissions are required on the SOURCE directory. The permissions problem was on the SOURCE directory, yet the IIS error was telling me the permissions problem was on the DESTINATION directory.
The IIS error pointing to the destination was curiously incorrect, but I should have thought about the process generating the error rather than the IIS error itself to more quickly resolve the problem.
This is the 4th W2K3 Server I've setup (I do the web and SQL stuff; my very excellent Systems Admin does everything else) and each time I learn something new as I've posted in previous “To W2K3” entries.
This was a straightforward lesson. IIS6 displays a
The page cannot be found
message when I know the page is there. Full display here. From previous experiences I could conclude that something was missing or turned off in IIS. Seems the ASP.NET subcomponent in the Windows Components Wizard was not installed. Installing it did the trick.
More Posts « Previous page