File lock on LibSassHost.Native-64.dll about libsasshost HOT 11 CLOSED

Hello, Magnus!

This is not due to leaks. Just the native assembly continues to be used by the process. In principle, updating of native assemblies always require an restart of IIS or application pool.

from libsasshost.

I know this is closed but I had the same issue and just wanted to post my resolution. Add a dependency to LibSassHost.Native.XXX and compile. Grab libsass.dll from your bin folder and copy to C:\inetpub\dependencies, or some other folder. Remove the NuGet dependency on the LibSassHost.Native.XXXX project so your project no longer tries to copy libsass.dll when it's deployed. Then add c:\inetpub\dependencies (or wherever you placed the libsass.dll file) to your system path. Restart IIS so it recognizes the path change. When your website needs libsass.dll and IIS can't find it in your project folder it'll start walking the path to find it and will find it in your dependencies folder. This will allow your website to load it, but won't require it be deleted for webdeploy to deploy a new version of your website.

from libsasshost.

@ItWorksOnMyMachine Do you need to restart IIS, when you replace a libsass.dll in the c:\inetpub\dependencies directory?

from libsasshost.

@Taritsyn, you will need to stop/start the website to replace it, just like you would were the DLL in the website's bin folder. But you don't need to replace libsass.dll often. Certainly not as often as updating the website code itself..

from libsasshost.

@ItWorksOnMyMachine, @Taritsyn - I'm finding there's a problem with using this library in conjunction with an app that auto-deploys on AZURE

2017-10-31T21:30:48.1108017Z Info: Updating file (mysite-techrefresh\bin\x64\libsass.dll).
2017-10-31T21:30:48.1108017Z Info: Updating file (mysite-techrefresh\bin\x86\libsass.dll).
2017-10-31T21:31:47.9081187Z ##[error]Failed to deploy App Service.
2017-10-31T21:31:47.9091186Z ##[error]Error Code: ERROR_FILE_IN_USE
2017-10-31T21:31:47.9091186Z More Information: Web Deploy cannot modify the file 'libsass.dll' on the destination because it is locked by an external process.  In order to allow the publish operation to succeed, you may need to either restart your application to release the lock, or use the AppOffline rule handler for .Net applications on your next publish attempt.  Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_FILE_IN_USE.
2017-10-31T21:31:47.9091186Z Error count: 1.
2017-10-31T21:31:47.9091186Z 

where do the LIBSASS dlls come from?

https://github.com/sass/libsass-net ?
https://github.com/sass/libsass ?

I'm wondering if I dig around in the source for the DLL you're wrapping if I could find a place where a file-handle is left open.

from libsasshost.

Hello, Alex!

Solution of problem is described in your error message:

In order to allow the publish operation to succeed, you may need to either restart your
application to release the lock, or use the AppOffline rule handler for .Net applications
on your next publish attempt.
Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_FILE_IN_USE.

where do the LIBSASS dlls come from?

https://github.com/sass/libsass-net ?
https://github.com/sass/libsass ?

This question only says, that you did not even look to the documentation. Prior to version 1.X, libsass.dll's were included in the LibSassHost package. Since version 1.X libsass.dll's were moved to separate packages: LibSassHost.Native.win-x86 and LibSassHost.Native.win-x64. In addition, LibSassHost uses a modified version of the LibSass library.

I'm wondering if I dig around in the source for the DLL you're wrapping if I could find a place where a file-handle is left open.

Do you understand what is a P/Invoke?

from libsasshost.

Unless Azure deployment now offers an option to stop the website before deployment, you won't be able to use this in Azure. Libsass is locked by the IIS Worker Process (w3wp.exe) and only stopping the website's app pool will release it. I would actually recommend that you start doing a design-time or compile-time sass transpilation. Mads Kristensen has a nice VS Extension called Web Compiler you can use. Although, I'd recommend moving to a nodejs/npm solution that uses gulp-sass. You can add a post build/pre-deploy event to your project file that will execute npm install and then npm run with a custom script that will compile your scss files. This is the solution I use now.

from libsasshost.

Hi @Taritsyn thanks for the response. I appreciate that it looks like I might not have read the error message but I promise I did.

I tried the things offered in threads from stack overflow and another GitHub repo.

None of the azure interface options I found actually work. This includes checking the "take app offline" checkbox and "adding retries in the msbuild command line options"

The next level of feedback on those threads suggest adding a custom Powershell script to azure deployment.

As I'm delivering code to an Enterprise client into their environment and (azure) build system I anticipate reluctance to grant me permission to implement that (or even outright refusal based on enterprise security concerns.)

That made it seem "easier" from my point of view to try and fix the underlying issue and contribute back the community. I certainly see others have had the problem.

I've experienced a similar DLL locking issue with something that reads files where the developer forgot to call File.Close() .. it may be wishful thinking, but I'm hoping it is something similar here.

Do I have the right source on the libsass DLL binaries that you're including in your package?

edit: and sorry - no I don't know what P/Invoke is right now but I'll google around for it.

OK - have read a little on P/Invoke - so you're saying that the "standard" for using P/Invoke Dlls is to leave them open/locked? And it isn't likely to be a "dangling" file.close but is actually a function of the fact that you're using a p/invoke DLL.

@ItWorksOnMyMachine I'm not allowed by the client's enterprise security policies to add node dependencies to build - although I can check in the compiled CSS to the code we release, I was hoping to get away from that for 'cleanliness' sake. For pragmatic reasons that may be where I have to end up.

from libsasshost.

Do I have the right source on the libsass DLL binaries that you're including in your package?

I already wrote about this: “In addition, LibSassHost uses a modified version of the LibSass library.”.

I've experienced a similar DLL locking issue with something that reads files where the developer forgot to call File.Close() .. it may be wishful thinking, but I'm hoping it is something similar here.
…
And it isn't likely to be a "dangling" file.close but is actually a function of the fact that you're using a p/invoke DLL.

I think, that it is possible to complete the discussion, because you have already been given the right answer: “Libsass is locked by the IIS Worker Process (w3wp.exe) and only stopping the website's app pool will release it.”.

from libsasshost.

OK - thanks for your time @Taritsyn, @ItWorksOnMyMachine sorry if my questions caused frustration.

edit: suggested fix didn't work. deleted bad suggestion

from libsasshost.

That package allows for a MSDEPLOY / AZURE deployment without requiring app pool reset. I can't say that the implementation is as performant as using the native DLL but the CSS produced does seem to be identical in my case.

Very happy for you. When you first deploy any similar library, you will have no problems, but they will occur when you upgrade to a newer version. I recommend you to read the “w3wp.exe locks 'libsass*.dll'” discussion.

from libsasshost.