Since am also an avid LINQPad user I wanted the same level of easy of use and integration for MongoDb as there is with Linq To SQL. So I invested an evening and wrote a LINQPad DynamicDataContextDriver.

The purpose of the driver is to provide the glue between  three involved parties:

1. LINQPad
2. NoRM
3. and finally the Entites (or Domain Classes) defined by your Project(s)

After the driver has been installed, LINQPad’s Add Connection Dialog contains a new type of connection:

To add a new Connection, select the MongoDb Driver, click Next and you are greeted with the Driver’s Connection Configuration Dialog:

The Connection String should be pretty self explanatory but the Entity Assembly and Entity Namespaces(s) field might need some explanation. The Entity Assembly is supposed to contain the entity or domain classes of your project. Since NoRM does not define any marker interfaces, base classes or attributes for those classes I opted to identify them within the assembly by namespace which you can specify in the third field of the configuration dialog (separate multiple namespaces with semicolon).

Please refer to the Driver’s Project Page for Installation Instructions and Source Code.

There was one issue that was causing me a major headache during the setup phase and that was getting Mercurial talk to my private repository server over SSH using private key authentication from within TeamCity’s Windows Service running under the SYSTEM account (I’d rather have it run under a non-privileged user but that doesn’t seem to be supported).

The first problem was getting Mercurial to use Putty’s plink.exe while running under the system account. Normally you would just create a file named mercurial.ini in the user’s home directory containing something like this:

[ui]
ssh = "C:\Program Files\putty\plink.exe" -i "c:\your.ppk"

But where do you put this file in the case of the system account? Some Googling on that matter turned out that it should go to \System32\config\systemprofile. I’ve tried that to no avail. Mercurial would still try to invoke ssh.exe which is obviously nowhere to be found on a Windows box. I realized that the Mercurial Executable is 32-Bit which meant that the home directory of the SYSTEM account had to be located somewhere under \SysWoW64 and indeed there is a \SysWoW64\config\systemprofile directory. After moving my mercurial.ini to that directory the “Test Connection” button in TeamCity would *drumroll* … HANG!

The reason for this behavior was that plink.exe prompted the user to accept the new ssh host key – in an invisible shell window. To overcome this hurdle I shutdown the TeamCity Web Service and opened a new shell window running under the SYSTEM Account using the psExec Utility by Mark Russinovich:

psexec.exe -s cmd.exe

Now that I had a shell running under the system account I could connect to my server and accept the host key:

plink 192.168.230.1

Low and behold clicking the “Test Connection” button in TeamCity would now give me a different error:

"C:\Program Files (x86)\Mercurial\hg.exe" identify ssh://git@192.168.230.1/usr/local/hg/testproject' command failed.
stderr: abort: no suitable response from remote hg!
 
stdout: remote: abort: There is no Mercurial repository here (.hg not found)!

Fiddling around with the settings for another hour turned out that there was a problem with my SSH Url in TeamCity: ssh://git@192.168.230.1/usr/local/hg/testproject

1. The ssh URL contained the user name
2. The path needs to contain a second / at the beginning otherwise the server will see it as “usr/local/hg/testproject”
3. The user name must not be part of the SSH Url but needs be entered in Teamcity’s “User name:” field under “Authorization Settings”

After changing the SSH Url to: ssh://192.168.230.1//usr/local/hg/testproject (please note the double slash after the host), I could finally connect, pull the sources and build my project.

Please keep in mind that your private key may not be protected by a passphrase!

Unfortunately, all of that ended with the release of Visual Studio .Net 2002. This was the first release which introduced support for the .Net Framework in the IDE. Don’t get me wrong. I still regard the .Net Framework as one of Microsoft’s better products, but this post is about Visual Studio and the impact the framework plus other contributing factors had on the quality of IDE.  Visual Studio .Net 2002 took approximately two hours to install on my relatively powerful workstation. After that, when I was allowed to launch the IDE, the greatly increased startup time was immediately noticeable. But hey that’s the price you got to pay for all those shiny new features right?

During the following months it turned out that studio had not only gotten much slower but also much less stable – especially when working with .Net applications. The debugger was freezing on me so often that I became afraid of using it at all. The same applied to the Winforms GUI Builder which just did not seem to be stable enough for complex projects. At the time when the successor product Visual Studio 2003 was released, I got more and more into ASP.Net web development and this is where things got nasty.

Open source and commercial Java IDE’s like Eclipse and IntelliJ have caught up with Studio a long time ago, but unlike Visual Studio, they kept pushing forward with excellent productivity and refactoring features while Microsoft in turn introduced feature after feature which no experienced developer really cares about (new Ctrl+Tab feature in Visual Studio 2008 anyone?), consuming even more resources for eye candy and useless stuff.

The project I am currently involved in is a large scale ASP.Net based CRM Web Application consisting of a couple thousand C# source files and approximately 400 ASPX pages with associated ASCX web controls. Just opening the solution takes 2 minutes and a 3 GHz workstation. Opening the first Web Control takes another 2 minutes, changing anything inside the file incurs another 1 minute penalty. Why? I have NO idea. I suspect that there’s a ton of costly object marshalling between the managed and non-managed parts of the IDE going on under the hood, combined with a healthy amount of various workarounds and hacks to ensure compatibility with stuff that should have been abandoned a long time ago.

Sure, I could de-install Resharper and by doing that cut the waiting time in half, but let’s face it: Resharper is currently the only serious option to turn Visual Studio into something that remotely resembles a modern IDE after you’ve used one of the aforementioned Java IDEs. Unfortunately, Resharper comes with a double price tag: first it’s quite expensive for an addon (you almost get a license for IntellJ for the same money) and it makes Visual Studio even slower and more prone to crashes.

Out of desperation I recently tried out SharpDevelop – the Open Source Development Environment for .NET. It opened our solution in under ten seconds. Bummer! If I was Microsoft’s Developer Products manager I’d pay the SharpDevelop team a visit with a suitcase full of cash, lock them up in a room with unlimited resources let them take over the development. But that will probably never happen because Microsoft has lost its focus on all fronts including the developers. And realizing this has converted another Microsoft Developer into a Java and Rails Developer.