I found the following breaking change in the MSDN article "Development Impacts of Security Changes in Windows Server 2003" by Michael Howard:
DLL Search Order Has Changed
No longer is the current directory searched first when loading DLLs! This change was also made in Windows XP SP1. The default behavior now is to look in all the system locations first, then the current directory, and finally any user-defined paths. This will have an impact on your code if you install a DLL in the application's directory because Windows Server 2003 no longer loads the 'local' DLL if a DLL of the same name is in the system directory. A common example is if an application won't run with a specific version of a DLL, an older version is installed that does work in the application directory. This scenario will fail in Windows Server 2003.
The reason this change was made was to mitigate some kinds of trojaning attacks. An attacker may be able to sneak a bad DLL into your application directory or a directory that has files associated with your application. The DLL search order change removes this attack vector.
SetDllDirectory function, also available in Windows XP SP1, modifies the search path used to locate DLLs for the application and affects all subsequent calls to the
LoadLibraryEx functions by the application.
via Paul Wilson.
There's has been an informative discussion in CodeProject's Lounge regarding cached file dates.
Here some quotes from MSDN:
A file time is a 64-bit value that represents the number of 100-nanosecond intervals that have elapsed since 12:00 A.M. January 1, 1601 (UTC). The system records file times whenever applications create, access, and write to files. Not all file systems can record creation and last access time and not all file systems record them in the same manner. For example, on NT FAT, create time has a resolution of 10 milliseconds, write time has a resolution of 2 seconds, and access time has a resolution of 1 day (really, the access date). On NTFS, access time has a resolution of 1 hour.
and in the documentation of CreateFile:
Windows NT/2000: If you rename or delete a file, then restore it shortly thereafter, Windows NT searches the cache for file information to restore. Cached information includes its short/long name pair and creation time.
I've updated my site to .Text .94 , but unfortunately I have had some issues, though I followed Scott's instructions . Maybe I did something wrong during the setup, but here are my changes to the aggregated version of
web.config to get my site working:
Whenever I tried to go to the admin section of a blog, I got an error. .Text complained about missing templates of the admin pages. Therefore, I added following entries to the
<add key="Admin.DefaultTemplate" value="~/Admin/Resources/PageTemplate.ascx" />
<add key="Admin.DownlevelTemplate" value="~/Admin/Resources/PageTemplate.ascx" />
<add key="Admin.DefaultContent" value="PageContent" />
The authentification was set to Windows. I switched back to Forms authentification:
<forms name=".ASPXFORADMIN" loginUrl="login.aspx" protection="All" timeout="90" />
Steve ~~~~ mentions to change the httpHandlers. Hmm, there is no
httpHandlers section in my
web.config. I admit I was already wondering when Scott moved all the handling stuff to blog.config. Someone has to tell ASP.NET to use that. Therefore:
<add verb="*" path="*" type="Dottext.Framework.UrlManager.UrlReWriteHandlerFactory,Dottext.Framework" />
With these modification my .Text installation works like a charm :-)
ASP.NET 1.1 validates the input, so I cannot use HTML in my posts. I've added following line:
<pages validateRequest="false" />
Ooops, my fault. I was using the out-dated
web.config. Note to myself: RTFM.
After I updated my .Text sources two day ago from the official workspace, I wasn't able to post anymore, because some essential stored procedures were missing. Meanwhile, Scott has updated the sources. I'm back on-line.
I don't know what others think, but IMHO the quality of the preview images generated by .Text isn't as good as it could be. Currently it just resizes the images with the simplest algorithm existing in the .NET framework.
Therefore, I've patched the sources, so it will use bicubic interpolation. Here's a comparison:
Maybe Scott wants to commit my changes to his sources, so here's what I did: The image conversion happens in the method
Dottext.Framework.Images. I've added another method which does the resizing, and added the calls to it in the original method. Following the affected code snippet, I've marked my changes bold:
public static void MakeAlbumImages(ref Dottext.Components.Image _image)
System.Drawing.Image original = System.Drawing.Image.FromFile(_image.OriginalFilePath);
Size _newSize = ResizeImage(original.Width,original.Height,640,480);
_image.Height = _newSize.Height;
_image.Width = _newSize.Width;
System.Drawing.Image displayImage = ResizeImage(original,_newSize);
System.Drawing.Image tbimage = ResizeImage(original, ResizeImage(original.Width,original.Height,120,120));
private static System.Drawing.Image ResizeImage(System.Drawing.Image original, Size newSize)
System.Drawing.Image result = newBitmap(newSize.Width, newSize.Height);
using(Graphics g = Graphics.FromImage(result))
g.InterpolationMode = System.Drawing.Drawing2D.InterpolationMode.HighQualityBicubic;
g.DrawImage(original, 0, 0, newSize.Width, newSize.Height);