I'm currently trying to publish my AWS lambda functions using Visual Studio 2019 community (v4.8.03752) and leveraging the AWS Toolkit for Visual Studio (v1.20.1.0). After right clicking my project and selecting 'Publish to AWS Lambda' I receive the following error:
- Zipping publish folder C:\Users\Matt\source\repos\programName\programName\.\bin\Release\netcoreapp3.1\publish to C:\Users\Matt\AppData\Local\Temp\HelloWorld-CodeUri-Or-ImageUri-637489827969959200.zip
- Failed to find the "build-lambda-zip" utility. This program is required to maintain Linux file permissions in the zip archive.
- Error packaging up project in C:\Users\Matt\source\repos\programName\programName\. for CloudFormation resource HelloWorld: Failed to find the "build-lambda-zip" utility. This program is required to maintain Linux file permissions in the zip archive.
I've been able to deploy this MANY times over previous months, up until Friday 2/12 when I started receiving this error (after a reboot). What's even more strange is that if I uninstall the AWS Toolkit for VS, then reinstall it, I'm able to publish successfully 1 time. With my 2nd attempt, I begin to receive this error again.
Steps I've taken to attempt to resolve:
Repair Visual Studio
Uninstall/Reinstall Visual Studio
Uninstall and reinstall amazon.lambda.tools using dotnet tool install -g Amazon.Lambda.Tools
Uninstall AWS Toolkit for VS, Reinstall toolkit. (This works for first deployment, fails when trying to deploy a 2nd time)
UPDATE:
Per some comments below, it looks like this is being caused by McAfee Real-Time Scanning. In checking the logs during a deployment I noticed a "Virus or threat found" record that points directly to the build-lambda-zip.exe file. To permanently avoid this issue moving forward please follow the steps provided by user2174794 in the comments below.
I'm having the same issue. Just started happening today. It was working within the last 2 weeks.
Failed to find the "build-lambda-zip" utility. This program is required to maintain Linux file permissions in the zip archive.
Running Windows 10, Visual Studio 2019
My solution for now is to use the .NET Core CLI
https://docs.aws.amazon.com/toolkit-for-visual-studio/latest/user-guide/lambda-cli-publish.html
Specifically, the
dotnet lambda deploy-function
A recent update must have broke the AWS Toolkit For Visual Studio.
I have the same problem, it was because my antivirus detect the executable build-lambda-zip.exe, then delete it.
I restore the executable from my antivirus, or restore dotnet tools with the command :
dotnet tool update -g Amazon.Lambda.Tools
I also faced the same issue,
This is because the "build-lambda-zip.exe" file is getting removed by the McAfee Antivirus.
For the permanent fix, you need to follow the below steps.
Step 1
Go to McAfee Settings >> Quarantined Items
You will find the "build-lambda-zip.exe" file there. Restore it to the original location.
Now If you will try to publish, the error won't get displayed. But again on the next scan, the file will get removed.
Step 2
We need to Exclude this file from getting Scanned and removed. So for that,
Go to McAfee Settings >> Real-Time Scanning and Add the "build-lambda-zip.exe" file in the Excluded files list.
For the file path of "build-lambda-zip.exe" got to
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\Extensions\ and search for the file name.
Maybe you should try reinstalling the AWS Tool Kit and before you make deployments please turn off your antivirus protection. I was troubbling the same issue and my antivirus(McAfee) was deleting build-lambda-zip.exe file when I did deployment first time.
I'm curious about the state of the extension installation. Can you go to VS's extension directory in Windows explorer C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\IDE\Extensions and in the search box search for AWSToolkitPackage.dll.
Ideally it should only show one instance of that file. Assuming it finds a single instance right click on the file and select "Open File Location". Now that you are in the root folder of the AWS extension check the Resources folder and see if it contains the file build-lambda-zip.exe.
I know the question is in a windows system, but under a linux system, in my case the following command was needed:
sudo apt-get -y install zip
Related
It worked for years.
Yesterday for no reason (?) I'm not able to compile LESS files any more.
I tried to
reinstall the Web Compiler extension,
reinstall Web Essentials 2019 extension,
reinstall the whole Visual Studio 2019 for 3 times,
start a new project from scratch
I do not know if some automatic update happened under the hoods, but basically, every time I try to compile a LESS file I get:
module.js:471
throw err;
^
Error: Cannot find module 'C:\Users\igor\AppData\Local\Temp\WebCompiler1.12.394\node_modules\less\bin\lessc'
at Function.Module._resolveFilename (module.js:469:15)
at Function.Module._load (module.js:417:25)
at Module.runMain (module.js:604:10)
at run (bootstrap_node.js:390:7)
at startup (bootstrap_node.js:150:9)
at bootstrap_node.js:505:3
Thanks for any help!
For VS2017 and VS2019:
Uninstall the Web Compiler extension
Delete* the directory C:\Users\<username>\AppData\Local\Temp\WebCompiler1.12.394
Install Web Compiler
I do not know why the "lessc" file disappeared.
* From cmd.exe:
rd /S %LOCALAPPDATA%\Temp\WebCompiler1.12.394
From a PowerShell prompt:
rm -r $env:LOCALAPPDATA\Temp\WebCompiler1.12.394
How I found the solution: I attempted to re-create the .vsix file from the GitHub repository for the Web Compiler extension so that I could get the lessc file; I had installed Node.js and all its associated gubbins. Trying to use the node_modules.7z generated by build.cmd in the Web Compiler files didn't work in the end because there are several deprecated things in it - I ended up with the error described in 3.10: Breaks IE Compat Option. So I thought: oh dear, it is all broken, why not just delete the directory and try the install again?
I deleted the C:\Users\<username>\AppData\Local\Temp\WebCompiler1.12.394 folder and ran the compilation from Task Runner Explorer which recreated the folder without having to reinstall Web Compiler.
Maybe it is related to also having the BuildWebCompiler 1.12.405 NuGet package installed in the project.
I was able to fix a similar problem with a "node-sass" file missing from the Web Compiler (although the entire bin folder was empty) by performing the following actions:
close Visual Studio 2019
delete the C:\Users<username>\AppData\Local\Temp\WebCompiler1.12.394 folder
restart Visual Studio.
When I restarted VS, the folder was recreated with all the necessary files back where they needed to be.
When I ran into the issue I had just came back to work after taking a little over a week off. At least for me, I think a program on my computer that automatically cleans up unused temp files may have been the culprit.
I am searching for a command that I can use in Elastic Beanstalk configuration file to install Visual C++ Redistributable for Visual Studio 2012 which I need for my web project to run.
I tried installing using msi which I built from the exe and put on S3 but it returned timeout:
The following instances have not responded in the allowed command timeout time (they might still finish eventually on their own)
And I still get the error:
Could not load file or assembly 'Magick.NET-x86.DLL' or one of its dependencies. The specified module could not be found.
Magick.NET needs the Visual C++ Redistributable for Visual Studio 2012 in order to run. Installing it manually is not an option as I need it pre-installed for auto scalability. Thanks.
Servers run on Windows Server 2012 / IIS8
I recently encountered the same problem. What I ended up doing was creating scripts that are bundled with the deployment that download the redistributable from my S3 store and then install on the server during deployment. Here is what I did:
Download the redistributable from http://www.microsoft.com/en-us/download/details.aspx?id=30679
Upload the redistributable to your S3 store and note the URL location.
In the .NET project, create a folder named .ebextensions at the
top level of the project (i.e., at the same level as the App_data,
App_Start, Content, etc. folders)
Create a file named myapp.config (replace myapp with whatever you like). I actually created two config files (myapp-1.config and myapp-2.config) because for whatever reason the deployer didn't like the commands in Step #5 to be in the same file (I'm still learning this so I most likely screwed something up, but this worked for me).
In the config file, place the following (files into myapp-1.config and commands into myapp-2.config):
files:
"c:\\somedirectoy\\vcredist_x64.exe":
source: https://s3.amazonaws.com/yours3location/2012vcredist_x64.exe
commands:
instlVC:
command: c:\\somedirectory\\vcredist_x64.exe /q /norestart
Now, when you deploy to the Elastic Beanstalk from Visual Studio 2012, the amazon deployment process will download the vcredist_x64.exe from S3 and then run the installer in quiet mode (no prompts, etc.).
Hopefully this helps and I welcome any improvements or suggestions on this approach.
I usually use the VS GUI for TFS and have never had any problem.
I am trying to get the command line working and am running TF from the root of the collection's mapped directory.
When I run TF Get <project name> /noprompt / recursive
I get the error message:
Unable to determine the workspace. You may be able to correct this by running 'tf workspaces /collection:TeamProjectCollectionUrl'.
I have run this but the error still exists.
When I run TF workspaces I have an entry for the computer I am on (the TFS source is on a different PC) and the collection path http://<comp name:port>/TFS/<project> which is correct.
Has anyone else been in this situation? The various pages I have found talking about it seem to stop after running the tf workspaces command. Has this always worked for everyone else? Perhaps I am just using it wrong?
You are getting this message because the TF get is being run outside of your workspace directory CD to the directory that contains the workspace that you need to work with first.
The commandline isn't asking for the TFS server uri, but for the ProjectCollection uri, so you need to add some extra information:
{https}://{tfsserver}:{port}/tfs/{collection}
Replace:
{https} make sure you use the right protocol, http or https.
{tfsserver} with the hostname of your tfs server
{port} with the port number (default: 8080 or 443)
{collection} with the project collection name (installation default: DefaultCollection)
The ProjectCollection isn't the same thing as the project, so make sure you're entering the correct values. Easiest place to find the collection name is to open Visual Studio and then the Source Control Explorer. The Uri for the project collection should be the root node. It might be that you're entering the Project name, instead of the ProjectCollection name.
If you're in a folder mapped to TFS, then tf get should figure the CollectionUri by itself.
When you have Visual Studio 2010 and 2012 or 2013 installed side-by-side, make sure you're using the Developer Command Prompt from the correct version of Visual Studio. With the advent of Local Workspaces, the 2010 commandline may not be able to find your mappings, where the 2012 or 2013 commandline will.
I fixed this problem by running tf using the "Visual Studio Command Prompt" (also known as the Developer Command Prompt) instead of running the default command prompt that comes with the operating system.
You can find it in Windows 7 under "Start -> All Programs -> Microsoft Visual Studio -> Visual Studio Tools -> Visual Studio Command Prompt".
You may find more documentation, including instructions for other versions of Windows, by visiting Microsoft's Visual Studio Command Prompt MSDN page.
I got this fixed with:
tf workspaces /collection:http://example:8080
tf workfold
tf get /r .
Every time I try to install (5 attempts) I get:
Error 2753. the File "agent.exe.6ED28686_7b19_420c_b255_5b6c1bd2c705" is not marked for installation
I've tried uninstalling, deleting the install folder after installing, clearing out temp files, restarting the machine and making sure I run the setup as administrator but I get this every time. I've even followed some advice about putting the installer files in c:\cr4vs2010 but to no avail.
The customer I'm developing for has Crystal skills so no other reporting engine will do.
EDIT
Found out about the FLEXnet transformer that fixes the above error. However, on completion of the install I get an error "The operation could not be completed" in a dialog box headed "Visual Studio".
I've fixed it I think. I now have Crystal Templates.
To fix.
Get the Flexera tool at
http://kb.flexerasoftware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=Q207355&sliceId=
Run the tool as instructed and install the two msi's using it. I did the VS install first, then the 64-bit runtime.
After getting the "The operation could not be completed" error and installing both msi's, open up the Visual Studio Command prompt, ensuring you elect to Run as Administrator.
execute the command line devenv /installvstemplates. This takes a few minutes.
That fixed it for me.
When I try to pack my MVC project (NuGet.exe pack) I get:
NuGet.exe : Access to the path '...' is denied.
This happens to be the case for all files in the content and script folder of my MVC solution. If I remove the readonly flag on all these files NuGet.exe is able to create the NuGet package.
Why do I have to remove the readonly flag? Is there another way?
I'm using TFS which specify the readonly flag on all files under source control.
I am running:
NuGet Version: 1.7.30402.9028
Microsoft Visual Studio 2010 Version 10.0.40219.1 SP1Rel
I'm using the NuGet.exe that you get when you install the NuGet package NuGet.CommandLine which is located at http://nuget.org/packages/NuGet.CommandLine.
Apparently, you need to set ReadOnly=false for the files it accesses
Try running it as administrator.
I ran into this with nuget restore after doing a git clean -fd with VisualStudio open: the packages/ directory was marked for deletion, and while several files were deleted, the packages/ folder itself was not as VisualStudio had the .nupkg files open.
Once I closed VisualStudio and re-ran git clean, it removed the packages/ directory and then nuget was able to restore everthing correctly.
In my case something happened when switching branch in git. Everyone lost execute permissions for Nuget.exe.
This blog post helped me: http://mannysiddiqui.wordpress.com/2013/05/11/nuget-access-is-denied-command-existed-with-code-5/
I was running into a similar problem. I attempted to restart Visual Studio, Run as Administrator (Which I always do), Set the folder attributes to ensure the 'Read-Only' flag was off. Regardless, whatever I did, I still encountered the error "access to the path is denied" when updating my Nu-Get packages.
I was able to fix the issue by updating packages one-by-one. Choosing instead to go through each dependency and updating it. Once the dependency was updated I would choose another, sometimes the same error resulted in which case I would choose another until all my packages were successfully updated.
It appears in my case the Nu-Get packages had to be updated in a particular order.
Hope this helps someone out there
I had this problem and it turned out windows had an update waiting for the next restart. Cleared with no problem after restarting and waiting for the update.
My collegue just got this error, during all "worked on my machine". After some research I found out that the *.nuspec file for some reason wasn't added to the version control.
In order to Restore nuget packages, remove read only permissions from the folder level (for windows). Clean the solution and Build. It will works
In my case it was *.gitattributes in the git repo root recently modified (incorrectly), so git started to checkout nuget.exe on the build server and converted all LF to CRLF inside, making it non-executable.
Run your Visual Studio with administrator rights.