mirror of
https://github.com/ElectronNET/Electron.NET.git
synced 2026-02-03 21:25:13 +00:00
BuildAll.cmd expect dotnet-electronize to be in the PATH #58
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @tebeco on GitHub (Nov 6, 2017).
Originally assigned to: @robertmuehsig on GitHub.
To be a bit more specific :
Clone the repo in a brand new folder
The output is :
I maybe wrong but
running
dotnet foobarwill try to find an executable nameddotnet-foobarin the current folder (not sure about that one)then in the PATH
here the build try to
dotnet electronize stuffand it feels logical that it fails since when developing this
dotnetextension point we might not want it to be in the path.but since we did build
dotnet-electronizein the previos step it would be perfectly acceptable to run the actualElectronNet.Cli\bin\${Build_Config}\${Target_Runtime}\dotnet-electronize.exe build winThis is where this is interesting
i was trying to reproduce the CLI build
output :
What is in CsProj ?
see:
https://github.com/dotnet/cli/issues/6760
so either
dotnet run ElectronNet.Cli\bin\${Build_Config}\${Target_Runtime}\dotnet-electronize.exe build winI guess the second one seems to be the best but so far i get this :
it seems that the CLI tries to run the webapp .... WTF
@robertmuehsig commented on GitHub (Nov 6, 2017):
Gregor had the same problem when using it from the Visual Studio Powershell window. Could you try to use it in a "normal" cmd prompt?
Otherwise the CLI is created like this example: https://blog.maartenballiauw.be/post/2017/04/10/extending-dotnet-cli-with-custom-tools.html
@tebeco commented on GitHub (Nov 6, 2017):
No luck i was already using
cmdeverywhere on this project@robertmuehsig commented on GitHub (Nov 6, 2017):
Are you trying to add new stuff to the CLI? If yes: Be aware, that NuGet caches pretty aggressivly. You can use my command (devCleanup) or checkout our Wiki:
https://github.com/ElectronNET/Electron.NET/wiki
Another point: NuGet.org is currently down and I'm not sure if the dotnet cli extensions are "failure" tolerant.
We just produce a CLI NuGet package, which is linked via the csproj - the loading and caching does dotnet/nuget for us. It's just a naming convention (dotnet-electronize).
@robertmuehsig commented on GitHub (Nov 6, 2017):
Oh - and we are not doing anything with the PATH. Our AppVeyor builds for example are very simple and I didn't need any setup for it.
@tebeco commented on GitHub (Nov 6, 2017):
the
buildAll.cmdfail locally :dotnet electronizelook fordotnet-electronizeand there's no chance that it would fine iti tried to fix it but so far with no sucess
@robertmuehsig commented on GitHub (Nov 6, 2017):
Nope - "dotnet-TOOLNAME" is a valid approach here. dotnet.exe searchs for a assembly name that has this pattern.
There are other examples out there with the same naming e.g. Amazon does it this way
Our AppVeyor/TravisCI build does this all the time - it just invokes the buildAll.cmd/sh
It has nothing to do with PATH settings if you are using the .NET Core 2.0 SDK. Have you checked the wiki? Maybe you have an older cached version of the electronnet.cli package in the nuget cache.
@tebeco commented on GitHub (Nov 6, 2017):
but there's no exe, only a dll
dotnet-electronize.dllbecause theCLI.csprojdoes not have RIDhttps://github.com/dotnet/cli/issues/6760
(will continue to investigate tomorrow)
and i'll read that sample
@robertmuehsig commented on GitHub (Nov 6, 2017):
This is by design - the CLI project itself will produce a .dll, which is packed as a NuGet package and is then consumed and run by dotnet.exe. This is nothing we invented, thats at least one way of doing it.
Reference:
"As mentioned, tools are just portable console applications. You build tools as you would build any other console application. After you build it, you use the dotnet pack command to create a NuGet package (.nupkg file) that contains your code, information about its dependencies, and so on. You can give any name to the package, but the application inside, the actual tool binary, has to conform to the convention of dotnet- in order for dotnet to be able to invoke it."
https://docs.microsoft.com/en-us/dotnet/core/tools/extensibility#per-project-based-extensibility
Some other examples: https://github.com/dotnet/cli/tree/rel/1.0.1/TestAssets/TestPackages
The CLI extensions are "normal" dotnet core console apps and are meant to be run through dotnet.exe, just like a regular .NET Core Console app, see:
No .exe generated (at least if you don't do the RID stuff in it)
@tebeco commented on GitHub (Nov 14, 2017):
can you please check #56
This is what kinds of i got from MSDN or speaking on slack about CLI extensions
I had trouble because i used
dotnet run xxxinstead ofdotnet cli.dll@robertmuehsig commented on GitHub (Nov 14, 2017):
Response in the PR.
@robertmuehsig commented on GitHub (Nov 14, 2017):
PR merged (and I also enhanced the .sh for osx/linux builds). Can this issue be closed?
@tebeco commented on GitHub (Nov 15, 2017):
totally forgot the other scripts do you want another PR so you could close this issue ?
@robertmuehsig commented on GitHub (Nov 15, 2017):
Do you mean the start.cmd/.sh? If yes: I think it might be good to avoid the NuGet cache problem locally
Von meinem iPhone gesendet
Am 15.11.2017 um 07:22 schrieb TeBeCo <notifications@github.commailto:notifications@github.com>:
totally forgot the other scripts do you want another PR so you could close this issue ?
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHubhttps://github.com/ElectronNET/Electron.NET/issues/45#issuecomment-344497333, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAuL3zz45KDExL122LkgTx4I93x_VeW9ks5s2oL2gaJpZM4QT4iM.
@robertmuehsig commented on GitHub (Nov 15, 2017):
I will close this one - the start.cmd/.sh file doesn't need it currently, because it skips the electronize start.