Behavior change in Server 2003 SideBySide?

May 3, 2006 at 6:09 pm · Filed under .NET, Grid Computing

In my previous post, Ah, it was DLL hell, I said I still have a problem. The problem is with Server 2003 registration-free COM and a custom-generated manifest. XP and Server 2003 have different requirements for the location of dependent assemblies, so it isn’t suprising that they might behave differently. Anyway, now that I’ve gotten past my initial issue, the problem is clear. Well, as clear as can be expected with registration-free COM.

The event log said (reformatted and abbreviated for readability):

Syntax error in manifest or policy file 
"C:\\ . . . \\DigipedeAutoManifest.manifest" on line 4. 
The value of attribute "name" 
element "urn:schemas-microsoft-com:asm.v1^file" is invalid.

The name attribute was a full path to the DLL containing the COM server to be activated. I changed it to a relative path and now it works just fine. The DLL is in the same directory as the manifest (rooted below the executable).

I know for a fact that the full path used to work on Server 2003. I can only guess this was changed by some Windows Update in the past six months.

Now I’ve fixed our code to be compatible with the change.

BTW: the required syntax seems to be <file name="./comserver.dll">. It doesn’t work without the ./. Thanks to Steve White — his articles on registration-free COM are very helpful.

Comments (6)

Ah, it was DLL hell

May 3, 2006 at 8:50 am · Filed under .NET, Grid Computing

Last week I posted about some frustrating bug hunting:

In fact, I still don’t know what the problem is, but I’m moving on for now (confident that this problem will resurface somewhere else).

I was faced with the problem almost immediately because the feature wasn’t working on Server 2003 either. So, back into it I went.

This morning I figured out the original problem: that special form of DLL hell created by waxy-build up of shifting COM registry data.

Great news! Well, no, not really. Turns out it wasn’t the same problem. So I’m still dealing with a frustrating registration-free COM activation issue on Server 2003. This code used to work. So, I don’t know if we broke something or if a recent Windows Update did. Time to do some spelunking.

Comments (1)

Google and the honeymoon

May 2, 2006 at 11:05 am · Filed under Web 2.0

A lot has been said about Google complaining to the government about IE7 (from NYT).

Don Dodge says that Google’s honeymoon is over. Perhaps this is true. Their complaining about the way search is handled in IE7 does seem disingenuous.

In the past I’ve said that Google’s goodwill will wane. From Dave Winer’s Geek Dinner for Scoble with relevant excerpt here:

Google has enjoyed a great deal of popularity as an answer to Microsoft’s dominance. They have a stockpile of goodwill and trust from people simply because they are not Microsoft. This is not permanent. The bigger they get, the more profitable they are (if that’s possible), the more people they piss off with their own kind of over-reaching, the more this is going to wane.

Google has some great products, of which search is #1. But, please Google, don’t try to lock in your users by complaining. Do it by making your products better.

Tags: Attention, Google, IE7, Microsoft

Comments (1)

VS2005 PowerShell Prompt

May 2, 2006 at 8:29 am · Filed under .NET

If you are like me, you use the Visual Studio Command Prompt frequently, because you need the environment that gets set up by the vcvarsall batch. I’m using the PowerShell now exclusively, but still need this environment. Just calling the batch file doesn’t get the variables set in PowerShell. Adam Barr has a good explanation and solution here (and the interesting bit below is taken from his blog and credited there to Bruce Payette).

My goal was to have these environment variables set for every instance of PowerShell. Not rocket-science, but not terribly straight forward to a newbie PowerShell user either. To do that, I needed to add a script that will get run on every invocation of PowerShell. Here is what I did.

If you don’t yet have a profile set up, then create the required directory (explanation of profile naming is here):

mkdir "$home/My Documents/WindowsPowerShell"

Open your profile (or create if it doesn’t exist):

notepad "$home/My Documents/WindowsPowerShell/Microsoft.PowerShell_profile.ps1"

Paste the following into your profile:

pushd 'C:\\Program Files\\Microsoft Visual Studio 8\\vc'
cmd /c “vcvarsall.bat&set” |
foreach {
  if ($_ -match “=”) {
    $v = $_.split(“=”); set-item -force -path "ENV:\\$($v[0])"  -value "$($v[1])"
  }
}
popd

And then start a new PowerShell. Now the environment should be set properly.

Update: I fixed the path to the default profile.  Thanks to dreamlusion for pointing out that my info was pre-release and out of date.

Tags: .NET, Monad, PowerShell, vs2005

Comments (5)

SQL Server 2005 FrontRunner

April 28, 2006 at 7:00 am · Filed under .NET, Grid Computing

The Digipede Network is now certified as a SQL Server 2005 FrontRunner. Among other things, this means that we have passed the SQL Server 2005 component of the Platform Test for ISVs.

Thanks for the quick turnaround, Veritest and thanks to Microsoft for inviting us into the program.

Tags: .NET, Digipede, sql2005

Comments

Playing with PowerShell

April 27, 2006 at 9:21 am · Filed under .NET, Grid Computing

I finally jumped into making my own PowerShell (nee Monad) CmdLets. I took the name change and, more importantly, promotion to release-candidate status, as the impetus to try it out. A rich command-line interface to the Digipede Network is on our future-list and I’m doing some prototyping now — it seemed as good a time as any.

I won’t go into what the PowerShell is, much has been written about it. I do want to commend the PowerShell team, though. I wrote a CmdLet and found how very easy and powerful their model is.

I started by writing a CmdLet to present simple job status. Turns out, the meat of the code is just this:

protected override void ProcessRecord() {
    foreach (int jobId in mJobIds) {
        WriteObject(mClient.GetJobStatus(jobId), true);
    }
}

This code goes through all of the Job IDs passed on the command-line (or from the pipe), gets JobStatusSummary objects representing their state, and writes each one to the receiving pipe. Those of you familiar with our API will recognize the DigipedeClient.GetJobStatus() method. ProcessRecord() and WriteObject() are parts of the PowerShell API.

OK, granted, there are a bunch of lines of code required to wrap around all of this, but not too many. It all took a couple of hours start to finish (including reading and grokking). The result looks like this:

PS C:\> get-job-status -credential $me -host localhost -jobid 1

IsReadOnly            : False
Collection            :
JobId                 : 1
TimeCreated           : 4/26/2006 1:10:32 PM
TimeModified          : 1/1/0001 12:00:00 AM
StatusChangeTime      : 1/1/0001 12:00:00 AM
Status                : Waiting
LastTaskTimeFetched   : 1/1/0001 12:00:00 AM
LastTaskTimeCompleted : 1/1/0001 12:00:00 AM
TaskTotal             : 100
TaskTotalAssigned     : 0
TaskTotalCompleted    : 0
TaskTotalFailed       : 0
TaskTotalActive       : 0
TaskTotalWaiting      : 100
TimeStarted           : 1/1/0001 12:00:00 AM
TimeEnded             : 1/1/0001 12:00:00 AM
EstimatedTimeEnd      : 1/1/0001 12:00:00 AM
IsFinished            : False
TaskStatusSummaries   : {}
FailureReason         : None
FailureMessage        :

Again, if you are familiar with the Digipede API, you’ll recognize this as a JobStatusSummary. I wrote zero lines of code to do this, because PowerShell uses .NET Reflection to interrogate the object directly. Of course, this can all be reformatted with built-in PowerShell commands. This is excellent — we can layer CmdLets on top of our existing APIs without having to write a bunch of formatting code.

Now I know how easy this is, the next step is to step back and look at the bigger design.

Thanks to the PowerShell team for such a cool product.

Tags: .NET, Digipede, Monad, PowerShell

Comments (1)

Bradbury on IE

April 26, 2006 at 10:41 am · Filed under Miscellaneous

Nick Bradbury has an excellent post on how Dvorak is wrong about Internet Explorer (perhaps Dvorak is reading Kevin Burton’s blog).

I agree with Mr. Bradbury on the value that Microsoft brings to developers by making IE easily embeddable into applications. Having this capability built into the OS makes it all the easier for the distribution of new products without the weight of an IE install.

So, yes, I too am glad that Windows has a browser. I do wish it were better and easier to extend; but, I think IE7 will help us there too.

Tags: Dvorak, IE, IE7, Windows

Comments (2)

When is software development frustrating?

April 26, 2006 at 6:48 am · Filed under Miscellaneous

Last week I got into a morass on some prototyping I’m doing. I had made some changes to several different modules. I ran the standard tests: all good. I decided to run a slightly more obscure test (one that requires special orchestration). Failed. I wasted much time tracking this down. Turns out (of course) that the original code also didn’t work on my machine. Works every where else. In fact, I still don’t know what the problem is, but I’m moving on for now (confident that this problem will resurface somewhere else).

On Friday, my wife and I were talking about the week and I said that it was kind of frustrating. I gave her a little detail on the issue. Her response was:

That seems really common in your job (i.e., frustrating and non-productive time developing software).

That gave me pause. Is this common in my job or common in software development? Is it even common in my job?
Perhaps I have a tendency to talk about the frustrating without talking about the rest (the part that is creative and fulfills a need for artistic expression).

But, it got me thinking. What are the sources of frustration developing software?

Poor Tools / Development tools don’t work

This is generally not a problem; though I have a tendency to use addins from beta or early-access programs. Certainly while tools have been upgraded to work with VS2005, I’ve had a fair amount of uninstall / re-install / disable of addins. I wouldn’t bother, but some addins you just can’t live without (like TestDriven and ReSharper).

Of course the solution is to keep your dev machine fairly clean. Good idea, but hard to do in practice.

Too many manual steps

This is not uncommon when building something for debugging or testing on a remote machine. If between build and debug you have to switch to some other application, manually select files or folders, copy (ftp, . . .) files, restart something, run a test, wait for results, . . . then you have a source of real frustration and, worse, the chance of introducing error.

I try to root out manual processes as soon as possible.

Maintaining someone else’s poorly documented code or code with poor/nonstandard style

Not generally a problem at Digipede, but certainly can be frustrating.