mtrutledge
Compromise for disconnected dev model
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.
That’s a great idea!
On Jun 29, 2018, at 4:38 PM, nvisionative [email protected] wrote:
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.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
So I would essentially need to find out where their local DNN instance is installed and then run a command like?
mklink /d D:\WhereverProjectIs\ C:\inetpub\wwwroot\DotNetNuke\DesktopModules\CompanyName\
This is exactly what I do and I find it very helpful for rapid development. A couple things that you should really be careful with this:
- Run the mklink command for the dll(s) in the bin directory. I strongly recommend running the command for the pdb so you can get debugger support
- Run the mklink link for the views (cshtml) directory
- mklink and IIS don't play nice, even if I am updating cshtml code I find myself running
iisreset
Great points @ahoefling - with SPA approach we typically don't have the IIS issue though.
I have been putting some more thought into this and I have come up with a new solution that I think will be really benefit this project. I have added several new gulp tasks that handle a basic local deploy
- Copies .dll and .pdb files to the bin directory of a local dnn site
- Delete the Views folder and copies all files recursively from your dev code into your module in DNN
After initial testing this appears to be working and resolves the issues I highlighed above with MKLINK and requiring iisreset while even updating views.
This doesn't come with a trade off, which I hope we can discuss alternatives and come up with a good solution.
- The gulp script now relies on the location of a local DNN instance
If anyone wants to try out the scripts let me know and I can post them in this thread
@ahoefling it would be great to have a gulp command to set the DNN instance path. That would make it easy to switch sites. We usually test on multuiple DNN versions during development. Worst case, the DNN instance path should be stored in a simple JSON file within the project.
@ahoefling https://github.com/ahoefling Of course the other option is to use the DnnCli to install the package to a local instance. Since multiple instances are sometimes on a local machine it would be ideal to list those instances somehow so the user could choose which instance. They could run a command like
npm run deploy
It would trigger a gulp script of some sort to prompt for the DNN instance. Once the instance is picked then DnnCli could install the package.
On Jul 25, 2018, at 6:55 AM, nvisionative [email protected] wrote:
@ahoefling https://github.com/ahoefling it would be great to have a gulp command to set the DNN instance path. That would make it easy to switch sites. We usually test on multuiple DNN versions during development. Worst case, the DNN instance path should be stored in a simple JSON file within the project.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/mtrutledge/generator-dnn/issues/16#issuecomment-407744510, or mute the thread https://github.com/notifications/unsubscribe-auth/ACCJ_v-TUQ4XK-LKU2dgGzFH0W7emlFSks5uKGq3gaJpZM4U9tYv.
The problem with using the DNN Installer regardless of how we invoke it (DnnCli, etc.) is we need the .PDB files to be shipped into the bin directory. I'm not sure if the DNN installer framework would handle copying over the pdbs unless we specified them in the dnn manifest file.
The idea here is for development, not deployment. As a developer I am going to manage the database myself so it is okay to not run the sql scripts as part of these gulp tasks. The important thing is I need my dlls and pdbs in the bin directory. I need any static content I have created to be copied into my module folder
Here are my thoughts on this:
developer locally runs command npm run start (as this is a pretty standard command available for node and js projects)
start does the following:
- Builds the module
- Detects if a DNN instance has been configured in the package.json file. If not prompts and asks for root location of instance. This could later be changes by running somthing like
npm run start —dnn-instance=path - Detects if module has ever been installed. If not runs DnnCli to install the package
- Start http://dnndev.me http://dnndev.me/ in the default browser
- Start a watch task that will auto copy DLL, PDB, and any module files to the dnn instance. This will allow the developer to just change files locally and when they change they would get copied over. If the build is ran again the dlls and pdbs would change and be auto copied over.
How does that sound?
On Jul 25, 2018, at 9:46 AM, Andrew Hoefling [email protected] wrote:
The problem with using the DNN Installer regardless of how we invoke it (DnnCli, etc.) is we need the .PDB files to be shipped into the bin directory. I'm not sure if the DNN installer framework would handle copying over the pdbs unless we specified them in the dnn manifest file.
The idea here is for development, not deployment. As a developer I am going to manage the database myself so it is okay to not run the sql scripts as part of these gulp tasks. The important thing is I need my dlls and pdbs in the bin directory. I need any static content I have created to be copied into my module folder
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/mtrutledge/generator-dnn/issues/16#issuecomment-407801340, or mute the thread https://github.com/notifications/unsubscribe-auth/ACCJ_ogikq4dioHQ41OHRGDJmx9GHwwpks5uKJK_gaJpZM4U9tYv.
I like this idea a lot but I think we need create a few different commands here to facilitate different development environments:
- npm run start
- full lifecycle like you mentioned above
- npm deploy
- Detects if module has ever been installed. if not run execute the following steps
- Run npm package to build installer
- Run the dnn installer using something like DnnCli
- at this point it will be safe to side load everything else
- Copies dll,pdb, and any other module files over to correct directories (side-load)
- Detects if module has ever been installed. if not run execute the following steps
- npm debug
- Runs npm deploy
- Starts http://dnndev.me in the default browswer
- Maybe it would attach a debugger? This is more for visual studio integration, probably not a good idea for npm
- npm watch or npm debug watch (whatever is the best convention)
- Runs npm debug
- added the necessary watch for all the copied files so you don't need to constantly run npm debug or npm deploy (there is a gotcha to this that I will document below under MSBUILD)
MSBuild Issues
Looking through the proposed build tasks above there is an issue with the npm watch and the concept of updating the files on the server as they are changed. How do we update/generate the dll/pdb files?
- typically this is done via MSBuild
This really doesn't fit into the gulp task architecture IMO so adding the watch for the dlls and pdb isn't really useful. Unless the idea is to just copy over the dll so the app can get the latest code.
What I think we should do is build a visual studio integration with gulp which just requires a gulp directive at the top of the gulpfile.js.
- When the user runs a build from visual studio after completing it should run the npm debug or npm deploy.
Following this pattern for msbuild now allows the user to build their code and deploy it easily with 1 button click in visual studio. They will then be able to attach their debugger to the code.
IMPORTANT
We can't attach the debugger to a pdb/dll file that was built from gulp that needs to happen by visual studio or the debugger will think it is not user code.
The watch command can trigger any gulp task, so if it detects a change in a cs file we can have it auto run the build task and then deploy the new dll and pdbs. Gulp itself is not actually doing the build, msbuild is doing the build. The gulp task just executes msbuild.
On Jul 25, 2018, at 11:51 AM, Andrew Hoefling [email protected] wrote:
I like this idea a lot but I think we need create a few different commands here to facilitate different development environments:
npm run start full lifecycle like you mentioned above npm deploy Detects if module has ever been installed. if not run execute the following steps Run npm package to build installer Run the dnn installer using something like DnnCli at this point it will be safe to side load everything else Copies dll,pdb, and any other module files over to correct directories (side-load) npm debug Runs npm deploy Starts http://dnndev.me http://dnndev.me/ in the default browswer Maybe it would attach a debugger? This is more for visual studio integration, probably not a good idea for npm npm watch or npm debug watch (whatever is the best convention) Runs npm debug added the necessary watch for all the copied files so you don't need to constantly run npm debug or npm deploy (there is a gotcha to this that I will document below under MSBUILD) MSBuild Issues
Looking through the proposed build tasks above there is an issue with the npm watch and the concept of updating the files on the server as they are changed. How do we update/generate the dll/pdb files?
typically this is done via MSBuild This really doesn't fit into the gulp task architecture IMO so adding the watch for the dlls and pdb isn't really useful. Unless the idea is to just copy over the dll so the app can get the latest code.
What I think we should do is build a visual studio integration with gulp which just requires a gulp directive at the top of the gulpfile.js.
When the user runs a build from visual studio after completing it should run the npm debug or npm deploy. Following this pattern for msbuild now allows the user to build their code and deploy it easily with 1 button click in visual studio. They will then be able to attach their debugger to the code.
IMPORTANT
We can't attach the debugger to a pdb/dll file that was built from gulp that needs to happen by visual studio or the debugger will think it is not user code.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/mtrutledge/generator-dnn/issues/16#issuecomment-407840215, or mute the thread https://github.com/notifications/unsubscribe-auth/ACCJ_iaZl9oJiv-HUzd9TOMgSgkEmTYfks5uKLAsgaJpZM4U9tYv.
Okay that makes sense on how the watch works as I don't have much experience in that. While msbuild is running via the command line there is an issue with the PDB that are being generated. This is a problem I ran into the other night when I was writing these tasks. When I tried attaching to a pdb that was generated by the gulp task I couldn't. I could only attach to the pdb/dll that was generated by visual studio.
I may have a bad configuration but I am reporting the behavior that I have seen in the field when testing these ideas out
ok that will require some more tests since msbuild is actually running to create the files. Maybe there is another parameter that needs to be passed to msbuild.
On Jul 25, 2018, at 12:12 PM, Andrew Hoefling [email protected] wrote:
Okay that makes sense on how the watch works as I don't have much experience in that. While msbuild is running via the command line there is an issue with the PDB that are being generated. This is a problem I ran into the other night when I was writing these tasks. When I tried attaching to a pdb that was generated by the gulp task I couldn't. I could only attach to the pdb/dll that was generated by visual studio.
I may have a bad configuration but I am reporting the behavior that I have seen in the field when testing these ideas out
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/mtrutledge/generator-dnn/issues/16#issuecomment-407846770, or mute the thread https://github.com/notifications/unsubscribe-auth/ACCJ_hWi0Rs-_2FiDfjHr6GtGl9vayRNks5uKLUrgaJpZM4U9tYv.
what is the benefit of having the gulp task generate the dll/pdb in this scenario? Unless I missed something you really can only debug this with visual studio
There is a command line debugger shipped with the .net sdk called mdbg.exe that allows you to debug outside of visual studio. I might be able to leverage that in the future, The debug symbols generated from the msbuild task should produce valid PDBs.
On Jul 25, 2018, at 12:23 PM, Andrew Hoefling [email protected] wrote:
what is the benefit of having the gulp task generate the dll/pdb in this scenario? Unless I missed something you really can only debug this with visual studio
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/mtrutledge/generator-dnn/issues/16#issuecomment-407849804, or mute the thread https://github.com/notifications/unsubscribe-auth/ACCJ_lF4WC2RzB1LVzOesVuatst56Zkrks5uKLeVgaJpZM4U9tYv.
This makes a lot of sense and I see where you are coming from now.
I did a quick search and I think I found something that may be helpful in our research. It appears there is full .NET Framework debugger support in VS Code (I had no idea). The problem is you need to specify your PDB as portable. My guess is we aren't passing that in the msbuild arguments like you mentioned above.
Take a look at this thread which I found helpful in this topic
https://github.com/OmniSharp/omnisharp-vscode/issues/813
Thanks Andrew. I will take a look. I also created a new Issue in github for the PDB error. I will move this comment over.
On Jul 25, 2018, at 12:35 PM, Andrew Hoefling [email protected] wrote:
This makes a lot of sense and I see where you are coming from now.
I did a quick search and I think I found something that may be helpful in our research. It appears there is full .NET Framework debugger support in VS Code (I had no idea). The problem is you need to specify your PDB as portable. My guess is we aren't passing that in the msbuild arguments like you mentioned above.
Take a look at this thread which I found helpful in this topic
OmniSharp/omnisharp-vscode#813 https://github.com/OmniSharp/omnisharp-vscode/issues/813 — You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/mtrutledge/generator-dnn/issues/16#issuecomment-407853287, or mute the thread https://github.com/notifications/unsubscribe-auth/ACCJ_qV8_3ldDJELbnAlywoUi0dREjXDks5uKLpdgaJpZM4U9tYv.
@mtrutledge and @ahoefling just a thought here - we don't use dnndev.me - we use custom local URLs, so having a way to use those would also be helpful.
@nvisionative Noted. I will keep this in mind.
On Jul 25, 2018, at 5:37 PM, nvisionative [email protected] wrote:
@mtrutledge https://github.com/mtrutledge and @ahoefling https://github.com/ahoefling just a thought here - we don't use dnndev.me - we use custom local URLs, so having a way to use those would also be helpful.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mtrutledge/generator-dnn/issues/16#issuecomment-407929758, or mute the thread https://github.com/notifications/unsubscribe-auth/ACCJ_ntklJ1pXC4HvKdzxqSF1RiFmhsnks5uKQFVgaJpZM4U9tYv.