ElectronNET.Core:: Taking it to the Next Leve #893
Conversation
- Update all packages to their latest version - Drop tslint (replaced by eslint) - Update node types to 22 => nodejs => 22 is minimum now - Also use latest TypeScript version - Finally, reference ElectronHostHook has a package dependency this avoids conflicts of dependency versions between main code and host-hook code, by letting npm resolve them
- Consume host-hook as a module
- Use package.json instead of electron-manifest.json
- Support new commandline flags:
- unpackedelectron
running in debug mode, electron first, so must launch dotnet
- unpackeddotnet
running in debug mode, dotnet first, do not launch dotnet
- dotnetpacked
running from electron-builder output, dotnet first, do not launch
- {none of the above flags}
running from electron-builder output, electron first, launch dotnet
- electronforcedport
specified by dotnet when dotnet-first, port is validated to be free
- Removed 'watch' functionality (regular debugging is working now)
- New feature to load a custom_main.js file, if present
- Removed the 'electronWebPort' handling
When ASP.Net is launched first, then the information which port it
should use would be coming too late; anyway, there's no need for
letting the port number round-trip all the way through the manifest
file, loaded by main.js and then sent to dotnet.
- Reworked handling of 'quit' message
This probably stems from newer ts definition or the newer ts version. It errored because it cannot determine the event name and so it considers argv[] as empty.
The crashed event has been removed in Electron 29 - just let TS ignore that error
…ice orchestration)
These were too short when debugging on WSL
- Add a ElectronNetDevMode property at the top This allows switching the project between using the nuget packages and consuming the core code directly via project references and direct imports or .props and .targets files - Add the project data which was previously in the manifest file - Add the Microsoft.TypeScript.MSBuild package This overrides the ASP.Net built-in TS support which is currently at version 5.6 only. With this package, we get 5.9.3 everywhere, so everything is consistent now. The only caveat is that it requires exclusion of folders (especially node_modules), so that they don't get attempted to be compiled
|
OK, looks great. Can we fix the NUKE project? You can forget about AppVeyor (we should finally remove it). Thanks! |
|
Minor suggestions to make solution compatible with other IDEs such as VSCode or JetBrains Rider as well as plain
|
Alright, will do! |
I wouldn't want to exclude it because it's a crucial part and it's not going to be worked on by many users (consuming users of Electron.NET won't normally touch it).
Eventually it might make sense to migrate it to a TypeScript SDK project, the bit advantage here is not the TypeScript compilation (you can get that in many ways) but the fact that it bring the VSCode JS debugger under the hood. This allows you to do a multi-project debugging startup configuration where the TypeScript project attaches to the Node debugging interface or the Chromium debugging port (or both) and then you can get seamless debugging between dotnet code, node js code and browser js code. |
Only as a minimum. The reason for adding this is that we have seen a number of weird issues in our Azure DevOps builds. In all cases, the outcome (after painful research) was that their runner images had removed older SDKs and our net6 projects got build with a .net 9 SDK. In the past (earlier .net versions), such issues were extremely rare, but unfortinately, the situation has changed now. It doesn't need to be 316, though. We can change it to 8.0.100 (first non-prerelease SDK). |
|
Just wanted to reiterate that these are very minor problems and are not a priority, full response below:
C:\Dev\ElectronNET-electronnet_core\src\ElectronNET.sln : Solution file error MSB4249: Unable to build website project "ElectronNET.Host". The ASP.NET compiler is only available on the .NET Framework version of MSBuild.Rider workaround: unloading ElectronNET.Host project from solution same action as you can do in Visual Studio. Unfortunately for VSCode things become very messy, commenting out the project does not work as it is referenced in multiple places. As I mentioned before these are very minor problems and since I work in Rider its pretty much a no issue. Additionally
C:\Dev\ElectronNET-electronnet_core\src (electronnet_core -> origin)
dotnet build ElectronNET.WebApp/ElectronNET.WebApp.csproj
The command could not be loaded, possibly because:
* You intended to execute a .NET application:
The application 'build' does not exist.
* You intended to execute a .NET SDK command:
A compatible .NET SDK was not found.
Requested SDK version: 8.0.316
global.json file: C:\Dev\ElectronNET-electronnet_core\src\global.json
Installed SDKs:
1.1.14 [C:\Program Files\dotnet\sdk]
2.1.202 [C:\Program Files\dotnet\sdk]
2.1.526 [C:\Program Files\dotnet\sdk]
3.1.426 [C:\Program Files\dotnet\sdk]
5.0.104 [C:\Program Files\dotnet\sdk]
6.0.321 [C:\Program Files\dotnet\sdk]
7.0.410 [C:\Program Files\dotnet\sdk]
8.0.205 [C:\Program Files\dotnet\sdk]
8.0.206 [C:\Program Files\dotnet\sdk]
8.0.414 [C:\Program Files\dotnet\sdk]
9.0.305 [C:\Program Files\dotnet\sdk]
Install the [8.0.316] .NET SDK or update [C:\Dev\ElectronNET-electronnet_core\src\global.json] to match an installed SDK.
Learn about SDK resolution:
https://aka.ms/dotnet/sdk-not-found |
- Remove obsolete sample targets - Restore and build solution (.Lean) instead of projects - Read version from common.props, compare with latest changelog version and fail if not equal - Keep PostFix separate from version (AssemblyVersion may not have a postfix), so the postfix will go into the package version and file name as well as the informational version (visible in file properties dialog on Windows) - Add "ElectronNET.Core " as prefix to GitHub release names (to disambiguate with earlier versions)
@agracio - Thanks for that output! You were right, it didn't roll forward because setting rollForward to 'patch' doe not cross the feature bands (i.e. 100s 300s or 400s are kept separate).
I have added a second solution file now: Thanks for sharing your concerns, it was even more helpful than you might think! |
Done! I hope you're okay withe the way I've done it. I needed to find some middle ground which (hopefully) satisfies all sides, because until everything is settled, I still need to be able to create versioned packages for your private feed without any delay, so I kept the version source inside common.props while nuke is reading this one plus the version from the changelog and fails when not equal. I also preserved the ability of postfixing the version for pre-release etc. For restoring, building and packing, I switched to using an (extra) sln file - once for simplicity, but also because restoring interdependent projects separately can cause problems (you haven't had such dependencies before, hence it was fine). PS: Yes, getting rid of that AppVeyor check would be cool - seeing all green is much nicer 😉 |
|
@GregorBiswanger do you have access to AppVeyor (in particular the registration for ElectronNET)? Would be cool to delete the web hook there. Just let me know. Otherwise I would merge this in - so if there are any concerns or required enhancements let me know. |
|
Solution looks a lot cleaner with ElectronNET.Lean.sln, very minor observations that are not necessarily have to be addressed.
|
|
Additionally while I am aware that Wiki is very fresh and is incomplete 'Getting Started -> With ASP.Net' has incorrect code at least in my experience following the guide. I ended up combining original Program.cs code that loads Razor pages with Wiki code. Wiki code is trying to load Controller and Views that do not exist in a freshly created project. This is my code for starting freshly created webapp. using ElectronNET.API;
using ElectronNET.API.Entities;
var builder = WebApplication.CreateBuilder(args);
// Enable Electron.NET with callback for UI setup
builder.WebHost.UseElectron(args, ElectronAppReady);
// Add services to the container
builder.Services.AddRazorPages();
var app = builder.Build();
// Configure the HTTP request pipeline
if (!app.Environment.IsDevelopment())
{
app.UseExceptionHandler("/Error");
app.UseHsts();
}
app.UseHttpsRedirection();
app.UseRouting();
app.UseAuthorization();
app.MapStaticAssets();
app.MapRazorPages()
.WithStaticAssets();
app.Run();
// Electron initialization callback
async Task ElectronAppReady()
{
var browserWindow = await Electron.WindowManager.CreateWindowAsync(
new BrowserWindowOptions
{
Width = 1200,
Height = 800,
Show = false,
WebPreferences = new WebPreferences
{
NodeIntegration = false,
ContextIsolation = true
}
});
// Load your ASP.NET application, make sure to match port number in launchSettings.json
await browserWindow.WebContents.LoadURLAsync("http://localhost:8001");
browserWindow.OnReadyToShow += () => browserWindow.Show();
} |
|
@agracio - Thanks a lot for the feedback!
Yea, it's intended - it't a cheap trick to keep it at the top 😜
All projects are class libraries. There's nothing to run..?
Maybe I was a bit overprotective here. I included it because all other outputs which go into the packages are part of the repo, including compilation output (like all the .js files from TypeScript compilation), so that nothing can go wrong and things are just "working". Thanks |
|
Just FYI @softworkz: The publish failed as the currently assigned NuGet key is missing the new package. I am in contact with @GregorBiswanger and we will update / fix this ASAP. I will trigger a re-build to publish the preview of the package once this is done. |
|
Thanks! I'm currently reviewing the docs and PR them shortly. |
You're right, AI had found that it should get a little creative about that code, even though, I had already provided the snippet I wanted to have in the rough draft I had prepared before: Anyway, it's fixed in the new PR now. Thanks |
3 participants
This PR includes all the the changes that have been discussed in Taking it to the Next Level!
I haven't updated any documentation yet. This PR - for now - is focused on getting everybody a quick start without much hazzle. I have even checked in the current nuget packages, in order to get the hurdle of building and consuming out of the way.
Quick Start Instructions
Warning
IMPORTANT: You must do a fresh checkout. Either clone into a new directory or - after checking out the branch, delete ALL files in the repo except the
.gitfolder and then do a git reset.Run on WSL
Prerequisites
(but I think the ASP.Net core framework does the installation automatically when you start debugging)
To launch Debugging on WSL
Creating Packages
Please let me know how it works for you
Enjoy!