I'm using Hudson as a continuous integration server. The jobs ultimately kick off MSBuild. Everyone once in a while, my build fails with a non-code-compilation error out of MSBuild:
C:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets(2703,9): error MSB3021: Unable to copy file "..\Lib\Microsoft\Microsoft.Practices.Unity.Configuration.dll" to "bin\Debug\Microsoft.Practices.Unity.Configuration.dll". Access to the path 'bin\Debug\Microsoft.Practices.Unity.Configuration.dll' is denied.
When I examine 'bin\Debug\Microsoft.Practices.Unity.Configuration.dll', I find it to be a 0-byte file.
I'm at a loss for why this file is being problematic. Any ideas?
MS Build Copy task has undocumented feature, at least Google keeps silence.
If set system wide environment variable MSBUILDALWAYSRETRY=1
This task will retry to copy a file even it gets Access Denied exception during copy operation
Example of output
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets (3513): Got System.UnauthorizedAccessException: Access to the path 'C:\Builds\8\28\Binaries\Release\fr\System.Spatial.resources.dll' is denied.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.File.InternalCopy(String sourceFileName, String destFileName, Boolean overwrite, Boolean checkHost)
at System.IO.File.Copy(String sourceFileName, String destFileName, Boolean overwrite)
at Microsoft.Build.Tasks.Copy.CopyFileWithLogging(FileState sourceFileState, FileState destinationFileState)
at Microsoft.Build.Tasks.Copy.DoCopyWithRetries(FileState sourceFileState, FileState destinationFileState, CopyFileWithState copyFile) copying C:\Builds\8\28\Sources\Main\Solutions\packages\System.Spatial.5.2.0\lib
et40\fr\System.Spatial.resources.dll to C:\Builds\8\28\Binaries\Release\fr\System.Spatial.resources.dll and HR is -2147024891
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets (3513): Retrying on ERROR_ACCESS_DENIED because MSBUILDALWAYSRETRY = 1
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets (3513): Could not copy "C:\Builds\8\28\Sources\Main\Solutions\packages\System.Spatial.5.2.0\lib
et40\fr\System.Spatial.resources.dll" to "C:\Builds\8\28\Binaries\Release\fr\System.Spatial.resources.dll". Beginning retry 1 in 1000ms. Access to the path 'C:\Builds\8\28\Binaries\Release\fr\System.Spatial.resources.dll' is denied.
Sounds like a process is holding bin\Debug\Microsoft.Practices.Unity.Configuration.dll open.
You can check that earlier by renaming 'bin' to something else, like 'bin-old' and then removing 'bin-old' If any process is holding the files in 'bin' open, the rename will fail.
Use Handle.exe from SysInternals (Microsoft) to see which files are being held open by which processes.
Run this at a cmd prompt when you get the error;
Handle.exe > OpenFile.txt
Notepad.exe OpenFile.txt
Then search OpenFile.txt for the file that is locked and you'll see the process.
Ryan
See also http://blogs.msdn.com/aaronhallberg/archive/2007/10/22/error-msb3021-and-team-build.aspx and MSBuild & TeamBuild - BuildInParallel failing because of MSB3021 file permission violation
Related
I have a directory in remote Linux machine where files are being archived and kept for a certain period of time. I want to delete a file from remote (Linux) machine using kettle transformation based on some condition.
If file does not exists then job should not throw any error but if file exists at remote location, then job should delete file or raise an error in case some other reason, i.e., permission issue.
Here, the file name will be retrieved as a variable from previous steps of transformation and directory path of archived files will be fixed one.
How can I achieve this in Pentaho Kettle transformation?
Make use of "Run SSH commands" utility to pass commands to your remote server.
Assuming you do a rm -f /path/file it won't error for a non-existent file.
You can capture the output and perform an error handling as well (Filter rows and trigger the course of action).
Or you can mount remote directory to machine where kettle is, and try to delete file as regular.
Using ssh, i think, non trivial. It needs a lots of experiments to find out error types, to find way to distinguish errors. It might be and error with ssh connection or error to delete file.
I'm trying to publish a relatively new ASP.NET site to azure appservice from Visual Studio.
I'm getting the following error message during the preview:
The "Dnu" task failed unexpectedly.
System.Exception:
Microsoft .NET Development Utility Clr-x86-1.0.0-rc1-16231
Copying to output path C:\Users*****\AppData\Local\Temp\PublishTemp*****************.********.WebApi114
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.
at Microsoft.DNX.Tasks.Dnu.Execute()
at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
at Microsoft.Build.BackEnd.TaskBuilder.d__26.MoveNext()
Path is long indeed. How do I fix it?
Error is from windows file API, not control by Azure App Service. Sadly I think you will have to find a way to shorter your file path in order to fix this issue.
I was running into the same issue trying to build an Angular2 app locally. So I tend to agree with Xiaomin that it may be a local issue. What worked for me was to run the dnu publish command from a command prompt with the output flag set with a shorter folder destination provided. For example, navigate to the location of the project you want to publish in a command prompt and type:
"dnu publish --runtime active -o c:\Sample"
The above command will post your output to c:\Sample.
You can interrogate the options as follows:
"dnu -help"
"dnu publish -help"
By default TFS Build creates a "Index Sources & Publish Symbols" step in a Visual Studio Build definition. When the step's property "Path to publish symbols" is empty, everything works fine. But when setting the path to a local directory, the step generates the following error:
2015-09-25T11:00:09.7991491Z Executing the powershell script: C:\NewAgent\tasks\PublishSymbols\1.0.4\PublishSymbols.ps1
2015-09-25T11:00:10.0022755Z Find-Files -SearchPattern **\bin\**\*.pdb -RootFolder C:\NewAgent\_work\990dcb3f\Projects
2015-09-25T11:00:10.0491548Z Found 15 files to index...
2015-09-25T11:00:10.0491548Z Invoke-IndexSources -RepositoryEndpoint <repositoryEndpoint> -SourceFolder C:\NewAgent\_work\990dcb3f\Projects -PdbFiles <pdbFiles>
2015-09-25T11:00:10.6272794Z Invoke-PublishSymbols -PdbFiles <pdbFiles> -Share C:\DebugSymbols -Product EntityMapper -Version 20150925.14 -MaximumWaitTime 7200000 -MaximumSemaphoreAge 1440 -ArtifactName
2015-09-25T11:00:10.7348541Z ##[error]Can't infer artifact type from artifact location C:\DebugSymbols.
2015-09-25T11:00:10.7504779Z
2015-09-25T11:00:10.7504779Z Start: AssociateArtifact
2015-09-25T11:00:10.7504779Z ##[error]Artifact Type is required.
2015-09-25T11:00:10.7504779Z End: AssociateArtifact
The pdb files are published to the specified directory, so i don't really understand what is causing the error (which then causes the whole build job to fail).
When the step's property "Path to publish symbols" is empty, everything works fine.
Yes, because if symbols path is not set, the script only index sources, not publishing symbols.
But when setting the path to a local directory, the step generates the error
You need prepare your symbol store. In your case setup folder sharing and permissions.
In my case changing the "Path to publish symbols" from
//myserver/symbols
to
\\myserver\symbols
solved the issue. Don't know why this happend to me but ok... :)
I'm trying to deploy a package with WebDeploy V3.
The installation process is to sync between a source folder to a destination folder on the remote computer and run a certain powershell script after the sync is done.
The command being executed is:
'"C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe" -verb:sync -source:dirPath='C:\source' -dest:dirPath='D:\destination',computerName=XXX -postSync:runcommand='powershell -inputformat none D:\destination\Install.ps1',successReturnCodes=0'
This yields the following error:
Info: Using ID '49edd786-d8a0-4acf-be7b-95dd6e1391cc' for connections to the remote server. Performing '-postSync'... Info:
Using ID '5ef9d005-82fa-4811-9f51-1741c8d622de' for connections to the remote server.
Info: Adding MSDeploy.runCommand (MSDeploy.runCommand).
Error: (11/28/2012 4:34:24 AM) An error occurred when the request was processed on the remote computer. Error: The entry type 'Unknown' was not expected at this time. The serialization stream may be corrupted.
Error count: 1.
Error during '-postSync'. Total changes: 0 (0 added, 0 deleted, 0 updated, 0 parameters changed, 0 bytes copied)
Searching the net for this error, I didn't see anybody who encountered it when using runcommand provider. If anybody encountered a similar issue and has ideas or suggestions I would be most thankful..
From what I've seen, using runCommand to execute an arbitrary command line might be a bit buggy. Try moving the commandline into a bat or cmd file and providing a (full?) path to that. The file will be uploaded and executed, as long as you don't try to pass in any arguments to it.
For future viewers of this post: I encountered this same specific error (Error: The entry type 'Unknown' was not expected at this time. The serialization stream may be corrupted) after adding runCommand provider usage to my MyProject.wpp.targets file for the Web Publishing Pipeline MSBuild process. The path was direct cmd shell input used in order to clear readonly flags with attrib -R.
In my case, my build server was configured with WebDeploy 3.0, while the server targeted by the deployment package was configured with Webdeploy 2.0. After upgrading the target server to Webdeploy 3.0 this particular problem was resolved.
However due to other errors surrounding runCommand (providing the correct path to the destination executable at package runtime) my solution still doesn't work entirely so take this all with a grain of salt.
I have read numerous MSBuild posts, but none seem to refer to a strange problem I am having.
In MSBuild.xml (.NET 3.5) I have the following:
<ItemGroup>
<JavaScriptFiles Include="..\js\jquery.translator-ms-1.0.0-debug-all.js" />
</ItemGroup>
I receive an error:
Error 188 Failed to read in the data for the path/file [..\js\jquery.translator-ms-1.0.0-debug-all.js]. The most common cause for this is because the path is incorrect or the file name is incorrect ... so please check your path and file names.
However, if I use a file in the very same folder as follows with like properties:
The build completes successfully.
Does anyone know the "uncommon" causes for this error?
Possible reasons for being unable to open and/or read a file:
It doesn't exist.
It is open in another process (either for exclusive access, or it's locked).
You don't have NTFS permissions.
You want write access but the file has the read-only attribute.
The combined length of the path and (your quite long) filename exceeds MAX_PATH (260) characters.
The file is on a remote server and there's a network problem.
You've run out of kernel resources (e.g. too many files or handles in general open). This is quite unlikely.
You have a physical disk error.
It turns out that having the "debugger" statement within this JavaScript file was the "uncommon" error in this case.