While setting up a C++ static shared library under Linux and unit testing under C++ for the first time, I found the following resources useful.  Unit testing in C++ does leave me wanting runtime reflection quite a bit, but I think CxxUnit's approach is quite workable despite the fact that the GUI runner sucks.

GNU Make user guide: http://www.gnu.org/software/make/manual/make.pdf

Static Lib Tutorial: http://www.iram.fr/~roche/code/c++/c++_AddNumbers.html

CxxTest user guide: http://cxxtest.sourceforge.net/guide.pdf

Here's a really interesting way to conduct unit tests using in memory collections with LINQ: http://iancooper.spaces.live.com/blog/cns%21844BD2811F9ABE9C%21397.entry

I'll need this in the future me thinks...

I was so used to using the Java Seralizable interface for arguments, that I kind of miss it in a way in .NET.  In fact I missed being able to easily tell if an object was serializable, but someone pointed this out to me today:

[Serializable]
public class User
{
...
}


if (typeof(new User()).IsSerializable)
   Console.WriteLine("The User type is serializable");

Found this in a comment on ScottGu's blog:

We use the web setup project to deploy our web applications. To automate additional installation tasks like setting the .NET version and encrypting the web.config files we use a custom installer along with the web setup project (see relevant code below). However we recently ran into a problem when deploying an application on a server where there are several web sites. The site we wanted to install on was not the default site. Therefore our code to set the .NET version and assign the newly created application pool did not work since "W3SVC/1/ROOT/" was not the correct path to the website. Is there a property similar to [TARGETDIR] which we can pass to our custom installer to account for this. We know hard-coding "W3SVC/1/ROOT/" was not the best option but we also knew it would be correct 90% of the time. Thanks as always for your time.

Best Regards,

Stephen

info = New ProcessStartInfo()

info.FileName = "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe"

info.Arguments = String.Format("-s W3SVC/1/ROOT/" & strVDir)

info.CreateNoWindow = True

info.UseShellExecute = False

Process.Start(info)

info = Nothing

Dim myApp As New DirectoryEntry("IIS://localhost/W3SVC/1/ROOT/" & strVDir)

myApp.Properties("AppPoolId").Item(0) = strMyAppPoolName

myApp.CommitChanges()

myApp = Nothing

# re: Using IIS with VS 2005 and the new Web Project system

Hi Stephen,

You can pass in the targetsite and targetvdir path as context parameters to your custom action by passing this:

/targetdir="[TARGETDIR]\" /targetvdir="[TARGETVDIR]" /targetsite="[TARGETSITE]"

I upgraded a web service application from .NET 1.1 and was getting the following error:

Parser error global.asax could not load type

I found this was caused because the installer for the application was creating an IIS web application set to use .NET 1.1.

Warning, this is a bit of a rant…

Today I was trying to add a new unit test project to one of our solutions through the Visual Studio VSS plugin.  Everything seemed fine until I realized I had named the project folder incorrectly.  I thought “no big deal” I’ll just rename the project folder, but of course there is no way to do this through Visual Studio, you have to remove the project, rename the folder through Explorer, then re-add the project.  But since this was already checked in I would need to go through the VSS client and rename the project folder.  That’s why I hate source control integration with Visual Studio, it doesn’t support all scenarios (especially renaming things correctly to preserve history) and it tends to add an extra layer of complexity.  In addition to renaming the folder I needed to edit the solution to point to the correct location.  The one problem was that I forgot to change the stupid source control bindings so when you went to open the solution it wouldn’t find the project.  Apparently I needed to “rebind” the project – at this point I just hand edited the sln file to rebind it to the proper location.  After that everything seemed to be OK.

Just to make sure, I decided to open up my SourceOffsite client (SourceOffsite is basically a 3^rd party client/server product to allow access to SS over TCP/IP) to verify things would look OK to the remote devs; but where’s the stuff I just checked in?  After some searching through the SOS forums I found out I needed to “Refresh Project Tree.”  That showed me the new files, but now I noticed the versions were incorrect.  I then had to get latest and overwrite local changes (even though I already had the latest) to update SOS on my client.  So now I have three possible points of contact with the source control database, and they seem to all have their own view of what’s going on.  This just scares the hell out of me, and makes integration painful.  Integration should be easy!  After all, we want everyone to integrate their changes as quickly as possible.

As per our current team rules, I then needed to send an email to everyone with a list of my changes.  Of course SS doesn’t have change lists so I have no way to know what the hell I just checked in.  We also don’t have a CC.NET server yet, so I couldn’t check there either.  Argh!

What a bunch of crap.  Something that should have taken me 10 minutes took me over an hour.  I think its time to setup an internal Subversion server to show everyone the way towards the light.

I had forgotten how much I hate dealing with web projects in Visual Studio 2003, until today.  I went to open up one of our companies VS 2003 web projects and didn't have a virtual directory configured before hand, so when it tried to open it complained it couldn't find the path to the csproj file.  OK, no big deal, open up inetmgr and create a virtual directory.  Well that was a good though, except I entered the incorrect path for the virtual directory.  Try again, change the virtual directory to the correct path and try an open the project again.  No good, I get this error now, "Unable to get the project file from the web server."  What the?

The fix: delete *.* from c:\documents and settings\sneal\VSWebCache.

I moved my little demo application (aka FoodBankTracker) that I use for demoing tech over to Visual Studio 2007 / .NET 3.5 today without much hassle.  The only real hassle I had was with log4net version/strong key mismatches between MonoRail RC2 and NHibernate 1.2 GA, but that's entirely another story.  The main reason I wanted to move it over to the new platform was to really try out the new language integrated queries (LINQ).  I ended up using the LINQ -> NHibernate criteria adapter being maintained by Ayende for several reasons:

1. My NHibernate mapping files are complete.
2. I like the unit of work NHibernate provides.
3. Its always good to have some abstraction between the domain and the database layer.
4. I'm familiar with NHibernate and already have infrastructure in place for it.

I grabbed the latest code from subversion for the LINQ -> NHibernate adapter and was up and running in no time.  The only change I had to make was to upgrade the NHibernate version from 1.2 beta3 to 1.2GA.  The hardest part was figuring out that I needed to add an assembly reference to System.Core for .NET 3.5 in my project.  Anyway, here's the one test I have working with LINQ and for comparison I'm also showing the original test without LINQ which does the same thing.

My little demo/test application that I monkey around with from time to time got a major revamp today.  Nothing fun or exciting, just a lot of infrastructure cleanup that I've been needing to do for some time.  I was hoping this would only take me an hour, but in reality it took me 3 times longer than that.  All I needed to do was:

1. Upgrade NHibernate from 1.2 beta3 to NHibernate 1.2 GA.
2. Separate out my shared core library into a separate folder/solution structure.
3. Stop using GAC'd Castle and NUnit assemblies and use a local libs folder to facilitate building on a clean box.

Nothing fancy, but I ran into some serious issues with log4net.  You would think that because most open source projects use log4net, integration of multiple open source products that use log4net would be a breeze right?  Well, Castle RC2 uses log4net 1.2.9.0 while the latest NHibernate release uses log4net 1.2.10.0.  That seems fine, just add an assembly binding redirect to have castle using the newer log4net version right?  Well that's fine until you realize that the log4net team unexplicablly changed their signed key between those releases, which means you can't use a binding redirect.  Oops, I doubt the log4net team intended that to happen.

To get around this version mismatch I ended having to grab the latest code from the Castle subversion repository which included log4net 1.2.10.0 and build my own assemblies that would play nicely with  NHibernate.

The moral of this story is don't change your keys between versions if they're binary compatiable/incremental updates.  Especially for something so commonly shared as log4net.

Anyone who's programmed in VB for a while will find this article interesting: http://www.codinghorror.com/blog/archives/000860.html

I didn't realize (or maybe truly understand) VB.NET had a background compiler in Visual Studio 2005 like Eclipse does for Java.  When I was programming in Java/Eclipse the background compiler literally saved me 20 minutes or more a day, its hard to believe C# doesn't have this even in Visual Studio "Orcas". 

The one thing I really from miss from VB is the with statement.  The with statement is very fluent and readable. In C# we could have something like the using statement:

Person user = new Person();
with (user)
{
   .FirstName = "John",
   .LastName = "Doe",
   .Age = 18,
   .PhoneNumber = 5555555,
}

The one thing we will have in .NET 3.5 is property initializers which are pretty close to the with statement, but the one difference is that the with statement would work anywhere.  Property initializers only work on construction of the object and really only save you from having to declare a bunch of overridden constructors.  Property initializers look like this:

Person user = new Person()
{
   FirstName = "John",
   LastName = "Doe",
   Age = 18,
   PhoneNumber = 5555555
}

Now what happens if I need to reuse an instance and assign different values?  Well, hopefully you won't need to, and in likely hood its very unlikely you would.  When I was programming in VB I generally only used the with statement to initialize an object.  What do you think?