by Allan Sieker

When it comes time to write an interesting article about a technical topic my mind goes into a deadlock in trying to find the balance between space/time constraints and keeping the content interesting.  Too short of an article and it seems trivial because the technical stuff doesn’t get covered enough.  Too technical, and the article becomes long and boring.  All the while, wanting to keep things original, informative, and light.  So did I end up with?  How about a series of related articles that covers something that is near and dear to all of us?   

 I bought my first computer in 1978 (yes, I still have it) and as my home network expanded to what it is now – several servers, workstations, and laptops, the need for keeping a file inventory goes with the territory.  Sure, over the years I created my own file databases written in several languages (BASIC, Pascal, dBASE, Clipper, VB, C#) and they all served their purpose, but technology keeps improving and I always want more.   

 What if data warehousing concepts were applied to capture the “slowly changing dimension” of file updates?  What if file collections were recognized and managed as applications and other entities?  What if all of the computer file inventories were gathered locally then stored centrally for searches via a web interface?   What if backup history were also available?

 This article series will cover a broad range of technical topics with the end goal being a respectable system for home or business usage.  Concepts will be discussed and code will be available for download.  References to other articles and postings will also be made.

 Here is a brief list of planned topics: 

• Using recursive methods to collect file information from all of the folders on a drive.
• Creating console and Windows “file agent” applications to collect file data and write to an XML file.
• Creating a SQL Server file inventory database.
• Balancing cost and architecture to avoid over-costing and over-engineering.
• Importing “file agent” XML into the database.
• Creating an ASP.NET web application for searching and retrieving application & file information.
• Making “file agent” applications downloadable from the web site using ClickOnce.
• Using the Visual Studio Report Designer and the ReportViewer control to create web reports.
• Creating a “wrapper” application for Microsoft’s Backup to manage and track backups.
• Detecting media and image file duplicates based on file content instead of file name.

 Feedback is always welcome.

by Allan Sieker

The story you are about to hear is true and should be of interest to all web developers – be you .NET or not.

A few businesses I know had issues with web site connectivity a few weeks ago.  Some computers could connect while others could not.  IE 8 seemed to have more of a problem than IE 7.   The client could access other web sites ok.  Client locations were across the US and not all local (the St. Louis area).
Read the rest of this entry »

by Allan Sieker

The Overview

   “We do not pretend to have achieved perfection — but we do have a system — and it works.”  – Klaatu

When developing ASP.NET web applications a very common approach to maintaining state is to store variables into the Session.

Session is just one way to store data. Here are some other ones that I know of. Can you think of any others?

• Application (global) – uses server memory.
• Session (user) – can use user memory and/or database storage.
• Data cache (global, but can be user specific with proper handling) – uses server memory.
• Viewstate (web page) – rides along with the page.  No server memory.
• Database (global and user) – includes SQL, XML, local files, etc.
• Cookie (user) – stored on the client’s computer and accessed via the browser.
• Query String (user) – doesn’t use server memory – just a lot of developer patience.
• Form fields (web page) – popular in HTML and classic ASP development.
Read the rest of this entry »

The bottom line much of the time, is that developers are creatures of habit… much of what we do, we do because that is what we do, and we have no better reason than that. Perhaps the first time we do something we thought it through, but rarely do we go back and revise those thoughts, and conciously choose a different direction, ideology or methodology… for me this is the case with my choice of choosing Website over WebApp for my development.

Recently I began a new project with a co-worker, and although we discussed every aspect of the project, the coding, the tools, the flow, basically every detail as to what was ahead of us, we never addressed whether this would be a WebApp or a Website project. As I began coding my first page of this project, the dev environment was different, my options had changed, and I knew we had not addressed a fundamental decision that we should have addressed.
Read the rest of this entry »

Recently our organization (The Net Impact) made the decision to rebuild our entire development environment. As most know this can be both a daunting and yet exciting venture. During the planning phase we had numerous discussions concerning which source control utility to implement and we finally decided to test Subversion versus Microsoft Team Server.

One of the complaints I have had in the past with Subversion is how clunky interfacing with it has been. I feel that in this day and age any command line interface is past its prime, and having to run external third party interfaces is simply annoying. I wanted something fully integrated into our development tools mimicking the functionality of eclipse and PVCS I had used years back.
Read the rest of this entry »