Thanks for your reply Sebastian.
I have made the following adjustments using the Install version we have on QA, the result is that we now have a correct Source install on DEV, and the good news is we're able to continue. That said, the issue is of big importance I think, so the DNN team should do a fresh install of the Source package and resolve the issues encountered. I mean, you cannot name a release 8.0.3 and omit some basic controls and worse have older versions in it? Clearly this has not been tested.
The steps I followed for a workaround - for anybody that is interested - to move QA DNN folder contents over to local folder Website in DEV... and gain consistence in module versions and code, were:
- back up local DNN DB
- back up local Website folder (...\CCMSDNN\Website)
- back up DNN DB on QA
- delete local DNN DB
- copy backed up DB to local DEV and restore
- delete dnnlogin user (if drop fails because it owns a database role, first set dbo as their new owner, then delete should work)
- assign local dnnlogin to restored DNN DB
- create zipped backup of DNN folder on QA (Install package means opy ALL from root)
- copy to local DEV, unblock, and unzip in temp folder
- overwrite local Website folder (do not delete anything, only rename the web.config to something unique)
- in SQL, adjust PortalAlias field HTTPAlias from msrvdev01.cloudapp.net/ccmsdnn to localhost/ccmsdnn
- one more step, we'll need to adjust the conn string to access local DNN DB... OK
- navigate to http://localhost/ccmsdnn
- the modules now have all version 8.0.1 or higher... good!
- the DEV project files are still there in Website folder so VS 2015 solution should load without problems... OK
- a rebuild all also works without errors... (all still Release)
- now change to Debug (both in Toolbar of VS, and in web.config in compilation tag)... OK!
- looks like we're back in business! :)