Gulp Package Uses Wrong Version Number about generator-dnn

[mtrutledge]

Looking at nvQuickTheme their gulp build tasks also manage the information in the manifest file

[mtrutledge]

After some discussions, we are going to change the packageInstall and packageSource to pull the version from the manifest file. Then we are going to add a manifest task that will update the version of the manifest.

[mtrutledge]

I do believe the version of the Dlls is set through the package.json configuration via a gulp task that updates the Assembly Info. So if the manifest is not being updated that is a bug. The initial idea was that gulp would drive the build process. Eventually, I would like the dnn manifest file to be generated for the user so they do not have to manage it. For example, the program would store the user's information in the package.json file and then during build a process would look for any folder with a View file in it and consider that a module and add it to the dnn.manifest file and then package the installer. I also believe that is the way nvQuickTheme is generating the manifest file (Uses config values from the package.json and populates the dnn.manifest on build)

[SkyeHoefling]

I have some problems with the package.json managing the manifest file.

• What if a user needs to modify the manifest file for their project and the gulp tasks keep overwriting it?
• What if a user needs to make their manifest file include multiple modules. One extension that installs multiple dnn modules
• What if the user needs to add a non-default home route in case of MVC

There is going to be a fine line between making things easier and having gulp tasks do it all for us and taking away control from people where the tool might not be as useful.

With all that being said I see a lot of merit in having gulp manage the dnn manifest file. I personally find it cumbersome in how my modules are managed from a build, versioning and manifest file perspective.

This is going to require more thought.

[mtrutledge]

It will be hard to strike a balance. There may have to be some gulp tasks that are run optionally. If someone uses the npm version command then there should be a hook that would update the manifest versions after the version has been patched.

Or maybe we give instructions to disable a build step if the user wants to manually manage their manifest file. That might be a really good option considering this tool was meant to attract some newer developers.

[david-poindexter]

That is correct @mtrutledge - we also have a separate JSON file for making project setup a bit easier. That way people do not have to understand all the intricacies of the DNN manifest file.

[SkyeHoefling]

My question is where does this leave the power users? The people that are comfortable modifying the manifest file? They need to find portions of the gulp tasks and update them to not overwrite their changes

[SkyeHoefling]

This is a great compromise where we can still take advantage of all the gulp scripts but still take into account the power users that want to manage the manifest themselves.

Do you want help with this one? We should just need an xml reader that we include and grab the file version. The only issue that may come up is with old manifest files the version isn't set the same way, but I don't think it is a problem we will run into with this tooling. As a safeguard we could follow this workflow:

1. Check the dnn manifest file first
2. Check the node package.json file 2nd

this way we have a fallback in case the manifest file is messed up for whatever reason