---
# System prepended metadata

title: 23/08/21

---

# 23/08/21

## 08:15 - 09:30
- Currently thinking about How I can tackle the Asar issue.
- I think the best bet is to get all the other task done around it and then spend the afternoon seeing I can solve it one more time.
- I am currently setting up my computer for C compilation.
- Ok the c program is ready
- I will now copy over the required files and see if I can run them. 

## 09:30 - 10:30
- The structure for the deployment of ES and gnlmpc has been created with gnlmpc config and the exe in the root. As well as a bin folder which contains the electron binaries and the source code.
- c program now works and as well as the cmd file.
- Looks like the ideal setup is nearly read.
- seems that the .env file has to be where ever the root of the command being run is.
- 

## 10:30 - 11:30
- Ok all you have to do now is do an npm install and npm build within the app and then click on gNLMPC.exe
-  ![](https://i.imgur.com/MxN9ppb.png)
-  The last thing is the Asar 
-  I'm going to take a screenshot of the main issue so that I have evidence of the issue.
-  I just had a thought, what if I npm install from the c file. 
-  I was right, I hve create one system() command within the c program that runs all commands at once. 
-  Now all the developer needs to do is run the script then run the gnlmpc.exe
-  I will now tackle the last issue of the asar 
-  after spending Thursday afternoon and Friday on this problem I don't know if it is possible because of the amount of different solutions I have applied to the problem. 
-  The problem being the asar unable to use @gdap directory paths for some reason.
-  ![](https://i.imgur.com/eUZTJGq.png)
- The asar seems to not recognise the workbench.
-  The highlighted line of code is causing the issue in the screenshot below:
-  ![](https://i.imgur.com/VMee4Yf.png)
-  What I have found is that even if the @gdap/workbench is npm installed the problem persists.
-  Evene if you clone a new copy of the ES project and try and place it within the app folder you still get the same issue.
- If ypu replace the @gdap/workbench path with a direct path to the file such as packages\engineering-studio-framework\workbench\source\workbench-app.class.js you's have to replace all of the paths throughout the project and even then that might not work.
- I think I may have found a resolution by pushing the node_modules to the paths

## 11:30 - 12:00
- There is a known issue for native module dependencies such as gdap not being recognised by asar.
- this can be found here: https://github.com/electron/electron-packager/issues/217
- 

## 12:00 - 12:15 
- no huddle going on today
- I have updated the group by publishing this md


## 12:15 - 12:30 
- 

## 12:30 - 13:30
- Lunch

## 13:30 - 14:30
- Currently trying to find any work around for the asar issue.
- I am experimenting with module.paths.push(path.resolve("resources\\app.asar\\node_modules\\@gdap"));
- module.paths.push(path.resolve("resources\\app.asar\\node_modules\\@gdap/workbench"));
- to see whether it is access to the module folder that is causing the issue.

## 14:30 - 15:30
- seems to be a common issue:
- https://github.com/electron-userland/electron-builder/issues/844
- I did a little test where a ran directly from the source and from the asar and found that the filesystem test for the gdap workbench path doesn;t exist in asar but it does exist in the source code.
- ![](https://i.imgur.com/cjnNZBe.png)


## 15:30 - 16:45
- Just seeing what gets return when console logging the gdap workbench require.
- nothing, nothing gets returned.
- just adding:
-  "@gdap/workbench": "\\engineering-studio-framework\\workbench",
-  to the package dependency to see if that has any affact on the error.
-  Zero affect.
-  Ok, so you've been through multiple scenarios and multiple fixes. None of which have worked.
-  The next step will be to create a presentation video for Asa and to update him on the situation.