I am trying to publish a project in Visual Studio 2013 that has some files with very long names, including the path location. I moved the project to a location closer to my root C:\ drive, which allows it to compile, but when publishing, it tries to copy files to the %appdata% folder which results in a name over the limit.
Here is the error I get:
Error 10 Copying file node_modules\grunt-bower\node_modules\bower\node_modules\bower-registry-client\node_modules\bower-config\node_modules\optimist\node_modules\minimist\.travis.yml to C:\Users\jake\AppData\Local\Temp\WebSitePublish\WebProject--1320288221\obj\Debug\Package\PackageTmp\node_modules\grunt-bower\node_modules\bower\node_modules\bower-registry-client\node_modules\bower-config\node_modules\optimist\node_modules\minimist\.travis.yml failed. 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. 0 0 WebProject
Is there a way to either adjust this project's name or where it copies to temporarily so that I am able to publish from Visual Studio?
Citing #Britton from Temp path too long when publishing a web site project:
Add this to your publish profile to modify the temporary directory for
package/publish:
<AspnetCompileMergeIntermediateOutputPath>c:\shortPath\</AspnetCompileMergeIntermediateOutputPath>
Or according to Website publish failing due to file path being too long (citing #Jason Beck and #VeeKayBee):
Add the following line in default PropertyGroup of web project file:
<IntermediateOutputPath>..\Temp</IntermediateOutputPath>
In addition to Amnon Shochot's answer, above, I also had to apply Roland's answer from another thread.
My publish paths (in .pubxml) now look like this:
<publishUrl>c:\publish\proj\</publishUrl>
<IntermediateOutputPath>c:\publish\inter\</IntermediateOutputPath>
<_PackageTempDir>c:\publish\package</_PackageTempDir>
You have to be careful with this:
Important: If this option is set, be sure not to nest your temporary files inside the publishUrl directory, because it will wipe out the _PackageTempDir files, causing a failed publish, even if it appears successful.
Related
I'm converting a premake4 config to premake5. My prebuildcommands are failing because the commands are executed from the root working directory, not the directory that the premake5.lua is in that contains the 'prebuildcommands'. premake4 executed them in the subdirectory containing the prebuildcommands call.
Is this the new intended behavior? If so, it's not documented anywhere that I can find. I don't mind correcting the paths as long as it's not an bug.
This looks like the correct behavior to me. Premake doesn't attempt to parse the commands to identify paths, so they are left intact as entered. The command itself is executed by the build tool (Visual Studio, GMake, etc.) and so will operate in whatever directory the tool makes current at that time.
If I'm reading it right, you would like the command to execute in the project directory, so what about:
prebuildcommands {
"%{prj.location}/styx/utils/ndate > %{prj.location}/include/kerndate.h"
}
For Visual Studio, Premake will convert those tokens to $(ProjectDir) so they will stay relative to the generated project file.
If I have multiple binaries whose sources are scattered in various subfolders of an overlaying folder, would windbg have access to them if only the topmost folder was included in Source Path? As opposed to having to reference each project folder of each relevant binary separately.
Assuming, of course, that the sources are unique in the mentioned folder structure, i.e. there are no multiple versions of one and the same project, source, etc.
If you specify the parent folder for the source files in source path then it should traverse through the subdirectories to find the source files.
Note that it will perform a signature match against your source files, in the same way that Visual studio will complain that the source files are different to the loaded dlls.
The relative locations of the source files must match the original locations so if your source files are located in a different structure then you will need to do a manual load/browse to specify the location of the source files.
Can’t answer exactly, but I often have 3 top (parent) directories, and each have approximately 4-5 levels of sub directories. No problems. However nothing beats using a source server
Short answer: NO.
From windbg's help:
For each directory in the symbol path, the debugger looks in three
directories. For example, if the symbol path includes the c:\MyDir
directory, and the debugger is looking for symbol information for a
DLL, the debugger first looks in c:\MyDir\symbols\dll, then in
c:\MyDir\dll, and finally in c:\MyDir. The debugger then repeats this
process for each directory in the symbol path. Finally, the debugger
looks in the current directory and then in the current directory with
\dll appended to it. (The debugger appends dll, exe, or sys, depending
on which binaries it is debugging.)
You can move all projects' .pdb files to one folder or change projects properties and setup the linker to create the .pdb file in a specific folder so you have to reference only one.
I've been doing a bit of debugging on this myself. From what I can tell, the relative path of the file found from the SourcePath needs to match part of the end path of the path embedded in the PDB. For example:
I have a file on disk at:
C:\Users\User\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\std\src\sys\windows\thread_local_key.rs
The path of the file embedded in the PDB is:
/rustc/c09a9529c51cde41c1101e56049d418edb07bf71\/library\std\src\sys\windows\thread_local_key.rs
✔ This SourcePath, and any below it, correctly finds the file:
C:\Users\User\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\src\rust
❌ This SourcePath, and any above it, does not find the file:
C:\Users\User\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\src
Notice how with the failure case, the relative path to the file would begin with library\. The library path component is the first part of the path that is not found in the embedded path. I assume it does a path check for every relative address, recursively:
thread_local_key.rs
windows\thread_local_key.rs
sys\windows\thread_local_key.rs
src\sys\windows\thread_local_key.rs
std\src\sys\windows\thread_local_key.rs
library\std\src\sys\windows\thread_local_key.rs
etc.
I am trying to publish an ASP.NET web site project using the Publish Web Site tool but get this error:
ASPNETCOMPILER(0,0): Error ASPRUNTIME: 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 see that it is trying to copy the files to a very long path in AppData:
Copying all files to temporary location below for package/publish:
C:\Users\imx0\AppData\Local\Temp\1\WebSitePublish\BMW.Web-424993535\obj\Debug\AspnetCompileMerge\Source.
c:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler.exe -v /BMW.Web -p C:\Users\imx0\AppData\Local\Temp\1\WebSitePublish\BMW.Web-424993535\obj\Debug\AspnetCompileMerge\Source C:\Users\imx0\AppData\Local\Temp\1\WebSitePublish\BMW.Web-424993535\obj\Debug\AspnetCompileMerge\TempBuildDir
I couldn't find anything about this temp directory in my .pubxml publish profile. How can I change the temporary directory that Visual Studio copies the files to?
Add this to your publish profile to modify the temporary directory for package/publish:
<AspnetCompileMergeIntermediateOutputPath>c:\shortPath\</AspnetCompileMergeIntermediateOutputPath>
Go to your web project folder, navigate to Properties\PublishProfiles folder.
open your profile file profile_name.pubxml (not the profile_name.pubxml.user)
copy/past <AspnetCompileMergeIntermediateOutputPath>c:\shortPath\</AspnetCompileMergeIntermediateOutputPath> under the <PropertyGroup> tag
save your file, you would be able to publish your website using this profil
This is sort of an aside answer, but I ran into this problem when trying to MSBuild a solution that depended on nodeJS and gulp. The problem was that the gulp dependency tree became very deep and the aspnet_compiler was trying to copy that tree to a deeper directory, resulting in this error. I tried everything noted in here but nothing worked.
As it so happened, I was building with TFS, so my solution was to run an attrib +h node_modules\* /S /D before msbuild to hide the directory tree and then attrib +h node_modules\* /S /D. That did it for me.
Sure would be nice if the error thrown in this situation by the compiler revealed the path that caused the write to fail...
try adding this
<IntermediateOutputPath>..\Temp</IntermediateOutputPath>
to the default <propertyGroup />
None of the other answers worked for me.
Visual Studio 2013 Community Edition.
I changed the TMP and TEMP environment variable to a short folder name and it worked.
We identified the lengthy files/folders using this solution, then corrected the issue from there:
Run this script at the command prompt: dir /s /b | sort /r /+261 > out.txt it will output all file paths into the out.txt file
Copy the output to an Excel file
In the next column over from what you pasted in add this Excel function: =LEN(A1) where "A1" is the cell, copy this against every file length so you can see how long the paths are
Sort in Excel by the path length
Identify the lengths over the recommended limit
I know this is a bit long-winded but if you have several files that are resulting in this issue you'll be able to see them all.
Even though the content of node_modules was not included in neither version control not in the *.csprojfile itself Deleting the whole node_modules folder did the trick for me.
You can try the selected solution for correcting the long file path issue.
Still if not able to publish due to some other issue, You can try below method.
=> If the 'Solution Configuration' is in 'Debug' mode, please change the same to 'Release' mode and Publish the files.
=> If the Solution Configuration is in Release mode, and if the problem still persists, please try to delete the dll generated earlier in the 'Release' folder of our project and Publish the project once again.
Any of the above method will solve the issue.
For me, using Visual Studio 2019, the only change to the publish profile .pubxml file that worked was:
<WPPAllFilesInSingleFolder>c:\shortPath\</WPPAllFilesInSingleFolder>
I discovered this property at line 484 of Microsoft.Web.Publishing.targets file. Full path was C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Microsoft\VisualStudio\v16.0\Web.
Error 1 Copying file Content\themes\base\AdminHomeImages\GiftControl.jpg to obj\Debug\Package\PackageTmp\Content\themes\base\AdminHomeImages\GiftControl.jpg failed. Could not find file 'Content\themes\base\AdminHomeImages\GiftControl.jpg'. 0 0 ResturantManager
I get the above error while publishing MVC3 project.. What should i do to solve it.
When you choose to Publish the Project and Let's say your Publish Method is "File System" that means you are copying your necessary files from one location to another location. The Index of these files are mentioned in your project file. You have two options below
(a) Remove the Index of these files(Files causing Compilation Error) from your Project File and Publish
(b) It is must to keep the Project related Files to their exact location(Files that causing Compilation Error, Try keeping a fake file with same name and same Extension). This relative path is mentioned in your project file. Publish now
This Compilation Error will not be shown when you Rebuild/Build the application.
We are deploying a website to a DFS share. DFS creates shortcut files with the name .DFSFolderLink.lnk in various locations. Admins on the box do not have rights to delete this shortcut file. So if any exist I need to exclude them from deployment, so that they will not be deleted.
I can already exclude the .DFSFolderLink by passing -skip:File=.DFSFolderLink.lnk to msdeploy. However, if the directory that contains the shortcut file does not exist in the package being deployed, then an error is raised because it tries to delete the folder but cannot because the shortcut file still exists.
How can I get it to exclude the shortcut file and the directory that contains it without knowing ahead of time what the directory name is?
If you don't know the name of the directory, you can't skip it. What you can do is tell msdeploy to ignore the "directory not empty" error using the ignoreErrors provider setting:
msdeploy -verb:sync -source:... ^
-dest:auto,ignoreErrors=80070091,computerName=... ^
-skip:File=\.DFSFolderLink.lnk