Further to this, if I just go into DDRActionsMenu.ascx and comment out the offending lines to 'just make it work', then I get more of the same..

Unknown server tag 'dnn:Profile'.        in \admin\Users\ViewProfile.ascx
The file '/DesktopModules/CoreMessaging/Subscriptions.ascx' does not exist.        in \DesktopModules\Admin\Security\EditUser.ascx
Unknown server tag 'dnn:UserSubscriptions'.        in \DesktopModules\Admin\Security\EditUser.ascx

And I assume it might go on... am I doing something wrong, this kind of workflow used to work - I have a DNN 6.x site working just like this.

I have also tried upgrading the project from .NET 4.7.2 to 4.8.

If I run without building, the installation wizard is shown as expected. But obviously there are going to be compile errors when I go to start developing..

Gary, if you are needing to compile DNN Platform, please follow the instructions found here:

https://github.com/dnnsof...lop/.github/BUILD.md

Also, Gary, if you were under the impression that you needed to use Visual Studio for just getting things up and running, that's not necessary either.  You'll only need to use Visual Studio if you're wanting to write code for new features and/or bug fixes and contribute back to the community.  

• Getting your computer ready to install DNN
• How to manually install DNN on your computer

Otherwise, you don't need the DNN source at all to develop your own DNN extensions.  There are a number of video resources to help you get started building your own extensions, as well as a great documentation article.  

Great points Will!

Hi All, I have worked it out now.. so what I was trying to do is what I have done for the last 15 odd years using DNN and that is to open my web folder and debug with visual studio and develop my modules in the DesktopModules and App_Code folders..

The problem I discovered, was that simply unzipping the install package doesn't give you a fully compilable website, but one that will only work enough to run the install page. The install process unpacks a number of zips and at the end of the day 'then' you have the fully compilable website that I am used to.

So I would humbly say, it is not a great out of the box experience and I wasted a couple of hours.. it would be better if those things that cause the compile errors 'before install is run' were also part of the 'install unzip payload'. Or they were just unzipped to begin with. Then you would have a fully compilable website at all times.

Anyway, yes I admit that, had I followed the install instructions to the letter, no I would not have run into this issue. But I think it should be noted in the install docs that the website "will not 'fully' compile directly out of the instll zip", and if you want to run it through visual studio (as I would do for anything else) that you need to disable 'build entire website' and just let the installer run, otherwise you will get compile errors.

Gary, glad to hear you got it working. This is a highly unconventional approach though. For custom module development, you shouldn't need to debug core DNN code. Most of us set up a normal DNN instance using nvQuickSite (see https://nvquicksite.com if you aren't familiar with this tool) and then develop our custom extensions either inline (within the DNN instance folder structure) or externally (outside the DNN instance folder structure). If building external to DNN, the build process can be used to deploy the necessary files to your DNN instance and/or package the extension for conventional extension installation within DNN. As long as you are deploying your PDB file(s) along with the DLLs, you should be able to attach Visual Studio to the w3wp.exe process and debug your custom code, regardless of where your project source files reside.

I agree that many things could be easier, and we're always welcoming those suggestions.  It sounds like you've used DNN in the past, and it was 1,000% more difficult for a new person to get started in the past.  What I think you're running into is more a conflict of expectation.  The installation package isn't necessarily meant for developers or admins, exclusively. 

To ensure that adminsitrator-type community members are able to get started, it's absolutely necessary to present things this way.  It also keeps developers from the very dangerous and tempting act of change the DNN source code.  This effectively removes the ability to upgrade in many cases, over-complicates the upgrade process in the future, potentially breaks features unknowingly, and makes it very easy to run into bugs that no one else here will experience.  

To say all of that in a more concise way...  Doing things this way ensures a better overall DNN experience. Many of the things I noted above are the reasons some people end up thinking DNN sucks in some way.  Often, it was self-induced. 

Software needs to protect people from themselves sometimes.  I'm saying this means you, but it does mean the overall general developer community.  I hope this helps to at least add context to some reasons why DNN is architected the way it is.  Not to mention, that we've inherited a lot of historical issues/challenges that we need to live with, set by people in the very beginning.  

I wouldn't do it any other way.. I edit any of my modules (I have 32 in my saas) code files in visual studio, hit run, set breakpoints, etc.. no need to manually attach to w3wp, it's all already directly integrated within visual studio.

Creating a separate project for each module (ie. x32), compiling, then attaching the debugger to the running instance, is just way too many steps. And I don't need that kind of isolation in the first place.

Gary, thanks for posting your issue and glad it’s worked out now. As for having a bad experience, I have to disagree though.

Simply unzipping the install .zip file does not result in a working site, and is akin to mounting an .iso of sql server, extracting the contents, and then expecting to have a working sql instance. There is a defined setup process which you didn’t follow. Did you test the website itself before you attempted to compile? If not, you should have stopped there before blaming it on the product.

I’ve been working with DNN since v1, and the setup/install process (and I use the “standard” install and upgrades—not even the nvquicksite approach recommended by Dave) and they are light years better with each iteration. And I will remind you—and everyone else—that this IS A FREE PRODUCT. And you have the community here for support, which you received—again, FOR FREE. So to imply that this was a poor experience is irresponsible and inaccurate.