I used tfs 2015 with update3. I have created tfs build definitions as below:
Artifact Type was 'file share'.
When the build started, I got the error:
2017-01-22T13:05:28.4826393Z shell.js: internal error 2017-01-22T13:05:28.4836396Z
RangeError: Maximum call stack size exceeded 2017-01-22T13:05:28.4836396Z at String.charCodeAt (native) 2017-01-22T13:05:28.4846392Z at Object.dirname (path.js:706:21) 2017-01-22T13:05:28.4846392Z at mkdirSyncRecursive (C:\Program Files\Microsoft Team Foundation Server
14.0\Build\tasks\PublishBuildArtifacts\1.0.28\node_modules\shelljs\src\mkdir.js:7:22) 2017-01-22T13:05:28.4856408Z at mkdirSyncRecursive (C:\Program Files\Microsoft Team Foundation Server
14.0\Build\tasks\PublishBuildArtifacts\1.0.28\node_modules\shelljs\src\mkdir.js:16:3) 2017-01-22T13:05:28.4866398Z at mkdirSyncRecursive (C:\Program Files\Microsoft Team Foundation Server
14.0\Build\tasks\PublishBuildArtifacts\1.0.28\node_modules\shelljs\src\mkdir.js:16:3) 2017-01-22T13:05:28.4866398Z at mkdirSyncRecursive (C:\Program Files\Microsoft Team Foundation Server
14.0\Build\tasks\PublishBuildArtifacts\1.0.28\node_modules\shelljs\src\mkdir.js:16:3) 2017-01-22T13:05:28.4876401Z at mkdirSyncRecursive (C:\Program Files\Microsoft Team Foundation Server
14.0\Build\tasks\PublishBuildArtifacts\1.0.28\node_modules\shelljs\src\mkdir.js:16:3) 2017-01-22T13:05:28.4876401Z at mkdirSyncRecursive (C:\Program Files\Microsoft Team Foundation Server
14.0\Build\tasks\PublishBuildArtifacts\1.0.28\node_modules\shelljs\src\mkdir.js:16:3) 2017-01-22T13:05:28.4886414Z at mkdirSyncRecursive (C:\Program Files\Microsoft Team Foundation Server
14.0\Build\tasks\PublishBuildArtifacts\1.0.28\node_modules\shelljs\src\mkdir.js:16:3) 2017-01-22T13:05:28.4886414Z at mkdirSyncRecursive (C:\Program Files\Microsoft Team Foundation Server
14.0\Build\tasks\PublishBuildArtifacts\1.0.28\node_modules\shelljs\src\mkdir.js:16:3)
how to fix it?
This is a known issue: Copy Files Task / Publish Build Artifacts Task copy to invalid UNC OR drive root produces RangeError: Maximum call stack size exceeded Issue in GITHub.
Just like jessehouwing commented you may have to update your build agent(TFS version). Another possibility may related to permission. Please make sure build agent (which was running as a Network Service) have sufficient privileges to create folders on the network share that it was trying to publish artifacts to.
You could also refer this similar issue: Publish build artifacts step fails, when using Artifact Type : fileshare (TFS 2015)
Related
I've seen other issues documented regarding SSIS project build failures but nothing that fits my scenario.
I am attempting to build an SSIS project (.dtproj) on a self hosted agent.
The project builds fine in Visual Studio 2019 and also on Azure Pipelines, but when I attempt to build it with the self hosted agent (via Command Line Task in a Build Pipeline in Azure DevOps) I get the following errors:
[debug]Evaluating condition for step: 'Build SSIS Packages'
[debug]Evaluating: succeeded()
[debug]Evaluating succeeded:
[debug]=> True
[debug]Result: True Starting: Build SSIS Packages
======================================================================== Task : Command line Description : Run a command line script
using Bash on Linux and macOS and cmd.exe on Windows Version: 2.151.2 Author: Microsoft Corporation
=========================================================================
[debug]VstsTaskSdk 0.9.0 commit 6c48b16164b9a1c9548776ad2062dad5cd543352
[debug]Entering C:\My Project\agent_work_tasks\CmdLine_d9bafed4-0b18-4f58-968d-86655b4d2ce9\2.151.2\cmdline.ps1.
[debug]Loading resource strings from: C:\My Project\agent_work_tasks\CmdLine_d9bafed4-0b18-4f58-968d-86655b4d2ce9\2.151.2\task.json
[debug]Loaded 6 strings.
[debug]SYSTEM_CULTURE: 'en-US'
[debug]Loading resource strings from: C:\My Project\agent_work_tasks\CmdLine_d9bafed4-0b18-4f58-968d-86655b4d2ce9\2.151.2\Strings\resources.resjson\en-US\resources.resjson
[debug]Loaded 6 strings.
[debug]INPUT_FAILONSTDERR: 'false'
[debug] Converted to bool: False
[debug]INPUT_SCRIPT: 'echo Building SsisProject...
[debug]
[debug]"C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\IDE\devenv.com" C:\My
Project\agent_work\1\s\MySolution.sln /build Development /project
C:\My
Project\agent_work\1\s\ETL\Integration\MySsisProject\MySsisProject.dtproj'
[debug]INPUT_WORKINGDIRECTORY: 'C:\My Project\agent_work\1\s'
[debug]Asserting container path exists: 'C:\My Project\agent_work\1\s' Generating script.
[debug]AGENT_VERSION: '2.155.1'
[debug]AGENT_TEMPDIRECTORY: 'C:\My Project\agent_work_temp'
[debug]Asserting container path exists: 'C:\My Project\agent_work_temp'
[debug]Asserting leaf path exists: 'C:\WINDOWS\system32\cmd.exe'
========================== Starting Command Output ========================
[debug]Entering Invoke-VstsTool.
[debug] Arguments: '/D /E:ON /V:OFF /S /C "CALL "C:\My Project\agent_work_temp\dde3e815-8cea-4bea-ab26-77e9bb52d973.cmd""'
[debug] FileName: 'C:\WINDOWS\system32\cmd.exe'
[debug] WorkingDirectory: 'C:\My Project\agent_work\1\s' "C:\WINDOWS\system32\cmd.exe" /D /E:ON /V:OFF /S /C "CALL "C:\My
Project\agent_work_temp\dde3e815-8cea-4bea-ab26-77e9bb52d973.cmd""
Building SsisProject...
Microsoft Visual Studio 2019 Version 16.0.29306.81. Copyright (C)
Microsoft Corp. All rights reserved.
The following files were specified on the command line:
C:\My Project\agent_work\1\s\MySolution.sln My
Project\agent_work\1\s\ETL\Integration\MySsisProject\MySsisProject.dtproj
[debug]Exit code: 1
[debug]Leaving Invoke-VstsTool.
[error]Cmd.exe exited with code '1'.
[debug]Processed: ##vso[task.logissue type=error]Cmd.exe exited with code '1'.
[debug]Processed: ##vso[task.complete result=Failed]Error detected
[debug]Leaving C:\My Project\agent_work_tasks\CmdLine_d9bafed4-0b18-4f58-968d-86655b4d2ce9\2.151.2\cmdline.ps1.
The other generic trouble shooting advice is to remove the space in your "My Project" folder. Yes, it's 2019 and it shouldn't matter and many tools comprehend spaces but the fewer escapes you need to worry about, the better your chances of success.
I've download nopCommerce 3.80 fresh code from github and publishing it from Visual Studio 2017 framework and I'm getting DLL related error.
Here are error messages.
------ Build started: Project: Nop.Services, Configuration: Release Any CPU
SGEN : error : Could not load file or assembly ..\nopCommerce_3.80_Source\packages\EPPlus.4.1.0\lib\net40\EPPlus.dll' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)
Build started: Project: Nop.Web.Framework, Configuration: Release Any CPU
CSC : error CS0006: Metadata file '..\nopCommerce_3.80_Source\Libraries\Nop.Services\bin\Release\Nop.Services.dll' could not be found
------ Build started: Project: Nop.Web, Configuration: Release Any CPU
CSC : error CS0006: Metadata file '..\nopCommerce_3.80_Source\Presentation\Nop.Web.Framework\bin\Release\Nop.Web.Framework.dll' could not be found
4>------ Skipped Publish: Project Nop.Web, Configuration: Release Any CPU ------**
Solution is successfully building in debug and build mode.
What can be wrong with DLL at publish time?
I get the solution by unblocking the error dll file by right click of that dll in their properties option.
I'm trying to install and run x64 Mercurial 3.8.3, but I'm getting the following error:
D:\Program Files\Mercurial>hg.exe
The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail.
Running sxstrace.exe gives the following log:
=================
Begin Activation Context Generation.
Input Parameter:
Flags = 0
ProcessorArchitecture = AMD64
CultureFallBacks = en-US;en
ManifestPath = D:\Program Files\Mercurial\hg.exe
AssemblyDirectory = D:\Program Files\Mercurial\
Application Config File =
-----------------
INFO: Parsing Manifest File D:\Program Files\Mercurial\hg.exe.
INFO: Manifest Definition Identity is (null).
INFO: Reference: Microsoft.VC90.CRT,processorArchitecture="amd64",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8"
INFO: Resolving reference Microsoft.VC90.CRT,processorArchitecture="amd64",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8".
INFO: Resolving reference for ProcessorArchitecture amd64.
INFO: Resolving reference for culture Neutral.
INFO: Applying Binding Policy.
INFO: Find publisher policy at C:\WINDOWS\WinSxS\manifests\amd64_policy.9.0.microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.9177_none_acd40623e1d81331.manifest
INFO: Begin assembly probing.
INFO: End assembly probing.
ERROR: Activation Context generation failed.
End Activation Context Generation.
It seems like it's looking for C:\WINDOWS\WinSxS\manifests\amd64_policy.9.0.microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.9177_none_acd40623e1d81331.manifest, which doesn't exist on my computer. I think this file comes from the Microsoft Visual C++ 2008 Redistributable Package (x64), but when I installed/repaired it I still get the same error.
I've also come across this same package from chocolatey, but its version history seems to indicate that its latest version is 9.0.30729.6161, not the 9.0.30729.9177 I'm looking for. I'm not sure where to find this version of the package.
I've already looked at these questions which seem very similar to my situation:
Side by Side configuration is incorrect error
Visual Studio 2012 Side by side configuration is incorrect
Edit: I've just reinstalled with x86 Mercurial and it works. Not ideal, but at least it's a workaround.
Microsoft Visual C++ 2008 Redistributable Package 9.0.30729.9177 doesn't seem to be publicly available, so I ended up reinstalling Windows. Now I can run Mercurial after installing it.
I ran the following batch file on our SQL Server "9". It is an SSIS 2012 package with no connections, no tasks, no code. It's an empty package.
ECHO before dtexe!
REM "DTExec.exe" /FILE "E:\SSIS\MyAppName\Packages\Empty2012Package.dtsx"
"D:\SQL2012\110\DTS\Binn\DTExec.exe" /FILE "E:\SSIS\MyAppName\Packages\Empty2012Package.dtsx"
SET RESULT=%errorlevel%
ECHO RESULT AFTER DTEXEC=%RESULT%
exit /B %RESULT%
Here's my output:
----------------------------------------------------------------
Output of messages for workload object TEST/GHG1990R.28/MAIN
Start date Tue Oct 06 20:45:38 2015
----------------------------------------------------------------
C:\Users\MyServerId>ECHO before dtexe!
before dtexe!
C:\Users\MyServerId>REM "DTExec.exe" /FILE "E:\SSIS\MyAppName\Packages\Empty2012Package.dtsx"
C:\Users\MyServerId>"D:\SQL2012\110\DTS\Binn\DTExec.exe" /FILE "E:\SSIS\MyAppName\Packages\Empty2012Package.dtsx"
Microsoft (R) SQL Server Execute Package Utility
Version 11.0.5058.0 for 64-bit
Copyright (C) Microsoft Corporation. All rights reserved.
Started: 8:45:39 PM
Could not load package "E:\SSIS\MyAppName\Packages\Empty2012Package.dtsx" because of error 0x80131534.
Description: The package failed to load due to error 0x80131534 "(null)". This occurs when CPackage::LoadFromXML fails.
Source: {BA581388-EFF5-4BC7-89E7-48E11D6DF0AE}
Started: 8:45:39 PM
Finished: 8:45:39 PM
Elapsed: 0.094 seconds
C:\Users\MyServerId>SET RESULT=5
C:\Users\MyServerId>ECHO RESULT AFTER DTEXEC=5
RESULT AFTER DTEXEC=5
C:\Users\MyServerId>exit /B 5
I get the same error regardless of whether I run with the 32 or 64 bit DTEXEC utility. When I run the same batch file against the same package on another SQL Server, server "80", I get no error.
All of the packages work on server 80, none work on 9. I get the above error every time on server 9.
When I execute this on both 80 and 9,
select ##version
I get the same result
Microsoft SQL Server 2012 - 11.0.5058.0 (X64)
May 14 2014 18:34:29
Copyright (c) Microsoft Corporation
Enterprise Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)
I am able to successfully use the sqlcmd and bcp utilities on 9, but not the dtexec utility.
The error that I am getting seems to suggest that I am using an old version of dtexec to open up a newer package, for example, trying to use a SQL 2008 dtexec util to execute a new SQL 2012 package.
Clearly the packages are not corrupt because all of the packages work on 80 and copies of the exct files on 9 all do not work.
The only thing I can think of is a installation issue with SQL Server, for example, a corrupt install or unregistered dll.
As far as I can tell, this is the first and only version of SQL Server installed on these machines, so I shoould not be acidentily runnning an old version of DTEXEC with a newer 2012 package.
Here is the complete Empty2012Package.dtsx file:
<?xml version="1.0"?>
<DTS:Executable
DTS:refId="Package" xmlns:DTS="www.microsoft.com/SqlServer/Dts"
DTS:ExecutableType="SSIS.Package.3"
DTS:CreatorName="MyDOMAIN\MyLanId"
DTS:CreatorComputerName="MYCPTR"
DTS:CreationDate="7/2/2015 8:26:52 AM"
DTS:PackageType="5"
DTS:VersionBuild="2"
DTS:VersionGUID="{00FD1F37-6375-4942-91D3-9ECA0B131FFD}"
DTS:LastModifiedProductVersion="11.0.2100.60"
DTS:LocaleID="1033"
DTS:ObjectName="Empty2012Package"
DTS:DTSID="{1539BA56-F17B-438E-A874-A2151F2F79C5}"
DTS:CreationName="SSIS.Package.3">
<DTS:Property
DTS:Name="PackageFormatVersion">6</DTS:Property>
<DTS:Variables />
<DTS:Executables />
<DTS:DesignTimeProperties><![CDATA[<?xml version="1.0"?>
<!--This CDATA section contains the layout information of the package. The section includes information such as (x,y) coordinates, width, and height.-->
<!--If you manually edit this section and make a mistake, you can delete it. -->
<!--The package will still be able to load normally but the previous layout information will be lost and the designer will automatically re-arrange the elements on the design surface.-->
<Objects
Version="sql11">
<!--Each node below will contain properties that do not affect runtime behavior.-->
</Objects>]]></DTS:DesignTimeProperties>
</DTS:Executable>
Since I used SQL 2012 to create the dtsx file, I knew that is was a 2012 package. However, according to this web page,
http://www.techbrothersit.com/2014/09/ssis-how-to-find-version-of-ssis.html
PackageFormatVersion of 6 indicates a 2012 package.
I don't have access to the server to see the versions of each dtexec.exe file. I hope to get this information soon.
When I run the same batch file with the same package on 80, as mentioned above, it works:
----------------------------------------------------------------
Output of messages for workload object C1_GHG1_TEST/GHG1999I.11/MAIN
Start date Tue Oct 06 22:21:08 2015
----------------------------------------------------------------
C:\Users\MyServerId>ECHO before dtexe!
before dtexe!
C:\Users\MyServerId>REM "DTExec.exe" /FILE "E:\SSIS\MyAppName\Packages\Empty2012Package.dtsx"
C:\Users\MyServerId>"D:\SQL2012\110\DTS\Binn\DTExec.exe" /FILE "E:\SSIS\MyAppName\Packages\Empty2012Package.dtsx"
Microsoft (R) SQL Server Execute Package Utility
Version 11.0.5058.0 for 64-bit
Copyright (C) Microsoft Corporation. All rights reserved.
Started: 10:21:08 PM
DTExec: The package execution returned DTSER_SUCCESS (0).
Started: 10:21:08 PM
Finished: 10:21:08 PM
Elapsed: 0.203 seconds
C:\Users\MyServerId>SET RESULT=0
C:\Users\MyServerId>ECHO RESULT AFTER DTEXEC=0
RESULT AFTER DTEXEC=0
C:\Users\MyServerId>exit /B 0
Any ideas on what may be causing this error? I'm thinking that this is a server SQL Server setup issue rather than something that I can control.
Your thoughts?
Update
The problem is related to security permissions. When we try running the job in the CA Scheduler udner MyServiceID, an Admin with access to the box then checked the Event Log and found this error:
The user has not been granted the requested logon type at this machine.
Furthermore, When a user who is in the local Admin group remotes to this server and launches the same batch file, the job runs successfully.
According to this link,
https://technet.microsoft.com/en-us/library/cc732593(v=ws.10).aspx
The error can be resoled by granting the right to "Allow User To Log On Locally." The user is already granted "Allow Log On As Batch" rights. When I dop a "net user MyServiceId" command from the command line, I also see that the ID is active and allowed on all Workstations at all times.
When I requested "Allow user to LogOn Locally" rights to be granted, apparently even the "Admins" could not grant this right because is is disallowed by Group Policy. Because this is the only server where this is happening, I am left wondering what is different about this server assuming that all serevrs share the same Group Policy. One thing that we noticed is that the OWNER property on the dtsx file is not MyServiceId and in environments. I don't have the righs to change this but I don't thing that this is it. The MyServiceAccount does have full control of the folder where the batch files and packages reside.
Update 2
Since this is now clearly a security issue, perhaps it would help if I try an state the question after stating the known facts:
MyServiceId has execute access to the local folder, E:\SSIS\MyAppName\Packages\, in which SSIS package resides
MyServiceId has execute access to the local folder, D:\SQL2012\110\DTS\Binn\, in which DTEXEC resides
MyServiceId has LogOn As Batch rights on the Server.
MyServiceId is an active account that is allowed on all Servers and Workstations
Question:
Given the simple one line batch file that calls DTEXEC passing a package path as a param, what could be contributing to the error that I am getting? What additional things can I look for? Sicne "Allow User To Log On locally" is never set on other server, what can be different on this server that is contributing to this error:
The user has not been granted the requested logon type at this machine.
Is the value of the OWNER property of the dtsx file relevant?
Update 3
Calling process Name: C:\Windows\System32\LSASS.exe
Is this a hint?
Update 4
In production, where it works,the service id is executing with a Network Logon type of 3, which is interactive. On 9, where it's giving us this error, it is executing with a logon type of 2, which is interactive. (We do not have the option to turn on "Allow Log On Locally" for the uyser on 9. This is verboten.
What would account for the same ID running on 2 different machines on teh same domain, to run as different user types?
I encountered this error shortly after making a modification to my machine.config file on my workstation. I resolved my issues in the machine.config (I had placed a node under the wrong parent node) and this error went away.
Unfortunately, since the error is vague, this may not be the solution for your situation. Just thought I'd share in case it helps someone.
I changed my SQL service account to local system. My SSIS services were also running from local system only.
So, ideally we can try keeping both as same services account.
NOTE: this needs to be applied only in case we are not able to change the access rights of SQL agent service account.
I have done android project in the mono develop It working fine in debug mode but when I am Trying to run project in release mode then it is giving following error:
C:\Users\Administrator.EDZ0138\Documents\Projects\IdooctopusNew\IdooctopusNew\SGEN: Error: Could not load file or assembly 'Mono.Android, Version=0.0.0.0, Culture=neutral, PublicKeyToken=c4c4237547e4b6cd' or one of its dependencies. Strong name validation failed. (Exception from HRESULT: 0x8013141A) (IdooctopusNew)
Can anyone please help me ?
I got a solution for this issue.
You just have to do is, put the mono.android.dll in to the C:\Program
Files\Microsoft SDKs\Windows\v7.0A\bin folder, open a command prompt and do
following steps:
cd C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin
sn -Vr Mono.Android.dll
gacutil -i C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin
Then build the project.
If you get the error for another DLL like System.xml.dll etc. then repeat above
procedure for respective DLL.
All the best.......!