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.
Related
I'm new to Redhat OpenShift and trying to deploy node application (with angularjs + mysql) and running into build issues.
Using openshift console created node application and in advanced options pointed to the private repository and linked configured secret (ssh key to private repository).
My build is failing with "Assemble script failed". Pasting the logs as below (from console - obfuscated private keys and values).
Not sure if I'm missing some configurations. Appreciate help on this.
Cloning "ssh://username#bitbucket.org/username/my-app.git" ...
Commit: xxxxxxxxxxxxxxxxx (Fixed readme)
Author: Name <email>
Date: Wed Sep 6 19:50:59 2017 -0700
Pulling image "docker-
registry.default.svc:5000/openshift/nodejs#sha256:0000000000000" ...
---> Installing application source
---> Building your Node application from source
Current git config
url.https://github.com.insteadof=git#github.com:
url.https://.insteadof=ssh://
url.https://github.com.insteadof=ssh://git#github.com
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
remote.origin.url=ssh://username#bitbucket.org/username/my-app.git
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
branch.master.remote=origin
branch.master.merge=refs/heads/master
---> Installing dependencies
---> Using 'npm install -s --only=production'
error: build error: non-zero (13) exit code from docker-
registry.default.svc:5000/openshift/nodejs#sha256:0000000000000
Pls note that my source code is hosted on private repository and per log above it appears openshift is able to access the repository and download the source code.
Thanks Graham for the pointer. I recreated the application and this time in advanced options on the web console selected 1 GB (from default of 500 mb) after which my build worked fine.
I am trying to build a sample webapi project using VS-2017 community in openshift with .netcore 1.1 template but its an building error.
Cloning "https://github.com/kuntal-b/netcoreWebAPI" ...
Commit: 84b604df745890311a7d23451c4bbef6552d1fb1 (2)
Author: kuntal.bose01#gmail.com Date: Thu
May 25 23:11:27 2017 +0530 Pulling image
"registry.access.redhat.com/dotnet/dotnetcore-11-rhel7#sha256:7c775cc11b280105f51bf2622ed79036c7f961e1cb9db23c4b17c66606154f7b"
... Pulling image
"registry.access.redhat.com/dotnet/dotnetcore-11-rhel7#sha256:7c775cc11b280105f51bf2622ed79036c7f961e1cb9db23c4b17c66606154f7b"
...
---> Copying application source ...
---> Installing dependencies ... warn : The folder '/opt/app-root/src' does not contain a project to restore.
---> Building application ... Couldn't find 'project.json' in '.' error: build error: non-zero (13) exit code from
registry.access.redhat.com/dotnet/dotnetcore-11-rhel7#sha256:7c775cc11b280105f51bf2622ed79036c7f961e1cb9db23c4b17c66606154f7b
Building application ... Couldn't find 'project.json' in '.' error:
.net core 1.1 template don't have a project.json file.
Using s2i with dotnetcore will only work in openshift with the old project.json based projects. This will be fixed once .net standard 2.0 is released.
Check: https://github.com/redhat-developer/s2i-dotnetcore/issues/46
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.
What do I need to do to get TeamCity to properly generate coverage reports against my project?
I've got a custom powershell build script running DotCover against my code. The build script has a coverage method like so
Function Invoke-NUnitWithCoverage ( [string] $targetAssembly, [string] $outputDir, [string] $runCommand){
$fileName = Get-TestFileName $outputDir $runCommand
$xmlFile = "$fileName-TestResults.xml"
$txtFile = "$fileName-TestResults.txt"
$coverageFile = "$fileName-CoverageResults.xml"
exec{ dotcover.exe analyse /TargetExecutable=$nunitRunnerDir\nunit-console.exe /TargetArguments="$targetAssembly /fixture:$runCommand /xml=$xmlFile /out=$txtFile /nologo /framework=4.0" /Output=$coverageFile /ReportType=xml } "Running code coverage '$runCommand' failed."
Write-Host "##teamcity[importData type='dotNetCoverage' tool='dotcover' path='$coverageFile']"
}
The output appears correct on TeamCity, however it's not generating the report. Here's the TeamCity Log. As you can see, there are generation failures.
TL;DR;
If you don't want to read the entire log, here are the key lines.
[JetBrains dotCover] Failed to merge snapshots. Unknown storage type. Unknown storage type
...
[JetBrains dotCover] Unhandled exception: 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.
...
[JetBrains dotCover] Report generation failed. Too short file
...
[JetBrains dotCover] Failed to create zipped snapshot. Too short file
...
[JetBrains dotCover] 'E:\BuildAgent\temp\buildTmp\dotCover5237101456909205485Merge' is not a coverage snapshot.
##teamcity[importData type='dotNetCoverage' tool='dotcover' path='E:\BuildAgent\work\81eb7c2fdfcfc0af\build-artifacts\results\TransCanada-GCTS-App-Tests-CoverageResults.xml']
....
....
Waiting for 16 service processes to complete
[10:32:34]Processing 1 coverage report(s)
[10:32:34]Generating coverage report by dotcover for files: [E:\BuildAgent\work\81eb7c2fdfcfc0af\build-artifacts\results\TransCanada-GCTS-App-Tests-CoverageResults.xml, E:\BuildAgent\work\81eb7c2fdfcfc0af\build-artifacts\results\TransCanada-GCTS-Framework-Test-CoverageResults.xml, E:\BuildAgent\work\81eb7c2fdfcfc0af\build-artifacts\results\TransCanada-GCTS-CommonDataService-Tests-Unit-CoverageResults.xml, E:\BuildAgent\work\81eb7c2fdfcfc0af\build-artifacts\results\TransCanada-GCTS-Contracts-Tests-Unit-CoverageResults.xml, E:\BuildAgent\work\81eb7c2fdfcfc0af\build-artifacts\results\TransCanada-GCTS-Invoicing-Tests-Unit-CoverageResults.xml, E:\BuildAgent\work\81eb7c2fdfcfc0af\build-artifacts\results\TransCanada-GCTS-FlowingGasService-Tests-Unit-CoverageResults.xml, E:\BuildAgent\work\81eb7c2fdfcfc0af\build-artifacts\results\TransCanada-GCTS-JobSchedulingService-Tests-Unit-CoverageResults.xml, E:\BuildAgent\work\81eb7c2fdfcfc0af\build-artifacts\results\TransCanada-GCTS-CommonDataService-Tests-Integration-CoverageResults.xml, E:\BuildAgent\work\81eb7c2fdfcfc0af\build-artifacts\results\TransCanada-GCTS-Contracts-Tests-Integration-CoverageResults.xml, E:\BuildAgent\work\81eb7c2fdfcfc0af\build-artifacts\results\TransCanada-GCTS-Invoicing-Tests-Integration-CoverageResults.xml, E:\BuildAgent\work\81eb7c2fdfcfc0af\build-artifacts\results\TransCanada-GCTS-FlowingGasService-Tests-Integration-CoverageResults.xml, E:\BuildAgent\work\81eb7c2fdfcfc0af\build-artifacts\results\TransCanada-GCTS-JobSchedulingService-Tests-Integration-CoverageResults.xml, E:\BuildAgent\work\81eb7c2fdfcfc0af\build-artifacts\results\TransCanada-GCTS-CommonDataService-Tests-Acceptance-CoverageResults.xml, E:\BuildAgent\work\81eb7c2fdfcfc0af\build-artifacts\results\TransCanada-GCTS-Contracts-Tests-Acceptance-CoverageResults.xml, E:\BuildAgent\work\81eb7c2fdfcfc0af\build-artifacts\results\TransCanada-GCTS-FlowingGasService-Tests-Acceptance-CoverageResults.xml, E:\BuildAgent\work\81eb7c2fdfcfc0af\build-artifacts\results\TransCanada-GCTS-Invoicing-Tests-Acceptance-CoverageResults.xml]
[10:32:34]Get dotCover version (1s)
[10:32:35]Started dotCover: E:\BuildAgent\tools\dotCover\dotCover.exe version E:\BuildAgent\temp\buildTmp\dotCover2609519531914093171Version
[10:32:35]
Output: JetBrains dotCover Console Runner v2.7.2.84. Copyright (c) 2009-2014 JetBrains s.r.o. All rights reserved.
[10:32:35]dotCover exited with code: 0
[10:32:35]Use DotCover 2.7.x commands set
[10:32:35]Merge dotCover reports (10s)
[10:32:45]Started dotCover: E:\BuildAgent\tools\dotCover\dotCover.exe merge E:\BuildAgent\temp\buildTmp\dotcover6392358845042650216.xml
[10:32:45]
Output: JetBrains dotCover Console Runner v2.7.2.84. Copyright (c) 2009-2014 JetBrains s.r.o. All rights reserved.
[JetBrains dotCover] Snapshot merging started [12/3/2014 10:32:44 AM]
[JetBrains dotCover] Source snapshots number: 16
Merging snapshots 1-5
[JetBrains dotCover] Failed to merge snapshots. Unknown storage type. Unknown storage type
[10:32:45]dotCover exited with code: -2
[10:32:45]dotCover returned non-zero exit code.
[10:32:45]Remove dotCover snapshot files
[10:32:45]Started dotCover: E:\BuildAgent\tools\dotCover\dotCover.exe delete E:\BuildAgent\temp\buildTmp\dotcover4610370083173723447.xml
[10:32:45]
Output: JetBrains dotCover Console Runner v2.7.2.84. Copyright (c) 2009-2014 JetBrains s.r.o. All rights reserved.
[JetBrains dotCover] Unhandled exception: 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.
[10:32:45]dotCover exited with code: -10
[10:32:45]dotCover returned non-zero exit code.
[10:32:45]Generate dotCover report (7s)
[10:32:52]Started dotCover: E:\BuildAgent\tools\dotCover\dotCover.exe report E:\BuildAgent\temp\buildTmp\dotcover8678535704262330052.xml
[10:32:52]
Output: JetBrains dotCover Console Runner v2.7.2.84. Copyright (c) 2009-2014 JetBrains s.r.o. All rights reserved.
[JetBrains dotCover] Report generation started [12/3/2014 10:32:45 AM]
[JetBrains dotCover] Report generation failed. Too short file
[10:32:52]dotCover exited with code: -2
[10:32:52]dotCover returned non-zero exit code.
[10:32:52]Generate dotCover HTML report
[10:32:52]Packing snapshot files (6s)
[10:32:59]Started dotCover: E:\BuildAgent\tools\dotCover\dotCover.exe zip E:\BuildAgent\temp\buildTmp\dotcover1602620273009840026.xml
[10:32:59]
Output: JetBrains dotCover Console Runner v2.7.2.84. Copyright (c) 2009-2014 JetBrains s.r.o. All rights reserved.
[JetBrains dotCover] Failed to create zipped snapshot. Too short file
[10:32:59]dotCover exited with code: -2
[10:32:59]dotCover returned non-zero exit code.
[10:32:59]Remove dotCover snapshot files (6s)
[10:33:06]No statistics values are provided by dotCover report generator (recommended)
For dotCover you should send paths to the snapshot (dotCover.snapshot) file that is generated by the dotCover.exe cover command, not .xml file.
When running DTEXEC I am getting "The connection xxxx is not found".
I beleieve this is because the connection managers are located at Project level and not within the package itself.
When running DTEXECUI - these connection managers are not displayed.
Is the only way to move them into the package - seems a bit weird as what is the point of allowing them a project level if you then have to move them to use them with DTEXEC.
Thanks
Here is the command line syntax you asked for:
C:\Users\Administrator>dtexec /FILE "\"F:\SSIS Projects\HESA\HESA\01 - Upload Metadata Files To Oracle.dtsx\"" /SET "\Package.Variables[User::varYear.Properties
[Value]";"1999" /CHECKPOINTING OFF /REPORTING EW /CONSOLELOG SMT
Your assumption that
the connection managers are located at Project level and not within the package itself
is exactly the problem. But there is a solution:
build the project to get a .ispac file
instead of invoking dtexec with /FILE you have to invoke it with /Project and /Package, like this:
/Project "path to you .ispac file, resulting from building the project"
/Package "Name of your package.dtsx"
Please, be aware that if you provide the whole path to your .dtsx package the execution will fail with very criptic SQLDUMPER error messages.