Scott Weinstein's .net blog

I love .NET. when I first started hearing about it my reaction was - "great I can get full access to the windows platform without having to learn C++". The small forays I'd made into past into the world of  COM and the windows platform always left me feeling overwhelmed and vastly uneducated.

They said .NET had a good "story" around COM integration. But as it turns out I find myself learning more about COM than I ever thought I would.

I finally understand what IUnknown and all those "punk"s are about, and that's cool. But I shouldn't have to -  I mean if VB6 can sink events from PowerPoint 2000 -  why should I have to go through so much extra effort to do it in .NET? I'm grateful that Microsoft has provided the answers to this particular problem, but without that assistance I never would have figured it out.

You're Singapore!
You're small but well-built and people are a little afraid of you.  You might even walk with a cane that people find somewhat menacing, rather than seeing it as an aid to your mobility.  You like an urban lifestyle, with little time for nature or the more rural pleasures of life.  This fast-paced lifestyle suits you, and you wish everyone around you would just shape up.
Take the Country Quiz at the Blue Pyramid

I'm still far from version "1.0", but my .NET class libraries for Documentum are nearing the point where demo applications can be created.

But I'm torn, should I make these libraries freely available, or should I try my luck and charge a fair market price.

On one hand I've greatly benefited from the vast library of free software - Back in my UNIX days I cut my teeth on Linux, GCC, Perl, Emacs, and Apache.  More recently I've been using NUnit and CodeSmith - great tools, both of them.

But development cost money  - most significantly VS.net licenses and the cost of my time.

I'd like to get some recognition of this - whatever that means,  and the freeware approach is likely to have a higher user adoption rate, a freeware approach also has the benefit that I can walk away from it at any point. 

The commercial approach is more likely to yield a better product, and I think I'd be more pleased with a successful commercial venture then a successful freeware venture. I might even make some money.

Thoughts anyone?

I recently got into a conversation with a coworker who want me to make the switch from SourceSafe to CVS . He had three reasons for why should I switch. CVS was free, it's more stable then SourceSafe,  and it's (almost) the new standard for the company.

This topic has come up before - when all the Unix guys made the switch from  SCCS to CVS - the big feature of CVS was that it was concurrent. I did a quick evaluation of CVS and it seemed like it was gonna be a lot of trouble to switch and once I learned that VSS does in fact support concurrent checkouts all the reasons switch evaporated.

But the conversation got me thinking - was I just being a stubborn ass in refusing to switch - was the ease of integration really worth the risk of the SS instability.

And I think it is.  The risk of the VSS database corruption is just that a risk. Tt might happen, it might not. If it does occur the damage will vary. From what I've seen their risk of the SS database corruption is low (but not zero) and the extetent of the damage is small . However switching has immediate unavoidable costs. First converting the database, then configuring CVS to understand windows development files - for example the .frm/frx VB6 file pairs. Learning the new commands, and there's the constant small irritation of having to think about source control rather than it just being a background feature.

I just learned from the daily grind about a new CVS SCC proxy. It didn't work for me, but such a thing could possibly change my opinion in the near future.

For Momentum, I’m rewriting my document .NET class library. This library has two components, the first is an ADO.net provider for Documentum’s SQL like query language – DQL. The second, is a set of generated strongly types classes that map to Documentum types.

      dt.fields(“object_name”)  = “test”

We can write

dt.object_name  = “test”

I’m rewriting this class library for three reasons. Yes, Joel makes a very good case, that this is something you really shouldn’t do, however there are some good reasons. The first and most persuasive reason is legal. The original version is owned by and my employer, however since there is no intellectual property agreement it’s simply a copyright restriction, and re-coding gets around that.

The second reason has to do with some flaws in the original. The most serious flaw is the decision to build into one assembly both the core data access code and the generated types code. This prevents using the class library with two different schemas, and makes the possibility of distributing the library much more difficult. The second design flaw had to do with the structure of the internal class libraries, because the lowest level of the library makes a bunch of Interop calls to the dmcl.dll, I coded that as a set of static methods – bad idea. This was a mistake for two reasons, the connection info was stored in a higher level class DqlConnection, and this restricted the inner class from knowing, without exception, what the connection was. Normally this wouldn’t be a problem because the connection info was always passed to the static methods, however, in error situations, this became a real problem. The second problem with this separation was that it needs of making the class library thread safe much more difficult. Instead of having 4 critical sections – one for each method that does Interop calls, I need one for each method that makes a call to the Interop class.

The third reason for a rewrite is social - should I decide to release this version for public consumption, I think I’ll have better reception if it’s coded in C# rather than VB.net.