Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Paket requires extra privileges in Windows #578

Closed
cmeeren opened this issue Oct 25, 2022 · 7 comments
Closed

Paket requires extra privileges in Windows #578

cmeeren opened this issue Oct 25, 2022 · 7 comments
Labels
needs-info

Comments

@cmeeren
Copy link

cmeeren commented Oct 25, 2022 •
edited
Loading

I am trying to set up a FSharpLint dev environment locally. From a clean repo, I first did dotnet tool restore, and then dotnet fake build, but the latter fails:

There was a problem while setting up the environment:
-> symlink C:\Users\cmeer\.nuget\packages\runtime.native.system.net.security\4.3.1 -> C:\Users\cmeer\Source\Repos\FSharpLint\packages\docs\runtime.native.System.Net.Security failed with error : [1] with output : 
    and error : You do not have sufficient privilege to perform this operation.

Do I have to run the build command with administrative privileges? I am hesitant to do that. It should not be needed.
@cmeeren
Copy link
Author

cmeeren commented Oct 25, 2022 •
edited
Loading

Seems it's a known issue with paket: fsprojects/Paket#3767 (comment)

Turned on developer mode in Windows and it works.

Do you run with elevated privileges or with Windows in developer mode?

@knocte
Copy link
Collaborator

knocte commented Oct 26, 2022

Thanks for the bug report and providing a workaround. As for me, I'm using Linux and never got this problem.

We're thinking of dropping paket anyway, now that NuGet has central-package-management capabilities (and also because I've ran into other paket bugs myself).

@knocte knocte changed the title Readme build instructions do not work Paket requires extra privileges in Windows Oct 26, 2022
@cmeeren
Copy link
Author

cmeeren commented Oct 26, 2022

That would definitely simplify setup for me. (I mostly just use the IDE, Rider in my case, and let that handle restores, build, and testing. It's always a hurdle to start to contribute to OSS projects where that doesn't work and I have to use build scripts.)

@Numpsy
Copy link
Contributor

Numpsy commented Nov 3, 2023

Thanks for the bug report and providing a workaround. As for me, I'm using Linux and never got this problem.

We're thinking of dropping paket anyway, now that NuGet has central-package-management capabilities (and also because I've ran into other paket bugs myself).

What are the current thoughts on Paket vs. Nuget? If we can get the build update to the current .NET SDK then we could try changing it to use directory.packages.props instead?

This was referenced Nov 22, 2023
Closed
Merged
knocte pushed a commit that referenced this issue Nov 22, 2023
@Numpsy
Paket: use Packages storage (#615)
b0f12c5 
I've been trying to get everything [building with .NET 6](#606) and the related tooling, and have been getting CI build failures in the macOS builds, with errors that look like those described at fsprojects/Paket#3767

It looks like changing Paket to use 'packages' storage instead of 'symlink' avoids that issue, by putting the restored nuget packages directly into the local packages folder instead of symlinking them. (I don't know much about this Paket feature - the docs suggest its for reducing disk usage by avoid duplicates, which might not really be an issue for the builds?)

On a related note, we also have this issue - #578 - where you have to either run the build as admin on windows or set some extra OS options otherwise the package restore will fail. I think this change would avoid that as well.

Note: Changing the paket storage to 'none' helped with package restore issue, but caused the 'docs' build to break for me because the Fornax tool couldn't find the libraries, whereas it works when set to 'packages'
@knocte
Copy link
Collaborator

knocte commented Nov 23, 2023

@cmeeren I have the suspicion that PR #615 (which I merged yesterday) might have fixed this issue. Can you re-test and let us know?

@cmeeren
Copy link
Author

cmeeren commented Nov 23, 2023

Sorry, I have long since moved on and can not prioritize this now.

@knocte
Copy link
Collaborator

knocte commented Nov 23, 2023

Ok, then I hope you don't mind that I close this, and if you find the issue again, please reopen!

@knocte knocte closed this as completed Nov 23, 2023
@cmeeren cmeeren mentioned this issue Nov 23, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
needs-info
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@knocte @Numpsy @cmeeren