-
|
I am upgrading to electronnet.core 0.3.0-pre and hitting the strict ELECTRON001 error (MIGRATION REQUIRED), which blocks the build because a package.json was found in the project root. My application is an aspnet core app which hosts Blazor Server. I use a package.json strictly to manage standard frontend libraries (e.g., Bootstrap, Popper, custom JS/CSS assets) which are bundled into wwwroot. The Conflict: The new build tooling seems to assume any package.json is an attempt to configure the Electron Host. However, in modern ASP.NET Core/Blazor development, it is standard practice to keep a package.json in the root for managing UI dependencies and build scripts (Webpack/etc). Question: Blocking all package.json files feels overly restrictive for hybrid apps that need npm for the UI layer but use MSBuild for the Electron host. Is there a way to configure Electron.NET to ignore a specific package.json so it doesn't trigger ELECTRON001? If not, what is the recommended architecture? Moving UI asset definitions outside my project folder seems like an unnecessary workaround for a standard web workflow. Thanks! |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
|
Hi @davidroth, that's a very valid point. In the context of adding the migration checks I had already acknowledged this: #944 (comment) But it hasn't been addressed yet. I wanted to wait until we're hitting a case in order to better understand how we can refine the migration check accordingly.
But all the migration checks are warnings - not errors. ` Do you have any MSBuild configuration to "treat warnings as errors"? |
Beta Was this translation helpful? Give feedback.
-
|
@softworkz Oh, gosh—yes, I have warnings as errors enabled; I didn't realize that was the reason for the Anyway, |
Beta Was this translation helpful? Give feedback.
Hi @davidroth,
that's a very valid point.
In the context of adding the migration checks I had already acknowledged this: #944 (comment)
But it hasn't been addressed yet. I wanted to wait until we're hitting a case in order to better understand how we can refine the migration check accordingly.
But all the migration checks are warnings - not errors. `
Do you have any MSBuild configuration to "treat warnings as errors"?