-
Notifications
You must be signed in to change notification settings - Fork 585
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FAKE build.cmd fails as dotnet.exe is not in AppData\Local\Microsoft\dotnet #1599
Comments
Uah no idea what happens there, usually the script should install its own
dotnet cli...
Am 22.06.2017 19:02 schrieb "Ben Taylor" <[email protected]>:
… Description
*TLDR: FAKE build.cmd is using Dotnet.fs to find dotnet.exe in AppData
<https://github.com/fsharp/FAKE/blob/master/src/app/Fake.DotNet.Cli/Dotnet.fs#L43>,
but I don't have it at that location, despite it being installed. This
means the source build.cmd fails. Am I missing an install? I've installed
.NET core via VS2017 and the 1, 1.1 and 2 SDKs.*
When attempting to build from the source, the DotNetRestore build task
fails, because dotnet.exe is not located at the path
%MyUserPath%\AppData\Local\Microsoft\dotnet\dotnet.exe. The directory
does exist on my machine, but only contains a folder called
optimizationdata. dotnet.exe does reside on other places on my machine.
I have VS Pro 2017 installed, with the *.NET Core cross-platform
development* workload installed and have separately installed (and
repaired) the .NET
[image: image]
<https://user-images.githubusercontent.com/189409/27440302-34e694b2-5762-11e7-862d-361d8d8e74ed.png>
Repro steps
1. Fetch latest FAKE repos.
2. Merge latest master into my fork master (fast forward).
3. Run build.cmd.
4. Get error as per image above.
Expected behavior
build.cmd would run successfully, perhaps finding dotnet.exe in
C:\%ProgramFiles%\dotnet. I'm not sure, as I'm new to the .NET Core stuff.
Actual behavior
build.cmd attempts to a non-existent dotnet.exe.
Known workarounds
None yet.
Related information
- Windows Server 2012 R2.
- master branch.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#1599>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABx630iUYur9Osm-2veCkedsdp26H5-jks5sGp4qgaJpZM4OClBI>
.
|
Thanks @matthid. I'm still looking in to it, but was hoping someone would know about this. I'm a .NET Core newbie, so a little in the dark. Seemed odd to me that it's looking in AppData. Is the build script supposed to be run as Admin? |
no you don't need to run anything as admin (well besides you messed with
some default directory permissions in windows...)
I think you could comment those targets out (bottom of the build fsx
script) until I have time to investigate if you don't care about the
netcore build
Am 22.06.2017 19:20 schrieb "Ben Taylor" <[email protected]>:
… Thanks @matthid <https://github.com/matthid>. I'm still looking in to it,
but was hoping someone would know about this. I'm a .NET Core newbie, so a
little in the dark. Seemed odd to me that it's looking in AppData.
Is the build script supposed to be run as Admin?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1599 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABx636IIDOxR40tYYLz5BPy8Aodrw1RYks5sGqJagaJpZM4OClBI>
.
|
OK, I'll do that for now and circle back to see if I can figure it out. Thanks. |
I didn't notice it before, but at the same time the build fails, it triggers the opening of the log file below. This seems to be something to do with a quiet install of Feels like some issue around differing
|
Any idea how I can reproduce this? |
I'll grab the latest and try this again. This error stumped me last time I was trying to work on FAKE and I've not had a chance since to go back to it. However, I will have a look right now and see if it is still occurring and what I can to do about a repro. |
Yes, while we test bootstrapping with the old version we only test if we can build with the LATEST package so such issues still might slip through at the moment. Usually I do an update immediately afterwards to fix these. However sometimes I find other issues which block me. |
I think I might be hitting this problem, or something related. I have dotnet 2.0.3 installed under |
Is this still a problem? |
@matthid I've not been working with FAKE since around this time. However, I just checked and I still have the problem. I did the following before confirming:
This fails with:
Given that only @LilRed has chimed in on this issue, I'm guessing my Dotnet installation/config on the VM I use is fubar. I can't speak for @LilRed, but I'm happy for you to close this. If I get back to FAKE dev, I'll be working on a new VM and I'll re-open if the issue persists. For reference, I include the failing output from
Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.
|
I think what happens is that the official PowerShell installer (which we execute) detects an existing installation of the correct version and doesn't actually install the dotnet-sdk into the path we assume. Question is if we properly detect dotnet from PATH (which I think we don't). TLDR: I have an idea how to solve, stay tuned. |
That would explain it. I forgot to add, that the build script also pops what I assume is the install/Wix log for the Dotnet install. Maybe this would help too:
|
@bentayloruk if you need a workaround you can find
Make sure you have added |
if it is not in the default install directory fixes fsprojects#1810 fsprojects#1599
if it is not in the default install directory fixes fsprojects#1810 fsprojects#1599
if it is not in the default install directory fixes fsprojects#1810 fsprojects#1599
if it is not in the default install directory fixes fsprojects#1810 fsprojects#1599
if it is not in the default install directory fixes fsprojects#1810 fsprojects#1599
Ok I think this should now be solved. Please re-try :) |
@matthid I feel like it was going to work, but it failed due to a space in my home folder path. Guessing the path needs to be quoted here? /cc @severisv This was the fail error:
|
I'm unable to reproduce this on Windows 10. Is that what you're using? Are you sure you have the latest package? My project intially ran with the old DotNet.Cli-package until I converted from including the dependencies in the top of my script, to specifying them in |
I ran it on Windows Server 2012 R2. Does your Temp path have a space in it? I think the space is causing the issue, so if you have no spaces in the Temp path, I wouldn't expect it to fail like this. |
I have a space, yes. I agree it looks like a space is the issue on your end :) |
Great, thanks for confirming. I'll go over things again and check. |
Oh wow. Yes people with space in their home directory really like the pain ;). @bentayloruk What is interesting is that the step worked before (ie in your screenshot...) |
@matthid it's was a red herring! On @severisv's prompt, I checked the FAKE install. I had choco installed, not upgraded and so it had stuck with the previous package. The good news is that the Thanks both for fixing and managing! |
Interesting as an old runner shouldn't have an effect like this (In fact one idea is to have runner and libraries independent from each other). But yes from time to time I do some subtle changes in the runner itself. |
The only other thing I did was delete the entire directory of my fork and pull again. |
Description
TLDR: FAKE
build.cmd
is using Dotnet.fs to finddotnet.exe
in AppData, but I don't have it at that location, despite it being installed. This means the sourcebuild.cmd
fails. Am I missing an install? I've installed .NET core via VS2017 and the 1, 1.1 and 2 SDKs.When attempting to build from the source, the
DotNetRestore
build task fails, becausedotnet.exe
is not located at the path%MyUserPath%\AppData\Local\Microsoft\dotnet\dotnet.exe
. The directory does exist on my machine, but only contains a folder calledoptimizationdata
.dotnet.exe
does reside in other places on my machine.I have VS Pro 2017 installed, with the .NET Core cross-platform development workload installed and have separately installed (and repaired) the .NET Core SDKs (1, 1.1 and 2).
Repro steps
build.cmd
.Expected behavior
build.cmd
would run successfully, perhaps findingdotnet.exe
inC:\%ProgramFiles%\dotnet
. I'm not sure, as I'm new to the .NET Core stuff.Actual behavior
build.cmd
attempts to a non-existentdotnet.exe
.Known workarounds
None yet.
Related information
master
branch.The text was updated successfully, but these errors were encountered: