tech addict

warning MSB3247: Found conflicts between different versions of the same dependent assembly.

Seriously how is that helpful? Guess what the solution is according to VS2k8:

Double-click the warning and then select "Yes" when you get the prompt, "Do you want to fix these conflicts by adding binding redirect records in the app.config file?"

That has to be the most pointless suggestion ever. This warning doesn't go away, nor is there any indication in the message as to the culprit. The XML it generates points at some candidates tho.

Now on to see why the same solution builds in VS2k8, but fails when using msbuild on the command line.

Solution file warning MSB4051: Project {ED0038FA-D90E-4C84-AE64- 245BC76D2406} is referencing a project with GUID {BF209BE8-334A-45E8-940E-CFEF0 DEE21EE}, but a project with this GUID was not found in the .SLN file.

Apparently that means I'm missing an EndProject line. Wonder why that couldn't have been fixed or brought to my attention by studio...? It can also mean that there is indeed an invalid project guid reference in one of the subproject's csproj files. Double check the project list in the solution versus the {guid} references. One of my issues was due to that. I'm guessing studio looks up the project by name if it fails to find it by guid.

It's my first foray into screen casting, hopefully people find it useful. I cover setting up a subversion repository, accessing the repository, putting things into the repository and some other items. I tried pushing this to Google video, but it consistently mangled the text. I'll give it a shot again once I have some time. Any feedback or requests are welcome.

For those of you with ipods, here's an ipod friendly version.

I'm reading through my Vim Tips feed, and what do I discover but someone using ftype and assoc to manage windows file associations from the command line. File association registry hacks begone! Soon we'll have monad, which should open up a very rich windows command line world. (Somehow that just seems wrong...)

This week has been rather hectic, we're finalizing a software release at work and its crunch time. While working on our installer I realized that the scheduled tasks we wanted to add did not have passwords associated. Without passwords the tasks will not run, which is a very bad thing for us. Apparently there is a command line scheduled task manager (XP/2k3 only). While I apparently could have chosen to hex edit the XP binary to run on 2000, I'm glad that I didn't. I don't think that redistributing modified copies of OS files is necessarily a good idea when dealing with production software. Instead I chose to seek out a programmatic solution. I started out looking for an scheduled tasks automation object to be used from vbscript, which as it turns out does not exist across 2000+. I did find a COM wrapper library for use with .net projects (music to my ears), which worked wonderfully. I now have a simple command line tool to register and delete scheduled tasks, which I can call from my installer.

While I was searching for programmatic solutions to my problem, I ran across the WMI task scheduler interface which does allow you to create and delete tasks. Though the interface does not seem to provide a means for running the task as a user other than LocalSystem or NetworkHost, which invalidated it as a possible solution for my problem.

In addition to all of that I have learned the true meaning behind the phrase Begging the question.