I got another wierd error today when I tried to upload a new module on one of my Dotnetnuke sites:

ExceptionSystem.ArgumentException: Invalid File or Directory attributes value. at System.IO.File.SetAttributes(String path, FileAttributes fileAttributes) at DotNetNuke.Modules.Admin.ResourceInstaller.PaDnnInstallerBase.CreateFile(String FullFileName, Byte[] Buffer) at DotNetNuke.Modules.Admin.ResourceInstaller.PaDnnInstallerBase.CreateModuleFile(PaFile File, PaFolder Folder) at DotNetNuke.Modules.Admin.ResourceInstaller.PaDnnInstallerBase.CreateFiles(PaFolder Folder) at DotNetNuke.Modules.Admin.ResourceInstaller.PaDnnInstallerBase.Install(PaFolderCollection folders) at DotNetNuke.Modules.Admin.ResourceInstaller.PaInstaller.Install()

Turns out that the system account (Network Service) did not have full permissions on the root folder of the installation. As soon as I set it correctly, this error disappeared.

Recently, when I tried to upload a new module to DotNetNuke, I received the following error:

ExceptionSystem.ObjectDisposedException: Cannot access a closed file. at System.IO.__Error.FileNotOpen() at System.IO.FileStream.Seek(Int64 offset, SeekOrigin origin) at System.Web.HttpRawUploadedContent.TempFile.GetBytes(Int32 offset, Int32 length, Byte[] buffer, Int32 bufferOffset) at System.Web.HttpRawUploadedContent.CopyBytes(Int32 offset, Byte[] buffer, Int32 bufferOffset, Int32 length) at System.Web.HttpInputStream.Read(Byte[] buffer, Int32 offset, Int32 count) at ICSharpCode.SharpZipLib.Zip.ZipInputStream.FillBuf(Int32 size) at ICSharpCode.SharpZipLib.Zip.ZipInputStream.GetNextEntry() at DotNetNuke.Modules.Admin.ResourceInstaller.PaInstaller.ReadZipStream() at DotNetNuke.Modules.Admin.ResourceInstaller.PaInstaller.Install()

To fix it, open the Web.config file and locate the line:

<httpRuntime useFullyQualifiedRedirectUrl="true" ...

I've had to change the port that SQL Server uses to communicate over the Internet several times now, and I'm getting tired of looking it up. Here is is for future reference:

1. Open SQL Server Enterprise Manager.
2. Right-click on the server instance.
3. ClickProperties.
4. Click the General tab, then click the button marked "Network Configuration" to display the SQL Server Network Utility.
5. Find TCP/IP under Enabled Protocols on the right. Highlight it and hit the Properties button.
6. The Network Protocol Default Value Setup dialog will ask for the Default Port for SQL Server. Change this entry to make SQL Server listen on a different port. Click OK to close the dialog.
7. Click Apply on the SQL Server Network Utility screen, then OK.
8. The changes are saved, but they will not take effect until you stop and restart the SQL Server service. ClickOK.
9. ClickOK ...

I am a jack of all trades, so I don't spend too much time on any one task. I just looked at directory where my sql server 2000 databases live and I noticed that my DB logs are huge. One log file was over a gig and a half in size for a 500 meg database. I'm putting it here for my future reference, but I hope someone else can use it, too.

BACKUP LOG <dbName> WITH TRUNCATE_ONLY

DBCC SHRINKFILE(<dbName>_Log, 2)

The Unspecified Error I wrote about not long ago came back on my server. I thought that reinstalling ASP.Net would fix it once and for all but I was wrong. I installed a new antivirus product called NOD32 and ran a full scan. It found a few little cyber-squatters sitting on my machine and disabled them. They were:

Win32/HacDef trojan
Win32/VB.NEI worm
HTML/Amazofraud.N trojan

Hopefully, they were the problem. I just finished reinstalling ASP.Net again, so we'll see how it goes this time around.

I HATE it when I have tried and tested code working that just mysteriously stops working. This particular time the problem lies around OLEDB access to Excel. I was doing a simple Select * from [Sheet1$] when all the sudden I started getting this ugly, useless error:

System.Data.OleDb.OleDbException: Unspecified error at System.Data.OleDb.OleDbConnection.ProcessResults(Int32 hr) at System.Data.OleDb.OleDbConnection.InitializeProvider() at System.Data.OleDb.OleDbConnection.Open() at System.Data.Common.DbDataAdapter.QuietOpen(IDbConnection connection, ConnectionState& originalState) at System.Data.Common.DbDataAdapter.FillFromCommand(Object data, Int32 startRecord, Int32 maxRecords, String srcTable, IDbCommand command, CommandBehavior behavior) at System.Data.Common.DbDataAdapter.Fill(DataSet dataSet, Int32 startRecord, Int32 maxRecords, String srcTable, IDbCommand command, CommandBehavior behavior) at System.Data.Common.DbDataAdapter.Fill(DataSet dataSet, String srcTable) &l ...

I needed to rewrite the URLs for DotNetNuke for SEO purposes. Here's how to do it.

1. Open the SiteURLs.config file located in the root directory. Optionally, use the Friendly URL settings interface in Host Settings.

2. Figure out what you want the URL to be and how to write the URL with Querystrings. Add an entry in the SiteURLs.config file like below. Regular expressions can be used, but because I want each page to show up a particular way, I have to explicitly specify each one. Lookfor is the one you want to show up, and Sendto is the real URL with querystring.

   
     <RewriterRule>
      <LookFor>.*/HorsebackRiding/MendesRanch.htm</LookFor>
      <SendTo>~/Default.aspx?tabid=78&a ...

I decided to try my custom dotnetnuke shopping cart module on a different version of DNN to see how it fared - a common practice among dotnetnuke module developers. I installed a new DNN instance and then used a template to set everything up. The version test went great, but the second I tried to add a new text module to the home page, the installation became corrupted and I couldn't recover it. After retracing my steps, I figured out that the cause was a some difference in the portal export feature. Lesson learned - only use create new portals from templates made in the same version of DNN.

I put in a support call with my host and I just got a cheery response.

Unfortunately, your server has already been compromised.  We found WINNT/system32/rdriv.sys.  The rdriv.sys is the Rbot.aja worm.  The only recourse, at this point, is to reload your operating system on a new primary hard drive.

The virus attacks a weakness in the SMTP service in older versions of Mailenable. The search has come to an end and the misbehaving of applications will cease.