Unable to package application using dotnet electronize build /target win

[ronish-potiah-cko]

Hi,
I guess the issue is with electron packager.
When I try to package my application using command dotnet electronize build /target win , I encountered the followings:

electron-packager . --platform=win32 --arch=x64 --out="C:[app_path]\bin\desktop" --overwrite
Packaging app for platform win32 x64 using electron v1.7.8
rcedit.exe failed with exit code 1. Fatal error: Unable to commit changes

[robertmuehsig]

Do you get the same error when you try to invoke the electron-packager directly (e.g. open a command prompt and execute this command)?

[ronish-potiah-cko]

@robertmuehsig , when I run the electron-packager directly to execute the above command, I got:

Error: Cannot find module electron from 'C:'
at C:[path]\npm\node_modules\electron-packager\node_modules\resolve\lib\async.js
.......
at FSReqWrap.oncomplete (fs.js:152:21) code: 'MODULE_NOT_FOUND'

[robertmuehsig]

Strange. Maybe it would help if you clean your node_modules folder and reinstall the electron stuff.

[ronish-potiah-cko]

Hi @robertmuehsig ,
I've cleanup everything, re-install again but having the same issue.
Can you try packaging it on your end?

Thanks.

[GregorBiswanger]

Hi @ronish-potiah-cko,
which CLI version is installed?

Use this command please:
dotnet electronize version

[yoDon]

@robertmuehsig I had to move my core development to straight Electron, so I haven't had a chance to check. That said, I spent quite a bit of time deconstructing the architecture of Electron.NET over the past couple months and am convinced the dotnetelectronize CLI app is a huge anti-pattern that just needs to be killed. It's an example of the classic "build systems are too complicated, I'll just whip up a quick C# app that execs the stuff I need and that'll be better." And then it's not enough, so there's a v.next that does more, and does it better. But it's still not enough. And then it gets more complicated. And another hack gets added onto it. Electron apps and modern front-end development live in a world of npm and webpack. Npm and webpack each have >100x more dev-years invested in them than all of Electron.NET. They aren't complicated. And they are proven to scale and solve the real world complexity problems a build system really does need to solve. dotnetelectronize has already reached a level of complexity where it's consuming real architectural time and takes real time for other devs to understand and learn, and it's already lacking the next feature the next dev to try to adopt Electron.NET is going to need.

Your coding time is incredibly valuable. Please don't waste it on a totally non-scalable C# hack to "save us" from needing to understand npm and webpack. Throw away dotnetelectronize before it burns any more of your precious-to-us time and replace it with a couple entries in the scripts section of packages.json and a bit of webpack.config.js. You'll be much happier and we'll be much happier and the community will be able to do much more much faster. Npm and webpack simply aren't hard tech to learn and they are tech any dev doing modern frontend development simply has to understand. dotnetelectronize isn't a time saver or an effort saver or a cognitive saver. It's an anti-pattern.

[robertmuehsig]

@yoDon Thanks for your honest answer. Electron.NET is (at least currently) just a fancy idea/experiement with some good ideas and some mayor flaws. Sticking to the "pure" electron might be a pretty logical idea IMHO, because we can't competete with the manpower behind the other Electron related projects.

"Wasting" our time is a pretty hard description. At least we are learning quite a few things about OSS, Electron and .NET Core - so - everything is good for us :)

Maybe Electron.NET is a anti-pattern, but I know a bunch of people that actually hate Electron itself and they say the same thing about Electron. There are tons of other options (e.g. use the normal Electron, or Xamarin, or some magic cross compiler). Our goal is to write cross platform .NET applications and there are some ways to achive this. Use what works for you :)

[yoDon]

@robertmuehsig thanks for hearing my comments in I think the way they were intended, with great respect for what you're doing and a deep desire for the project to succeed. This project is a super eye-opening way to think about Electron and I suspect the eventual v1.0 will look almost nothing like the first commit and yet I also think if we were able to take it back in a time machine to the time of that first commit we'd all look at the v1.0 and go "yes! that's exactly what we had in mind." It's just about figuring out how to get there.

[robertmuehsig]

Well - just TBH: We will see if we ever ship a proper v1.0, but thanks! 👍

[ronish-potiah-cko]

@robertmuehsig , version is ElectronNET.CLI Version: 0.0.7.0

[robertmuehsig]

You will need the newer version 0.0.9 for the new syntax. You need to reference the new CLI in your .csproj like this:

<ItemGroup>
      <DotNetCliToolReference Include="ElectronNET.CLI" Version="0.0.9" />
 </ItemGroup>

And run "dotnet restore" - this should update your CLI version to the most recent one.

[ronish-potiah-cko]

@robertmuehsig , I've changed the CLI version but with no luck.

Unhandled Exception: System.AggregateException: One or more errors occurred. (The given key was not present in the dictionary.) ---> System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.
at System.ThrowHelper.ThrowKeyNotFoundException()
at System.Collections.Generic.Dictionary2.get_Item(TKey key) at ElectronNET.CLI.Commands.BuildCommand.<ExecuteAsync>b__13_0() at System.Threading.Tasks.Task1.InnerInvoke()
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task& currentTaskSlot)
--- End of inner exception stack trace ---
at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)
at System.Threading.Tasks.Task`1.GetResultCore(Boolean waitCompletionNotification)
at ElectronNET.CLI.Program.Main(String[] args)