search

madskristensen / WebCompiler

Visual Studio extension for compiling LESS and Sass files
Other
451 stars 173 forks source link

Access to the path 7z.dll is denied. #390

Open cognitivex opened 6 years ago

cognitivex commented 6 years ago

Installed product versions

Description

On a random occasion maybe 5 times a week the error appears with Visual Studio. I've tried deleting .vs folder and .nuget and something can fix it but couldn't tell you the sequence that does work.

Steps to recreate

  1. Use visual studio for a random amount of time, try and compile

Current behavior

Can't build my solution until I got through a sequence of steps to resolve

Expected behavior

Should be able to compile without this exception.

mbp commented 6 years ago

We have the same problem on our team. It comes and goes

rswetnam commented 6 years ago

me too!

davidliang2008 commented 6 years ago

I have the same problem sometimes, which is annoying as I can't reproduce it for sure. But when I do encounter the problem, restarting the visual studio sometimes will let it compile.

enginaar commented 6 years ago

I've been having this issue intermittently for a year now which is since I started using this tool. I'm not sure if I'm missing a warning that says don't use this on production or don't use it for CI. Is there anyone who could offer a reliable alternative or a workaround?

mbp commented 6 years ago

We changed to gulp in our project.

Here are some references: https://dotnetthoughts.net/using-less-css-with-aspnet-core/ https://docs.microsoft.com/en-us/aspnet/core/client-side/bundling-and-minification?view=aspnetcore-2.1&tabs=visual-studio%2Caspnetcore2x

enginaar commented 6 years ago

thanks @mbp. i reviewed gulp and also grunt some time ago and the reason i chose webcompiler at that time was because it doesn't require an additional framework and package manager. i may have to discuss that requirement. thanks again.

leosdad commented 6 years ago

Suddenly I have this problem -- 3 days ago it was fine. Uninstalled and reinstalled, but the extension does not work anymore. Any solutions?

leosdad commented 5 years ago

Please?

MrRedBeard commented 5 years ago

I came across this error but by the time I found this issue thread the Task Runner kicked in and compiled the file. The Task Runner seems to have a delay and may not be the fault of the extension.

Invective commented 5 years ago

I had this earlier. Installed x64 7Zip and gave everyone full access to folder C:\Program Files\7-Zip and it seems to have fixed it?

FionaHolder commented 5 years ago

I had this earlier. Installed x64 7Zip and gave everyone full access to folder C:\Program Files\7-Zip and it seems to have fixed it?

This indeed fixed it for me. Restarting Visual Studio with admin privileges didn't.

hfishere commented 5 years ago

I had this earlier. Installed x64 7Zip and gave everyone full access to folder C:\Program Files\7-Zip and it seems to have fixed it?

I don't know this is a best practice or not, but it is work.

bergy6808 commented 5 years ago

I disabled the updates for the extension (WebCompiler) and everything was working again.

mgandley commented 5 years ago

I've had this same problem a few times, and it was very painful to track down and fix each time. So, here's my write-up on how I fixed it - hopefully it saves some of you some time.

Problem: Seemingly out of the blue, the Web Compiler stops working. It throws an error of "Access to the path 7z.dll is denied." In my case, I had been using it to compile SCSS files successfully for months.

Fix:

If this fixes it for you, please (1) comment and (2) let us know if you ended up having a compilation error in one of your files that may have caused the root problem. I personally did (an rgba attribute with no alpha supplied, ala rgba(10,10,10)).

Frustrating red herrings:

macux commented 5 years ago

@mgandley just had this issue and saving an scss file caused an error:

System.NullReferenceException: Object reference not set to an instance of an object. at WebCompilerVsix.Listeners.SourceFileCreationListener.DocumentSaved

(From Visual Studio Activity Log).

Running the compilation from the task runner worked (previously it was also failing) after which simply saving the file again worked. There was no invalid sass or css at any point.

fizgig commented 5 years ago

mgandley's fix worked for me, thanks for that.

chrissainty commented 5 years ago

@mgandley's fix worked for me as well.

zdarovka commented 5 years ago

Try to run VS as Administrator, that works for me

SheepReaper commented 5 years ago

@mgandley fix worked a few times for me, however, today it doesn't want to work. the ACL on 7z.dll is Full Control both for myself and SYSTEM and still access denied. Subsequently running VS admin does indeed allow it to work, but this should not be. I could see how this might be a problem for CI as well.

VS: 16.2.0 Preview 3.0 WebCompiler: 1.12.394

mitchelsellers commented 5 years ago

I have had this issue a few times today myself, but was able to use @mgandley fix

brantburnett commented 5 years ago

This fix worked for me as well. As to the root cause, I believe it was because I installed the extension and then opened two copies of Visual Studio simultaneously, which caused a fight over files in the temporary folder.

RayChungTW commented 5 years ago

@mgandley's fix worked for me.

hfloyd commented 4 years ago

@mgandley : your fix didn't completely work for me :-(

I was able to locate the folder, clear it out, and run the "prepare.cmd" batch script. It resulted in a "node_modules" folder with 432 subfolders, so I assume it worked fine.

I am running VS as an Admin, but when I save a scss file, nothing happens. I can right-click and choose "Web Compiler > Recompile file", but I was hoping to have it automatically work anytime any sass file was saved.

(The desire for aut-compile is what lead me to this post from https://stackoverflow.com/questions/39287333/web-compiler-compile-on-save-not-working)

WebCompiler1.4.167 Microsoft Visual Studio Community 2019 Preview - Version 16.4.0 Preview 6.0

mairaw commented 3 years ago

Maybe something change on the workaround process?

I got this error today and managed to get rid of the error message. There was no prepare.cmd batch script though. So I tried to rebuild the project twice (the first time, it didn't seem to recreate the Webcompiler subfolder and that worked out on a subsequent try). I guess now the node_modules subfolder comes expanded already.

mattkemp commented 3 years ago

I got this and mgandley's fix didn't work for me. I already open VS/projects as Administrator.

VS2019 16.9.2 WebCompiler 1.12.394

But I just updated the permissions on the C:\Users\{username}\AppData\Local\Temp\WebCompiler1.12.394\7z.dll file to Everyone and Full and haven't had a problem since.

mattkemp commented 3 years ago

Just got the error again today, came on here to say my fix didn't work, but found there was a new folder WebCompiler1.12.405 because it must have updated to a new version. Set the permission to Everyone again and got a new error "Access to the path 'fill.js' is denied" followed by the usual "7z.dll" error.

It's a shame the new version didn't fix this problem.

This is too much of a showstopper to put up with any more, I use Gulp in other projects so will just switch to that. Which sucks because WebCompiler was a super simple tool but if it does this all the time it's just not worth it.

cpboyd commented 3 years ago

I also got this bug and noticed a WebCompiler1.12.405 folder, but after deleting both I only have WebCompiler1.12.394 which appears to be the current published version and all is working again.

v-karbovnichy commented 3 years ago

Continuous Integration-specific fix:

I was getting this error on Jenkins agent, and also several others in random occurrence. Installing 7Zip globally and adding ACLs to it did not work. Adding Full access to Everyone to the AppData\Temp\WebCompiler1.12.394 folder and its contents did not work. I thought that MSBuild can run several builds in the solution in parallel, so decreased the number of its processes to 1 instead of equal to CPU count via a command-line switch: -maxcpucount:1 or -m:1 That worked. Here is the reference: https://docs.microsoft.com/en-us/visualstudio/msbuild/building-multiple-projects-in-parallel-with-msbuild

SheepReaper commented 3 years ago

I see a lot of unique users on this issue, but only 13 upvotes on the OP. Make sure you've upvoted the OP, I suspect M$ uses that to gauge heat. I've experienced similar with other issues now that UserVoice is dead and GitHub seems the only place now.

jachin84 commented 3 years ago

My team has been able to isolate what causes this issues. If you have multiple projects that reference WebCompiler that are built as a group and you run parallel builds there is a chance more that 1 process will try to write/delete 7z.dll or associated files.

@madskristensen Is there any way to have the following code only execute as part of NuGet Restore? https://github.com/madskristensen/WebCompiler/blob/c01fbbf785ea16a9b8784b1697e3095c3ffd0596/src/WebCompiler/Compile/CompilerService.cs#L93-L107

dezared commented 3 years ago

There was the same problem, I tried to recompile one of the files, the installation of updates for WebComplier started, now everything works.

MSIPhil commented 2 years ago

@mgandley I think the biggest fix for me was "Execute the prepare.cmd batch script and prepare to wait for 10 minutes while it unzips a full node_modules directory." I had uninstalled node and then installed it.

ArthurHenriqueDalosto commented 2 years ago

I've had this same problem a few times, and it was very painful to track down and fix each time. So, here's my write-up on how I fixed it - hopefully it saves some of you some time.

Problem: Seemingly out of the blue, the Web Compiler stops working. It throws an error of "Access to the path 7z.dll is denied." In my case, I had been using it to compile SCSS files successfully for months.

Fix:

  • Exit Visual Studio entirely.
  • Open C:\Users\%username%\AppData\Local\Temp
  • Find the WebCompiler subfolder for your version and delete it
  • Reopen Visual Studio. This should recreate the WebCompiler subfolder.
  • Open the WebCompiler subfolder
  • Execute the prepare.cmd batch script and prepare to wait for 10 minutes while it unzips a full node_modules directory.
  • Once this is done, you should be all set. Try saving a file.

If this fixes it for you, please (1) comment and (2) let us know if you ended up having a compilation error in one of your files that may have caused the root problem. I personally did (an rgba attribute with no alpha supplied, ala rgba(10,10,10)).

Frustrating red herrings:

  • The folder contains a console version of 7 zip, but the task runner may not have permissions to execute in your local user task directory. This might be the source of the failure.
  • The prepare.cmd batch file deletes itself, the 7z.exe, and the node_modules.7z files once it completes, making it way harder to figure out what is happening. If it deletes these without succeeding you're up a creek until you clear out the temp folder.

This work to me, thank you!

aa-ferret-aa commented 10 months ago

If 7z.exe and 7z.dll are being executed from inside "C:\Users%username%\AppData\Local\Temp" then AV software may prevent access to the binaries. This is to block malware executing droppers. Temp is really only for temporary files not for binaries to execute inside. Perhaps when it occurs check the AV logs or modify the relevant scripts to refer to a permanent "tools" folder for the binaries that is outside the temp folder.