Software Development

October 26, 2009

I was trying to debug a project we're maintaining just now and I kept getting "The breakpoint will not currently be hit. No symbols have been loaded for this document." after setting a breakpoint and running the solution. The Startup project is a Smart Device project targetting Windows Mobile 6.1 Standard and it was deploying to an emulator running the same.

After trying all of the suggestions from posts like this one including manually trying to point at the .pdb file, I then kept getting "The symbol file x does not match the module" where x was the name of the relevant .pdb file. Eventually I noticed a comment on that same post regarding deleting the actual .exe which has been deployed to the emulator and then redeploying which for some reason did the trick.

After trying what was suggested there (i.e. stsadm –o installfeature –name DiscussionsList) as well as deactiviating/activating/uninstalling/installing features, we finally noticed that the DiscusssionsList Feature.xml last modified was far too recent so we copied a version down from another working server and after reinstalling etc, creation of a site based on the Team Site template worked again, but the TFS error persisted.

Further troubleshooting ensued including, but eventually we tried the SharePoint Inspector as suggested here, which is rather useful for providing a hierarchical and visual drill down of various sharepoint objects. We then ran through all the features used by the TFS site template in question, deactivated/activated etc, but still no change. Eventually it turned out that the IssuesList Feature.xml had also had itself changed somehow, so pulling this down from a working server and doing the same as for the DiscussionsList Feature.xml finally resolved both errors.

The Scope and Hidden settings specifically had been modified, presumably by someone during some previous troubleshooting and/or development. They're built in files so this shouldn't have happened, but hope this at least saves someone else the wasted time and effort.

April 02, 2008

I thought this was a great way of describing the state of many projects you end up working on (Thanks www.igloocoder.com)....

A common term in software development is 'greenfield'. The term is commonly used to describe a project that is starting completely from scratch and thus having no existing code base. Recently I have been searching for a term that is capable of describing the opposite of greenfield. One of the terms that is often used to describe code that exists is 'legacy'. Unfortunately the term 'legacy' has connotations that lead people to think about applications that have out lived the life of the technology that they were implemented with and no longer are being actively developed. For some people this will make them think of mainframe, green screen, COBOL, FORTRAN and other technologies. Because our minds tend to sway to distant applications and technologies like this, we create a gap between greenfield and legacy where the technology is either relevant, or nearly relevant, and the application is under active development.

Applications like this are something that we regularly see in the industry. More often than not, when you're hired onto a project, either as an employee or a contractor/consultant, you will be stepping into a project that is already under development. How do you decribe that project to your mates? It's certainly not greenfield and if you mention 'legacy' people will ask you how you ended up working on mainframes. Neither do the situation justice.

The term 'brownfield' is not as commonly used in our industry. In fact, I can't find any online references to the term in relation to software development. According to Wikipedia, brownfield is used to define land and reclamation work and can be defined as:

...land previously used for industrial purposes, or certain commercial uses, and that may be contaminated by low concentrations of hazardous waste or pollution and has the potential to be reused once it is cleaned up.

If we translate that into software development it would probably read something like this:

...project or codebase that was previously created and may be infected with poor practices, structure, implementations and moral but has the potential to be revived through comprehensive and directed refactoring.

If that is how we define a brownfield project then we can also say that they are a more common type of project for us to end up working on.