mtrutledge / generator-dnn Goto Github PK

I'll submit a PR shortly

Currently, there are hard-coded strings in the ReactJS. It would be good to show how to access the App_resources from the ReactJS code.

There is an issue with the module name contains a dash or dashes. The current workaround is to not use dashes in the module name.

During the Southern Fried DNN call on 7/19/2018 a suggestion was made to have VueJS as a option for the SPA modules. I think this is a great idea!

After creating a MVC Module with the generator everything works as expected. When I install the module and goto the settings page it crashes with a DNN Error:

I will submit a PR shortly

Currently, the MSBuild task runs a ModulePackages.target build script. Ideally, I would like a gulp/grunt task to create the module package installer. I have some test code, however, it is currently not producing a clean enough zip file.

We have an MVC Module Yeoman task working. We need to implement the Persona Bar task.

Currently after the generator creates the templates and files it runs npm install. Should we change this over to yarn?

This would give us the ability to restructure some of the module directories and use yarn workspaces so we would not have to duplicate the node_modules if the sub-projects used the same modules.

Thoughts?

Instead of providing a way for people to develop inside of a DNN instance, I highly recommend documenting the use of symbolic links via Microsoft's built-in Windows 10 command mklink. Once the module is "installed" the first time, from there, you could just develop where you want and use MKLINK to map files to the appropriate directories.

Please summarize your question in one sentence

For optimum discoverability, you'll need to update the repo's Description to include DNN and DotNetNuke keywords at minimum.

Give a more extended description

A common practice is to use DNN (formerly DotNetNuke) within the Description and README.

Describe the bug

Newly created projects show intellisense errors in views due to missing DotNetNuke.Web.Client reference and missing model declaration

To Reproduce

Steps to reproduce the behavior:

1. Create new module using yo dnn
2. Open project and browse to Views, Home. Index.html
3. You will see red intellisense squiglies under a number of areas including the using statements, ViewBag, and @dnn

Expected behavior

A new project should not show intellisense warnings

Screenshots

Errors

See Screnshot

Additional context

This can be resolved by adding DotNetNuke.Web.Client to the initial package list to be loaded as references and adding a blank Model declaration such as @inherits DotNetNuke.Web.Mvc.Framework.DnnWebViewPage as the DNNHelpers like @dnn. and @url. load from DotNetNuke.Web.Mvc.Framework.DnnWebViewPage

*Note: The blank model declaration of type string may cause other issues if you try to render a named view from the controller as it see's the view name as the model, so this may not be the most bulletproof resolution.

Currently, the development process assumes development outside of the DesktopModules folder and a local DNN instance. There are enough developers out there that develop within a local DNN instance that the scaffolder needs to take this into account.

Hello Matt,
Thank you for creating this for the DNN community.

I followed the instructions for this generator and also watched your video explaining how to use the generator with SouthernFriedDNN.
However I dont see the install zip being created anywhere for the SPA module. I was unsure how to debug or figure out why this was happening.
I also tried using UpendoDNN generator for the SPA module but it didnt generator and install zip either.

I am an old DNN developer (from snowcovered.com days) who is trying to get back into DNN development.
I wanted to build SPA modules with react and use WPI (Library) module for Data access etc.
But I am stuck at even getting a sample SPA + React going.

Thank once again for you community offerings.

When creating a new MVC project the generated .csproj file is missing the following files:

• License.md
• packages.config

I took a look at the template for SPA projects and they are included and as they should because it is easy to edit these files while inside Visual Studio.

When creating a new project I have to add these manually using the following syntax:

<Content Include="package.json" />
<Content Include="License.md" />

I would recommend grouping them with the packages.config and web.config's ItemGroup. Here is the entire ItemGroup for reference

<ItemGroup>
  <Content Include="package.json" />
  <Content Include="License.md" />
  <None Include="packages.config" />
  <Content Include="web.config" />
  <None Include="web.Debug.config">
    <DependentUpon>web.config</DependentUpon>
  </None>
  <None Include="web.Release.config">
    <DependentUpon>web.config</DependentUpon>
  </None>
</ItemGroup>

Currently the reactjs spa template is calling out to Webpack to build the ecma script. There should be a way to do this with gulp and Babel so we can reduce the amount of dependencies we are downloading.

While working on some PRs I noticed there is no dev guide or how to contribute guide. It would be very useful if we had a document on how to build the generator locally and run it. That way people can easily test their changes

Opening the sln in visual studio on Mac or windows does not fully build the projects because that task is up to yarn build. Probably need to remove the sln file or figure out how to alter the scripts so msbuild triggers front end compiles.

We have an MVC Module Yeoman task working. We need to implement the Skin task.

Please summarize your question in one sentence

What is the purpose of this module/project?

Give a more extended description

The purpose of this is not clear. What do you mean by scaffolding? What can this "module" accomplish, what problem(s) does it address.

Steps to reproduce (if needed)

Other comments or remarks

It looks like it might be interesting, but the information does not provide any clue as to what it is.

http://www.dnnsoftware.com/community-blog/cid/155430/future-proofing-running-dotnet-core-on-dnn--it-works

There is an issue when the module directory name contains a dash or dashes.

The workaround is to remove all dashes from the module directory name. It doesn't seem to matter if the parent directory for the module contains a dash or dashes.

I'll submit a PR shortly for this

We currently produce the ReleaseNotes.txt file from a ReleaseNotes.md file in the project. We should mirror this with the License.txt file.

I don't see any link to the GitHub Pages/Docs website. I see there is a branch to it but no link on the README.md. It should be somewhere on the readme so it is easy to find

Is your feature request related to a problem?

This will prompt the user to let them know they can update their generator

Describe the solution you'd like

Yeoman implements an update-notifier that will show the user a message if there is a new version. More details can be found here: https://github.com/yeoman/update-notifier

When generating a MVC project the Settings.resx file is not being generated correctly the file is malformed and won't open in Visual Studio:

After further investigation it appears that the following fields contain <%= moduleName %> which appears to be correct generator syntax as a placeholder

• BasicSettings.Text
• ControlTitle_settings.Text

My assumption is the xml is not being properly parsed in this case. I took a look at the SPA configuration and it doesn't have these fields so we could just rip it out.

@mtrutledge what direction would you like to go with this?

Since everyone is in a effort to move away from Webforms, for obvious reasons, this generator should not support that option at all.

After finishing the yeoman implementation create the same templates that can be installed with the dotnet cli.

Please summarize your question in one sentence

For optimum discoverability, you'll need to add topics for dnn, dnncms, dotnetnuke at minimum.

Give a more extended description

GitHub Topics are added to repos by clicking Manage Topics just below the repo Description.

Describe the bug

When you run npm run build and the gulp task triggers msbuild the resulting PDB files generated do not allow an instance of Visual Studio to attach the debugger properly.

To Reproduce

Steps to reproduce the behavior:

1. Create a project
2. run npm run build
3. Deploy the project to a local DNN instance
4. copy the PDB files over to the DNN instance bin directory
5. Launch Visual Studio and open the project
6. Set a breakpoint and attach the debugger to the w3p.exe process running the DNN instance
7. Load the module and see the breakpoint will never be hit.

Expected behavior

The PDB generated from the command line should allow Visual Studio to attach the debugger and hit the breakpoint properly

Upgrade from Gulp v 3 to v4
There are several breaking changes because gulp-util was deprecated.

Currently the project needs to have it's NPM and it's child projects NPM packages updated.

Describe the bug

I get an error when trying to create a SPA module. I'm new to yeoman so followed the steps in your tutorial to get everything installed correctly. Then I created an MVC module which worked perfectly.
Then I went to create an SPA one and it failed after entering the last setting field.

To Reproduce

Create new folder, go to folder and run yo dnn.
After entering all details (see screenshot) I get the error below.

Screenshots

Errors

Error: Could not parse JSON in file: C:\node\dnnyeoman\test2\Test2\package.json. Detail: Unexpected token i in JSON at position 135
at EditionInterface.module.exports [as readJSON] (C:\node\dnnyeoman\node_modules\mem-fs-editor\lib\actions\read-json.js:8:13)
at EditionInterface.module.exports [as extendJSON] (C:\node\dnnyeoman\node_modules\mem-fs-editor\lib\actions\extend-json.js:6:30)
at module.exports.writing (C:\node\dnnyeoman\node_modules\generator-dnn\generators\spa\index.js:304:13)
at Object. (C:\node\dnnyeoman\node_modules\yeoman-generator\lib\index.js:424:27)
at C:\node\dnnyeoman\node_modules\run-async\index.js:25:25
at new Promise ()
at C:\node\dnnyeoman\node_modules\run-async\index.js:24:19
at self.env.runLoop.add.completed (C:\node\dnnyeoman\node_modules\yeoman-generator\lib\index.js:425:13)
at runCallback (timers.js:705:18)
at tryOnImmediate (timers.js:676:5)
Emitted 'error' event at:
at Immediate.setImmediate (C:\node\dnnyeoman\node_modules\yeoman-generator\lib\index.js:433:22)
at runCallback (timers.js:705:18)
at tryOnImmediate (timers.js:676:5)
at processImmediate (timers.js:658:5)

I'm runing on Win10 from a node.js command line.
Immediatly after I tried to create a Persona Bar module and that worked fine too.

Describe the solution you'd like

It would be good to be able to run dnn-generator within an existing solution folder and it to default to (or ask) adding the new module project to the existing solution.

Additional context

Currently, it seems to notice the conflict adding the file and ask if you'd like to overwrite your .sln file. If you say No, it creates the module project, and you can add it to the solution manually.

Need to upgrade to Yeoman-Generator package 3.1.1
There could be breaking changes in the script that need to be tested.

Is your feature request related to a problem?

No problem, just mssing option.

Describe the solution you'd like

It would be great to have an Angular based SPA option.

Describe alternatives you've considered

N/A

Additional context

I suggest we focus initially on Angular 2/4/5/6 (not AngularJS, v1) unless there is demand.

I had a problem with version 1.0.6 where adding an SPA module to an existing solution that contained an MVC module did not add the project to the existing solution. Need to verify the _addProjectToSolution call is working correctly for the SPA project.

I believe the packageSource and packageInstall build tasks are creating the incorrect file name and makes it confusing if you are not familiar with module versioning. Since we are using npm we technically have 2 manifest files:

• package.json
• modulename.dnn

The dnn manifest is what really matters as far DNN is concerned. When I tried incrementing the version in the package.json the dnn manifest was not incrementing with the command gulp package command. Which is correct in my opinion, BUT the file name version was incrementing with that. When I looked through the dnn-package.js code I saw that it is pulling the version from the npm package.json and not the dnn manifest.

Here is a small excerpt of the dnn-package.js file to highlight my point

var gulp = require('gulp');
var config = require('../../package.json');

...

gulp.task('packageInstall', ['build'], function() {
  var packageName = config.dnnModule.fullName + '_' + config.version;

...

gulp.task('packageSource', ['build'], function() {
  var packageName = config.dnnModule.fullName + '_' + config.version;
...

I can see good arguments for making a gulp task to increment the version in the manifest file. I personally see this as a bad idea or at least it should be made optional. If you use any type of build environment or additional scripts to track different versions of your module the manifest defines everything. In my build environments I use a script that increments manifest version number to match the build number. If the gulp package overwrote that it would be a headache to get the order of operations just right.

I only investigated MVC but I am assuming SPA is exactly the same

Requested Change/Discussion

I think we should update the dnn-package.js to pull the version from the DNN manifest file instead of the npm manifest file package.json

I would like to discuss this more if there are disagreements on my requested change

We have an MVC Module Yeoman task working. We need to implement the SPA Module task.

It would be very helpful to have a basic CRUD API and basic db setup to allow the front-end devs a good example of how to get started.

When creating a new MVC project the gulp build scripts are not included in the csproj by default. Every time I create a new MVC project I have to manually include the following files:

• build.js
• dnn-package.js

To do this you need to add the following XML inside an existing ItemGroup inside of your csproj

<Content Include="_BuildScripts\gulp\build.js" />
<Content Include="_BuildScripts\gulp\dnn-package.js" />

I choose to add it to the same item group where other build scripts are so the full ItemGroup looks like this:

<ItemGroup>
    <Content Include="_BuildScripts\gulp\build.js" />
    <Content Include="_BuildScripts\gulp\dnn-package.js" />
    <Content Include="_BuildScripts\ModulePackage.targets" />
    <Content Include="_BuildScripts\MSBuild.Community.Tasks.Targets" />
</ItemGroup>

With the new features we need to update the docs on project structure, how to get started, etc.

Describe the bug

When creating a new module, the template uses the attribute [DnnModuleAuthorize(AccessLevel = SecurityAccessLevel.Edit)] on the HomeController. This requires that a user needs edit permissions to the module to be able to view the module

Expected behavior

I would suggest this be set to [DnnModuleAuthorize(AccessLevel = SecurityAccessLevel.View)] or removed altogether (assuming the default Authorize level is View)

Describe the bug

When you create the installer package the gulp scripts are included and are installed onto DNN. I believe this is in error since the scripts are just designed for building the module not running the module.

This was tested with just MVC but may be occurring in the other module patterns as well

To Reproduce

Steps to reproduce the behavior:

1. Create a new DNN MVC module
2. Package the module up for install
3. Install the module into DNN

Expected Behavior

• The module installs without issue
• Build scripts are omitted from the release build

Actual Behavior

1. Open up the folder DesktopModules/MVC/MyCompany/MyModule (where MyCompany and MyModule are the names you supplied to yo dnn.
2. You will see the _BuildScripts folder with the gulp scripts

Screenshots

This is the directory output of an installed module using the DNN MVC template