New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Auto spin up local Dnn instance, with module on page, and debugger attached - to streamline local debugging! #14

Closed
dazinator opened this Issue Jun 13, 2015 · 2 comments

Comments

Projects
None yet
1 participant
@dazinator
Owner

dazinator commented Jun 13, 2015

At the moment, there is a small bit of additional effort that a developer must go through in order to have a working dev environment. There is also a small bit of effort that a developer must go through before they can test / debug each module for the first time.

Per Dev Environment:

  • The developer has to install a DNN website locally first.

Per Module being developed:

  • Must configure a page on the DotNetNuke website to display their module. This is the page you would browse too and typically "refresh" when testing module changes.
  • Must attach VS to the websites process each time you want to debug the module.

How this feature will work

When a developer is ready to run / debug a module they will run a command in the package manager console window:

Run-Module -Config "Debug" -Website "MyWebsite" -DnnVersion "7.4.1" -PageName "TestPage"

This command is fairly lengthy, so the developer would probably just hit "up" on the keyboard and then "enter" to re-rerun it within the package manager console whenever required.

The result would be, they would be presented with a browser window displaying their module on a page, and with the VS debugger attached. This would be the equivalent in a Website project to clicking the "play" button in vs.

To explain this command:

  1. First it will Build your module according to the build configuration specified by the -Config argument - in this case Debug mode - this will produce the installation zips.
  2. It will then check to see if a website exists on your local IIS, with the name provided by the -Website argument - in this case MyWebsite.
    • If the website does exist:
      -. It will compare the DotNetNuke version of that website to the to the -DnnVersion argument - in this case 7.4.1 to make sure it matches. If it doesn't match - an exception will be raised explaining the problem - i.e it's the wrong version of DotNetNuke.
    • If the website doesn't exist:
      -. The install package for the specified version of DotNetNuke will be automatically downloaded and the website created automatically. This saves the developer having to set up a local DNN website manually.
  3. It will then Install the module's zip/s into the DotNetNuke website using the standard DNN extension install procedure. If there is a problem with the module's installation package then this step will fail with an appropriate exception message at this point. Typical issues might be for example that the developer hasn't given their module / extension a name or title in the manifest file.
  4. It will then check to make sure that a page is created in the DotNetNuke website with a name matching the -PageName argument - in this case TestPage.
    • If it doesn't exist, it will be created.
  5. It will then check to make sure that the module in question has been placed on the page (page configuration)
    • If it hasn't, the page configuration will be amended to display the module.
  6. It will then:
    • Launch the specified page in a separate process in the default browser.
    • Attach Visual Studio to the process ready to debug.

Speed

First time - vanilla environment.

The first time this command is run on a vanilla environment it will be slower due to having to perform those one time costs that a developer would previously of had to do manually:

  1. Download and Install a DNN website
  2. Configure a test page, add the module to it.

Subsequent runs

Subsequent times this command is run though, it should be speedier:

  1. It sees the website allready exists (quick) and that it's the correct DNN version (sql operation is quick)
  2. Sees that a test page exists and has the module on (should be pretty speedy operations due to indexes on the tables queried)

Every run

Things that occur every time the command is run, and may vary considerably in time:

  1. It will install the module into the Dnn website. The time this takes will vary depending on the size of the module and the specs of the developers machine.
  2. It will launch a browser to display the test page. Dnn website may take varying amounts of time to spin up and display the page, guessing specs of developers machine makes a big difference.
  3. It will Attach VS debugger to the w3w process. The time this takes may vary based upon the developers debugging settings, especially around symbol resolution / symbol servers etc.

@dazinator dazinator added the idea label Jun 13, 2015

@dazinator

This comment has been minimized.

Show comment
Hide comment
@dazinator

dazinator Jun 13, 2015

Owner

A problem with downloading the installation zip for the DotNetNuke website on the fly, is that the download URL's may change over time. Ideally i'd like something that I am in control of so that the downloads are in a known location. This means I need to host the Dnn Installation packages somewhere that the DnnPackager can download them from. The easiest location I can think of is to put them in a public GitHub repo as that then is essentially free hosting, and I can retain ownership of that repository.

The download process then could either use LibGit2Sharp or the GitHub API to obtain the appropriate installation zip blob as necessary.

Owner

dazinator commented Jun 13, 2015

A problem with downloading the installation zip for the DotNetNuke website on the fly, is that the download URL's may change over time. Ideally i'd like something that I am in control of so that the downloads are in a known location. This means I need to host the Dnn Installation packages somewhere that the DnnPackager can download them from. The easiest location I can think of is to put them in a public GitHub repo as that then is essentially free hosting, and I can retain ownership of that repository.

The download process then could either use LibGit2Sharp or the GitHub API to obtain the appropriate installation zip blob as necessary.

@dazinator dazinator changed the title from Auto spin up local Dnn instance, with module on page, to streamline local debugging! to Auto spin up local Dnn instance, with module on page, and debugger attached - to streamline local debugging! Jun 13, 2015

@dazinator

This comment has been minimized.

Show comment
Hide comment
@dazinator

dazinator Jul 30, 2015

Owner

Let's go full out. Let's create a full on VS project system / flavour so that i can take full control over the VS run / deploy commands. That way it gets rid of the powershell command and the developer can just run the project as normal and let the magic unfold

Owner

dazinator commented Jul 30, 2015

Let's go full out. Let's create a full on VS project system / flavour so that i can take full control over the VS run / deploy commands. That way it gets rid of the powershell command and the developer can just run the project as normal and let the magic unfold

@dazinator dazinator closed this Jul 30, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment