I am unable to publish a project to Azure from Visual Studio. I am running into an issue because I am getting the following error:
The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
I have already tried many common solutions. The problem arises in the temporary directory location, but I have shortened this. The directory that is too long is b:\test\WebSitePublish\WebProject-1309592107\obj\Debug\Package\PackageTmp\node_modules\grunt-bower\node_modules\bower\node_modules\request\node_modules\form-data\node_modules\combined-stream\node_modules\delayed-stream\test\integration\test-delayed-http-upload.js, starting with a short directroy name.
I have also tried installing npm install -g flatten-packages but get the same error.
How can I make this project push?
Related
I am using the command: dotnet "myfile.dll"
Initially it was giving me this error: The user's home directory could not be determined. Set the 'DOTNET_CLI_HOME' environment variable to specify the directory to use.
Now after messing around with it, I have moved my files to c:/mydir, and it is giving this error: Failed to initialize CoreCLR, HRESULT: 0x80070057. I found this, but isn't c:/mydir a drive root?
Couple of things I noted:
I am able to run the .dll fine in a different directory.
Both directories contain same files.
The reason I want to run it in c:/mydir is because I am using AWS CodeDeploy, and that is where it copies the files (as far as I know; and the other directories are just the old versions where the files get copied from).
These issues are not linked (the first one I get from running a automated shell script after installation, and the second I get from manually trying to launch the .dll).
If someone could help me solve either one of these issues it would be greatly appreciated.
Try adding Environment=DOTNET_CLI_HOME=/temp to your Service declaration in your .service file. Example syntax:
[Service]
...
Environment=VARNAME=VARCONTENTS
So the actual like would look like this
Environment=DOTNET_CLI_HOME=/temp
Explanation :
There are about 15 subfolders in the node_modules directory. When going to perform any operation (deleted, moved or renamed) it popup below message.
Error message:
The source file name(s) are larger than is supported by the file
system. Try moving to a location which has a shorter path name, or try
renaming to shorter name(s) before attempting this operation.
Screenshot :
sub folder inside npm_modules directory.
node_modules\gulp-connect\node_modules\gulp-util\node_modules\dateformat\node_modules\meow\node_modules\normalize-package-data\node_modules\validate-npm-package-license\node_modules\spdx-expression-parse\node_modules\spdx-license-ids\spdx-license-ids.json
Tried so far:
I also tried to delete the folder (node_modules) using command prompt using command rmdir <dirname> /S but did not work as well.
There is a way to do this is that go into subfolder after subfolder, renaming each folder to something short like 'b'. Eventually the path is short enough to allow deletion. This will waste quite a bit of time.
Is there any efficient way to delete this node_modules directory?
Newest versions of npm fix this issue flattening the path: https://github.com/npm/npm/issues/3697.
Try
D:\vms\fe> robocopy d:\path\to\temp\dir node_modules /purge
to remove the nested dirs.
Update
As pointed by Coding Professor, another option is use rimraf util (which basically calls rm -rf):
> npm install -g rimraf
> rimraf node_modules
For the record, and because of the release of a newish open-source project released by Microsoft, you can easily delete paths that are too long using WinFile (which was introduced in WinXP).
Sometimes you have to go "Back to the Future". This can delete paths too long on Microsoft networks share as well.
WinFile (compiled for Win10) available here https://github.com/Microsoft/winfile
To find many paths that are too long and automate a fix, I recommend Path Too Long Auto Fixer - a free demo is available.
I upgraded Visual Studio to VS Professional 2012.
Building old Visual C++ projects resulted in the error:
LINK : fatal error LNK1158: cannot run 'mt.exe'
Putting the folder with mt.exe into the path did not help.
Currently I am using mt.exe in the folder C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Bin\x64
Set "Generate manifest" as No in Linker. This helped
As mentioned at fatal error LNK1158: cannot run 'mt.exe', there are times where turning off manifest generation is not an option, because one is actually using manifests.
At which point, one comes back to fixing the actual problem.
One cause of the actual problem is a bad executable search path.
I personally once had a setting for $(ExecutablePath) in the project file (VC++ Directories → Executable directories in the project settings) that was yielding an executable search path one of whose pathnames wasn't a valid directory name.
The pathname had a colon in one of its directory name components (caused by prefixing ..\..\ to another variable, which happened to contain an absolute pathname with a drive letter, rather than a relative pathname as expected).
In a sensible world, errors in path searches caused by merely bad/missing directories cause the pathname to just get skipped over, and the search to proceed to the next pathname in the search path.
link, in contrast, fails with this error (as indeed does midl when it tries to find cl.exe).
This is very confusing when one looks at the search path (with the build output level set to "detailed") and sees that the SDK directory containing mt.exe is right there in it, plain as day.
It seems that link does not live in a sensible world. ☺
The fix was to correct the bad project setting, of course.
I am trying to publish a project to Windows Azure but get an error in the generated Microsoft.WindowsAzure.targets file related to length of paths and file names. How can I determine which is the problematic path or filename. The error relates to the "" tag in the generated file
Thanks
Martin
Already an older post - did you check this post?
Path too long error when building a windows azure service
This might reslove your issue.
Since this was still a problem for me years later and the above doesn't apply to Azure SDK v2.8, I was able to solve it by creating a symbolic link to my projects folder. Open up the command prompt as an administrator and run this:
mklink /D C:\Dev C:\Users\danzo\Source\Workspaces
Obviously you can change "C:\Dev" to whatever you want it to be and you'll need to change the longer path above to the root directory of your soltions/projects folder.
While running a script to create an NSIS installer, I'm getting an error I can't figure out. The script copies the files needed to create the installer, and then calls makensis to build the setup.exe.
During the compilation with makensis, I get an error while trying to include a directory structure that was copied before makensis was called.
The error is: File: failed opening file "..\..\..\My\Long\Path\Name\To\File.ext"
It fails reliably on a specific file that is 5 directories deep from the File /r command used to include the directory structure. The total path length is 180 characters, so it is not insanely long.
This error persists even after reboots or deleting and recreating the entire directory structure. To make it even worse, it works fine on another machine.
I've used Process Monitor to watch the usage of the files in the directory, and there isn't anything that is opening the file after the copy completes.
Any idea how to solve this problem?
The complete path (Current directory + relative path) has to be < 260 characters.
Are you sure your Process Monitor filters are correct, there should be some type of action taken that then fails? The "File: failed opening file" message is printed if CreateFile fails...
I was getting the same error and the complete path was < 260 characters.
Problem
File: failed opening file "\FOLDERSHARE\XYZSRelease\XYZV1.2.2\AutoCompleteMenu.dll"
Error in script "C:\TFS\XYZProject\Releases\NullsoftInstaller\XYZWin7Installer.nsi" on line 77 -- aborting creation process
Cause
For some reason when the files are on a Folder Share it doesn't work (I am positive this is a change to the corporate network environment) as it previously was working.
Solution
Put all the files in C:\Temp or another local directory.