Those of you who use both the (excellent) Subversion open source control system, and Visual Studio 2003, are ubdoubtedly familiar with the “incompatible .svn folder” problem. Here is a quick-and-dirty solution.

By convention, Subversion holds all local source control data for a checked-out tree in hidden folders named .svn under each ‘content’ folder. This scheme, however, causes problems with Visual Studio 2003 and ASP.NET 1.1: the VS IDE has a problem when talking to the server and refuses to load projects with such folders in their structure (even though the folders do not contain any VS-readable source, but are just a facility to track history)

svn_vs2003_fix is a command-line based utility that performs a recursive rename of a given tree, renaming all .svn folder names to _svn or vice versa. This allows SVN to work with ASP.NET 1.1 in the following manner:

** Before using the source control system, invoke:
svn_vs2003_fix <the_webapp_tree_physical_folder> .
This will rename any _svn folders in the tree structure to .svn, and you’ll be able to use Subversion or any other common front end tools (such as Tortoise)

** Before doing any IDE work on the site, invoke:
svn_vs2003_fix <the_webapp_tree_physical_folder> _

Any .svn folders will be renamed to _svn; this will preserve all Subversion data (even though it will be temporarily unavailable to Subversion) and, at the same time, make the source tree readable to the VS IDE.

The utility is distributed absolutely free; get it here.

One of Delera’s key clients - a highly successful vendor of MS SQL Server value-added tools - has just posted “SQL Server 2005 Still has a Dependency Problem” on their company’s blog.

I don’t normally discuss our client’s products or business, but since I drafted that post, I thought I’d share a link with you here. It’s a good sample of the intricacies involved in writing software - especially when that software’s user-visible surface is just the tip of the iceberg. Also a good example of why developers just love doing ‘core programming’. It’s an extremely satisfying pursuit.

[link]

“Why do you do it? Why go to the hassle of working in a small team when all you get is long working hours, and clients who are bigger than you so they can push you around however they like? Why not join an established software company and run a team of people, go home at six and never fret over actual revenue - your paycheck will be coming anyway?”

This is a question I (and most other small consulting shop / ISV owners) get on a regular basis. Answering it properly would take a book - and indeed, there are a great many books on the subject of enterpreneurship out there. Suffice to say that I’ve been there, done that.

Today I’d like to present you with an answer. I am quite sure you will like it. This comes from a post from Joel on Software’s forums, and is reprinted with permission. The author wishes to remain anonymous (although I’d very much like to shake his hand and buy him a drink sometime.)

(more…)

We recently completed the first version of a complicated Excel data import tool (written in .NET) for one of our clients. Writing a .NET extension for the Excel environment proved to be more difficult and quirky that originally thought. It was also rather underdocumented, so I thought I’d share some of our experiences here.

Step 1 was determining the general architecture. Basically, we wanted to build a WinForms-based C# assembly with both user interface dialogs and extensive business logic in it. This assembly would run in the Excel environment as a pop-up window displayed over a user-supplied spreadsheet. Users would make a selection in the spreadsheet (identifying particular “data zones”) and click on an Excel toolbar button to bring up some additional dialogs - produced by the assembly with WinForms. The assembly would then proceed to verify and clean up the cell contents, and store it in a SQL Server database for further processing.

One option to approach the problem would be VSTO - Visual Studio Tools for Office, produced and sold by Microsoft and specifically aimed at writing Office extensions in a general-purpose programming language. We decided against VSTO because it only works with the most recent versions of Office, and we wanted Excel 2000 / .NET Framework 1.1 compatibility.

So we went ahead and devised the following architecture:

[MS Excel] –> [XLA add-in] –> [VC++ Shim] –> [C# Assembly]

(Why is the shim necessary? Can’t the C# assembly expose a COM interface to VBA directly? I’ll get to that in a minute)

Here’s some of the most important things we have learned in the process.

(more…)

(A story of how we gave a tremendous speed boost to Str Library’s small block cache manager)

The last few days we got to code a feature for Str Library that’s been sitting on the table for far too long. Specifically, we did an advanced small blocks cache that was even faster than the previous one. The smart part was to move to a TLS (thread local storage) based block cache.

One of the chief advantages of Str Library has always been its superior performance in a heavy multithreading environment. Under this scenario the major part of thread synchronization calls are used for two purposes: to synchronize access to the small blocks cache, and to perform thread-safe reference counting of those Str instances that have been specifically marked as MT-enabled.

The small blocks cache is a clever mechanism designed to dramatically improve speed when using dynamically allocated memory blocks. And string class implementations inevitably need to perform this operation very often. Basically, every creation of a new string (unless it’s a copy of a previous instance) involves allocating a memory block; this also applies to most concatenation operations and other methods that increase a string’s character count.

(more…)

These days one of our devs was stung by what seemed like a really bad bug in Str Library’s regular expression support.

You can imagine what fun you have when the custom code you’re writing fails because of a defect in your own product! Hmmph, time to send out a warning email to all our users, I thought.

Then we looked into the problem a bit deeper and found that it wasn’t really a bug; we had an issue in our expression and Str Library, instead of refusing to ‘compile’ the regex, just went ahead with it but produced wrong results. Well at least Garbage In, Garbage Out wasn’t our fault - it’s an age-old principle in IT with relevancy that continues to amaze me as the years go by.
(more…)

Next Page »