When working with solutions in a project often times I come across a few exports that I made previously. The probably I have is most people never update the version numbers on a solution. You end up with two or more solutions not really knowing what is in one versus another. Granted not knowing exactly what is in one solution versus another is still a problem, but the issue can at least be minimized.

What I have started doing is setting the solution version numbers based on date timestamps. So for example after working on a WIP (work in progress) solution on my VM I'll set the solution version as a reversed date with the army time such as 2012.01.01.1500. Part of the reason I use this format instead of sequential solutoin versioning is that as far as I can tell there isn't an easy when to know when a solution as last updated. The date next to a solution in an organization shows the first import of the solution. If you make another import that date doesn't change.

Using reverse date versioning not only do you know when the last time the solution was imported, but when you export the solution the file name will automatically be in a format that sorts in windows explorer. I've seen that there are a couple solutions out on codeplex for automatical versioning of solutions. I haven't tried those out for myself yet. I do know that it is kind of a pain to always have to manually update the solution version manually though.

In a perfect world there would be a much tighter integration between CRM solutions and TFS so that the seperate components could be tracked and only those things a developer changes are locked/updated in the master tenant solution. This process could also handle the updating of component versions and also solutions as well. I'm sure we'll see some very interesting solutions to these problems as time goes by.

Stephan Smith
Senior Microsoft Dynamics CRM Technical Architect