hello,

its hard to say exactly what you need but based on your description is sounds like the developer used the website project (WSP) mode of development (i.e. the module will have files in both app_code and their custom module folder in desktopmodules) - you can read how to use this at http://www.dotnetnuke.com/Resources/W... , but in general that approach is not ideal (it's fine for prototyping but not something id use on a production site)

In general most people use WAP style development - http://www.dotnetnuke.com/Resources/W... offers tips on how to do this, it's targetted to new development rather than maintaining existing development but it should help you get some background.

As for minimal extropy it was a skin that was the default core skin in 5.0, and was replaced with DarkKnight in 6.0 - there is no seperate download for it, but as you upgrade dotnetnuke versions if there is a known breaking change/problem that skin is upgraded also (as it was shipped as part of the core product at one time).

As to how to approach this, I'd recommend you consider taking a copy and upgrading to either the last 5.x release (5.6.7) at this time or else something on the 6.x branch (6.1.5 would be my recommendation) to check your extensions.

Regarding extensions such as modules/skins - we work hard to maintain binary compatibility so all extensions should work as you upgrade - if they do not this is typically because they are not written correctly e.g. they do direct database access, rather than use the API.

Hello,

first of all, just to make it clear - dotnetnuke itself uses codebehind files for many functions, those most of those reference classes that have been compiled into various dll's, so it's normal to have code behind files. However extensions such as modules can be written in any language and use either WSP or WAP (or even razor) so it's up to the extension developer what development model they use.

As to testing locally, the typical way to do this is to log in as host and add a portal alias for your development url (e.g. localhost) - see http://www.dotnetnuke.com/Resources/W... for more info on what portal aliases are in dotnetnuke terms. You can then take a copy of the site (files and folders, as well as backup of the database), copy it to your development machine, restore the database, and update the 2 connectionstrings to point to your local database location. Now you'll be able to browse to the site as localhost safely - if you back up the site (files and database) at this point you can do some test upgrades without risking the production site and do some testing. You'll also be able to create a WAP project and migrate the existing code into it, compile and deploy it to the site (and delete the old code-behind files) and see if that works.

Yes, everything in extensions is an add-on - there is a column to indicate if it's in use or not (older versions of dotnetnuke shipped with a lot of modules that were available but not installed). There is no real way to see if something came with dotnetnuke or was installed later -in general though 3rd party extensions have the company name in them.