DNN Forums

Ask questions about your website to get help learning DNN and help resolve issues.

Compile error on fresh install 9.13.3

Topic is locked
Page 1 of 212 > >>

New Around Here

    I unzipped from DNN_Platform_9.13.3_Install.zip
    Created a new VS2022 solution.
    Added an existing web site project.
    When I run/build I get the following related errors.

    The file '/DesktopModules/DDRMenu/Actions.ascx' does not exist.
    Unknown server tag 'dnn:ACTIONS'.

    The error is generated from file \admin\Menus\DNNActions\DDRActionsMenu.ascx

    The install zip file doesn't include the folder /DesktopModules/DDRMenu at all.

    New Around Here

      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..

      Veteran Member

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


        David Poindexter


        Senior Member

          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.  

          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.  

          Veteran Member

            Great points Will!

            David Poindexter


            New Around Here

              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.

              Veteran Member

                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.

                David Poindexter


                Senior Member

                  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.  

                  New Around Here

                    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.

                    Growing Member

                      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.
                      Topic is locked
                      Page 1 of 212 > >>

                      These Forums are dedicated to the discussion of DNN Platform.

                      For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

                      1. If you have (suspected) security issues, please DO NOT post them in the forums but instead follow the official DNN security policy
                      2. No Advertising. This includes the promotion of commercial and non-commercial products or services which are not directly related to DNN.
                      3. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
                      4. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
                      5. No Flaming or Trolling.
                      6. No Profanity, Racism, or Prejudice.
                      7. Site Moderators have the final word on approving / removing a thread or post or comment.
                      8. English language posting only, please.

                      Would you like to help us?

                      Awesome! Simply post in the forums using the link below and we'll get you started.

                      Get Involved