Project Update: One year on

Around one year ago, I was working very hard on some unpleasant projects at work at what seemed like a dead-end position in terms of where I wanted to be in my career. One aspect of this was that I wanted to be hard-core developer where as my current position was more consulting-oriented for a particular vendor.

Not being in a development position for about 3 years prior, I wanted to try to get some development experience under my belt in order to help landing a job in the field I wanted to be in. Given that I was not getting this opportunity at my job, I felt contributing to an Open Source project would be personally gratifying and giving me the chance to get deep into the code of an application and prove myself.

I made it a goal of 2009 to contribute to an open source project. This was my intention.

I focused on World Wind, given my enthusiasm for NASA, space travel, and geography. It was C#.NET which was a language I hadn't used in years and seemed interesting enough.

I found the code difficult, it took a long time for me to make any contributions, at first this was because of lack of documentation, but also lack of clear process or community support. No fault of anyone on the WorldWind project but it seemed to continually lose support, members and momentum throughout my involvement in 2009. What I didn't realize when I started is that although WorldWind has the NASA name, NASA has officially moved all their support to the Java WorldWind SDK project and virtually abandoned the .NET version. Not only does this mean that their full time developers who originally wrote WW.NET no longer made any contributions, they also removed the JIRA defect tracking site for the .NET project. This makes it impossible to track our progress, or even determine the goals of what needs to be fixed. I even got frustrated with this so I created a "bug tracking" page on the World Wind wiki just so we had something tangible to work against.

So after a year spent part-time on this OpenSource effort, I have made a number of contributions, the largest being perhaps the download code refactoring. I've also contributed to the project management side by documenting issues and pushing along input and contribution from the team members still active. I regret not being able to get into developing new features rather than just bug fixing, but in the Fall of 2009 my real-world job took precedence as I was assigned a literal Death March project.

As things stand we have a stable build with a number of fixes implemented. We have been discussing making a release of this build as World Wind 1.4.1, but as of this week I am still unclear on what steps are done to build and package this release. I gather it involves updating the installer and getting NASA to do some testing to sign-off on the changes. At the very least we have been giving people guidance on how to build their own WW app from the latest source with our changes. I suppose my efforts will live on.

In 2010 I am considering embarking on a personal web-site project. This will probably take most of my time outside of work, but I am very excited about this effort as I have control over it and can make a difference. Contributing to World Wind was an good experience but I feel it is time to move in a different direction, at least for the time being.

How does Visual Studio include Referenced Libraries?

A problem was raised on the forums a number of times about World Wind building in Release mode.

If you checked out the source from SVN, and opened the project in Visual Studio, then tried to build in release mode you would receive errors such as:

C:\WINDOWS\Microsoft.NET\Framework\v2.0. 50727\Microsoft.Common.targets : warning MSB3245: Could not resolve this reference. Could not locate the assembly "Tao.OpenGl.Glu". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.

C:\WINDOWS\Microsoft.NET\Framework\v2.0. 50727\Microsoft.Common.targets : warning MSB3245: Could not resolve this reference. Could not locate the assembly "ICSharpCode.SharpZipLib". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.

C:\WINDOWS\Microsoft.NET\Framework\v2.0. 50727\Microsoft.Common.targets : warning MSB3245: Could not resolve this reference. Could not locate the assembly "Tao.OpenGl.ExtensionLoader". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.

C:\Apache2\htdocs\html\WWsrc\PluginSDK\T iledWFSPlacenameSet.cs(10,7): error CS0246: The type or namespace name 'ICSharpCode' could not be found (are you missing a using directive or an assembly reference?)

Answer given by forum member, James_in_Utah:

I think the problem is that those DLLs may not be checked in for the "Release" mode build. Try building in Debug mode. That should work. Then find the dlls mentioned, Tao.OpenGl.Glu.dll, ICSharpCode.SharpZipLib.dll in the Debug target directory and just copy them to the Release mode target directory. We really probably should check these into the release mode build target directory in SVN, but I don't have privs to do that.

I added these two .dlls to the Release folder in World Wind SVN and commited the changes.

This brought the question to my mind, this seems to be a bad practice to check in to source control the contents of the output directory. I see that the .dlls are referenced under project references. Shouldn't there be a way that on build it copies the required .dlls to the Release folder or Debug folder as necessary?.

Unfortunately no one on the forum seemed to have a response and a quick web search revealed no answers.