Wes,

That is something to be aware of particularly when compiling extension code against the DotNetNuke.dll and other core assemblies that may have their revision number (4th group of a version #) incremented when the DotNetNuke_Community solution is re-built.

Until recently my preference had been to develop modules (WAP/compiled) in the DesktopModules/<MyModule> folder of a source install of DotNetNuke where the DotNetNuke.dll had been compiled just once during the initial install of the source package. Having the referenced DotNetNuke.dll revision version number one higher than that of the release version of DotNetNuke did not seem to pose an issue when installing the modules into a website of that same  version or higher.
 
I am now developing my modules outside of the folders of a DotNetNuke installation and set up the project to reference copies of the core assemblies for the minimum DotNetNuke version I'm developing against. These are placed in a folder in the module project. An MS Build task copies the necessary components of the module into a test installation (actually a source install but that's my own preference) of DotNetNuke and also creates the module packages when compiled in a release configuration. With that approach you are guaranteed to be compiling the module against the actual release version of each DotNetNuke assembly.

---

Bill, WESNet Designs
Team Lead - DotNetNuke Gallery Module Project (Not Actively Being Developed)
Extensions Forge Projects . . .
Current: UserExport, ContentDeJour, ePrayer, DNN NewsTicker, By Invitation
Coming Soon: FRBO-For Rent By Owner