My TeamCity build fails because I have a project that has 2 EF Code Migration configurations in it.
From the build log:
[12:39:58]Checking for changes
[12:39:58]Collecting changes in 1 VCS root (1s)
[12:40:00]Clearing temporary directory: C:\TeamCity\buildAgent2\temp\buildTmp
[12:40:00]Publishing internal artifacts
[12:40:00]Checkout directory: C:\TeamCity\buildAgent2\work\1679b8b30e00ad0
[12:40:00]Updating sources: server side checkout (2s)
[12:40:03]Step 1/8: Gulp (Command Line)
[12:40:03]Step 2/8: Nuget Package Refresh (NuGet Installer) (3s)
[12:40:06]Step 3/8: Compile (MSBuild) (21s)
[12:40:27]Step 4/8: Unit Tests (NUnit) (33s)
[12:41:01]Step 5/8: Transform Files (Powershell) (2s)
[12:41:03]Step 6/8: Deployment Build on XXXXX Live (MSBuild) (25s)
[12:41:29]Step 7/8: Deploy Database (Powershell) (5s)
[12:41:34]Step 8/8: Deploy Portal.Hub (Powershell) (33s)
[12:42:08]Publishing artifacts
[12:42:08][Publishing artifacts] Collecting files to publish: [C:\TeamCity\buildAgent2\temp\buildTmp\nuget5954880593924726328packages\nuget.xml => .teamcity/nuget]
[12:42:08][Publishing artifacts] Publishing using [WebPublisher]
[12:42:08][Publishing artifacts] Publishing using [ArtifactsCachePublisher]
[12:42:08][Publishing artifacts] Artifacts path 'C:/TeamCity/buildAgent2/temp/buildTmp/nuget5954880593924726328packages/nuget.xml' not found
[12:42:08]Reverting patched assembly versions
[12:42:08][Reverting patched assembly versions] Restoring C:\TeamCity\buildAgent2\work\1679b8b30e00ad0\src\Portal.Api\Properties\AssemblyInfo.cs
[12:42:08][Reverting patched assembly versions] Restoring C:\TeamCity\buildAgent2\work\1679b8b30e00ad0\src\Portal.Common\Properties\AssemblyInfo.cs
[12:42:08][Reverting patched assembly versions] Restoring C:\TeamCity\buildAgent2\work\1679b8b30e00ad0\src\Portal.Data\Properties\AssemblyInfo.cs
[12:42:08][Reverting patched assembly versions] Restoring C:\TeamCity\buildAgent2\work\1679b8b30e00ad0\src\Portal.Hub\Properties\AssemblyInfo.cs
[12:42:08][Reverting patched assembly versions] Restoring C:\TeamCity\buildAgent2\work\1679b8b30e00ad0\src\Portal.Manager\Properties\AssemblyInfo.cs
[12:42:08][Reverting patched assembly versions] Restoring C:\TeamCity\buildAgent2\work\1679b8b30e00ad0\src\Portal.Managers\Properties\AssemblyInfo.cs
[12:42:08][Reverting patched assembly versions] Restoring C:\TeamCity\buildAgent2\work\1679b8b30e00ad0\src\Portal.SignalR\Properties\AssemblyInfo.cs
[12:42:08][Reverting patched assembly versions] Restoring C:\TeamCity\buildAgent2\work\1679b8b30e00ad0\src\Portal.Tests\Properties\AssemblyInfo.cs
[12:42:08]Publishing internal artifacts
[12:42:08][Publishing internal artifacts] Sending using WebPublisher
[12:42:08][Publishing internal artifacts] Sending using ArtifactsCachePublisher
[12:42:08]Build failure condition: There was an error reported in one of the build steps.
[12:42:08]Build failure condition cause message: ERROR: More than one migrations configuration type was found in the assembly 'Portal.Data'. Specify the name of the one to use. (show original message)
[12:42:08]Build finished
Note: the only red (failures) are the last two lines above "Build Finished"
I am not running the migrations and I can't see any steps in team city or the publish profile that would be attempting to do this.
I do not want to split my configurations into separate projects, I just want to stop TeamCity from attempting to run them.
My Build Steps are:
1/8 Gulp - minimize js files
2/8 NuGet Installer - update nuget references in the solution
3/8 MSBuild - .NET 4.5 x86 compile
4/8 NUnit - run unit tests
5/8 Powershell - run script to manipulate app.config files for the windows service
6/8 MSBuild - use publish profile to deploy website
7/8 Powershell - script to deploy database
8/8 Powershell - script to deploy windows service
The publish profile: validation connection button works OK on the connection tab, on the settings page there are several databases listed but none have connection strings or "use this connection string at runtime" checked. One of them has an info label next to it "In order to publish a Code First Model, Code First Migrations should be used".
We have virtually identical build configurations for other projects which work fine.
Thanks
From the logs, it does appear as though you are trying to apply the EF migrations in Step 7 - Deploy Database Step.
This is where the config exception is getting thrown.
If the goal is to stop TeamCity from running them then disabling the step would do that.
Hope this helps
Related
I am using SQL Server 2017 and Visual Studio 2019 Community edition.
I have created my first SSDT project and configured it in Jenkins and I am facing issues while deploying it before running my tSQLt test cases.
Please refer to the link which I used to configure everything:
https://the.agilesql.club/2017/03/sql-server-continuous-deployment-in-a-box/#comment-4976546606
PS: Have made changes in related ps files for paths of msbuild and other related files as I am using SSDT and Sql server recent versions and above link shows older versions.
Error
I got succeed to build my ssdt project in jenkins but when it tries to run "DeployDacpac.ps1" in "Unit Tests" step it shows success in pipeline steps but actually script shows error like :
C:\Program Files (x86)\Jenkins\workspace\Test12_master>powershell.exe -ExecutionPolicy RemoteSigned -File "C:\Program Files (x86)\Jenkins\workspace\Test12_master/Deploy/DeployDacpac.ps1" -projectPath "C:\Program Files (x86)\Jenkins\workspace\Test12_master" -dacpac "C:\Program Files (x86)\Jenkins\workspace\Test12_master/bin/Debug/DatabaseUT.dacpac" -publishProfile "C:\Program Files (x86)\Jenkins\workspace\Test12_master/DatabaseUT.publishprofile.xml"
Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.Data.Tools.Utilities, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
at Microsoft.Data.Tools.Schema.CommandLineTool.Program.Main(String[] args)
Update: Now after changing path of sqlpackage.exe from my local folder to visual studio...\SQLDB\DAC\140\sqlpackage.exe" deployment works fine. But it shows that tSQLt unit tests step run successfully. Its not showing proper message any test case failed or passed.
Here is some ending result lines from unit test run step:
"...
Installing package 'AgileSQLClub.tSQLtTestAdapter' to 'C:\Program Files (x86)\Jenkins\workspace\Test17_master\Lib'.
CACHE https://api.nuget.org/v3/registration5-gz-semver2/agilesqlclub.tsqlttestadapter/index.json
Package "AgileSQLClub.tSQLtTestAdapter.0.59.0" is already installed.
Microsoft (R) Test Execution Command Line Tool Version 16.6.0
Copyright (c) Microsoft Corporation. All rights reserved.
Starting test execution, please wait...
A total of 158 test files matched the specified pattern."
It consideres all sps including tSQLt sps above in 158. But no result mentions if any unit test passed or failed.
Please guide.
Instead of SSDT project, I am using batch command to run tsqlt test cases through jenkins. i.e. sqlcmd.
So no need to dig more
I have an established CI pipeline comprising (prior to deployment):
TFS build
JFrog Artifactory for build artifact management
SoapUI and SpecFlow (BDD & itaretive, parameterised) for web service functional test automation
I have no access to our build agent servers and no permission to install anything thereon. Instead, I've added the SoapUI binaries as links to my functional test project; the binaries are pulled from source control in the Get Sources step of every build.
This works okay but it greatly increases the footprint of my test project (and any other test project for which SoapUI would be required), and by extension, the execution time of the build: functional testing will only execute on a small fraction of the builds executed (only if application codebase has changed or sufficient time interval since last full build and test has elapsed).
For these reasons, I opted to remove the SoapUI binaries folder from my test project and instead deploy a SoapUI binaries zip archive to an Artifactory repository. With the addition of a PowerShell script step in my build definition, I can pull the SoapUI binaries as needed and extract to the desired location on the build server. Foolishly, I thought this might be straightforward...
I did manage to push the zipped SoapUI binaries folder to the Artifactory repo, and, in my Development build definition, I did manage to correctly script my PowerShell step to pull the zip archive and extract its content successfully to he same folder in the build binaries directory on the build agent server as it had been located originally.
However, when I execute my build, in the step where the SoapUI tests are executed, on the first test iteration, I see the following error returned to build console:
System.ComponentModel.Win32Exception: The directory name is invalid
I added a PowerShell scripted filtered folder content step before the test execution step in both my Development (new) and my Production (original) builds for comparison. Both show the required 'testrunner.bat' to be present, in the same folder on the build agent server.
The test project itself has been unchanged (except for the removal of the SoapUI binaries folder).
To summarise:
I'm trying to execute SoapUI tests in two builds; in each build, the same test project is used and the SoapUI binaries are in the same location when the test execution kicks off.
One build executes successfully without issue.
One build fails at test execution step, returning error "System.ComponentModel.Win32Exception: The directory name is invalid".
I'm very puzzled by this; insights and SoapUI wisdom most welcome.
Thanks for looking.
Turned out, there was a discrepancy in the directory paths on the testrunner.bat between the builds; a '_' where a '-' should have been
I am trying to set up a build pipeline for the Windows Universal Sample Application File Access Project.
The pipeline is using the Azure Pipelines Hosted VS2017 Image
The solution builds when I run it in VS locally.
Package.appxmanifest contains
<TargetDeviceFamily Name="Windows.Universal" MinVersion="10.0.10586.0" MaxVersionTested="10.0.17763.0" />
When the pipeline tries to build the following error appears in the build task log.
Error CS0234: The type or namespace name 'ApplicationModel'
does not exist in the namespace 'Windows'
(are you missing an assembly reference?)
The YAML is
resources:
- repo: self
queue:
name: Hosted VS2017
demands:
- msbuild
- visualstudio
steps:
- task: NuGetCommand#2
displayName: 'NuGet restore'
- task: VSBuild#1
displayName: 'Build solution **\*.sln'
The project looks like this on my machine
Where
And it runs correctly.
I notice the log for the Nuget Restore task has no errors and does report
2018-12-16T01:27:31.8700773Z Checking compatibility for Microsoft.NETCore.Targets.UniversalWindowsPlatform 5.0.0 with UAP,Version=v10.0 (win10-x86-aot).
2018-12-16T01:27:31.8700831Z Checking compatibility for Microsoft.NETCore.Platforms 1.0.0 with UAP,Version=v10.0 (win10-x86-aot).
2018-12-16T01:27:31.8700878Z All packages and projects are compatible with UAP,Version=v10.0 (win10-x86-aot).
[Update]
Looking at the location on my machine of the SDK
C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.AI.MachineLearning.MachineLearningContract\1.0.0.0
I wonder how Nuget is meant to know about that.
Indeed I wonder why it has something about MachineLearning in the path.
[Update]
I changed versions to 17134 (RS4/1803) instead of 17763 (RS5/1809) as suggested by Stefan Wick MSFT
The errors changed to
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\VisualStudio\v15.0\AppxPackage\Microsoft
.AppXPackage.Targets(3218,5): Error APPX0101: A signing key is required in
order to package this project. Please specify a PackageCertificateKeyFile or
PackageCertificateThumbprint value in the project file.
Process 'msbuild.exe' exited with code '1'.
SharedContent\Templates\UWPSDKSampleCPP\ARM\Debug\UWPSDKSampleCPP\AppxManifest.xml(0,0):
Error APPX0501: Validation error. error C00CE169: App manifest validation
error: The app manifest must be valid as per schema: Line 10, Column 13,
Reason: 'Microsoft.SDKSamples.$safeprojectname$.CPP' violates pattern
constraint of '[-.A-Za-z0-9]+'. The attribute 'Name' with value
'Microsoft.SDKSamples.$safeprojectname$.CPP' failed to parse.
Process 'msbuild.exe' exited with code '1'.
SharedContent\Templates\UWPSDKSampleCS\bin\ARM\Debug\AppxManifest.xml(0,0):
Error APPX0501: Validation error. error C00CE169: App manifest validation error:
The app manifest must be valid as per schema: Line 10, Column 13, Reason: 'Microsoft.SDKSamples.$safeprojectname$.CS' violates pattern constraint of '[-.A-Za-z0-9]+'.
The attribute 'Name' with value 'Microsoft.SDKSamples.$safeprojectname$.CS' failed to parse.
Process 'msbuild.exe' exited with code '1'
The error is due to the fact that your app is targeting the 1809 SDK (v17763), which has not been rolled out on the build agents yet, due to some issues.
Until it has been rolled out on the agents, you have two options to get unblocked:
Target the 1803 SDK (v17134) if you don't actually need any APIs from the 1809 SDK - or
Use this script to explicitely install the 17763 SDK dependency
I will update the answer once there is an update regarding the SDK rollout to build agents.
I am very much new in TFS framework, and now i am creating build from last 3 days, all steps passes but fail # Build Solution with error:
[error]Process 'msbuild.exe' exited with code '1'.fails.png
My versions are:
TFS version: Version 15.105.25910.0
VS version: Microsoft Visual Studio Enterprice 2017 (15.9.4)
Can anyone from community tell me whats going wrong with my build.
Build Error:
2018-12-29T11:48:37.1011337Z ##[section]Starting: Build solution
*.sln 2018-12-29T11:48:43.4372323Z ##[command]"C:\Program Files (x86)\MSBuild\14.0\bin\msbuild.exe"
"\localhost\ARM-Drop1\1\s\LetsGo1\LetsGo1.sln" /nologo /nr:false
/dl:CentralLogger,"\localhost\ARM-Drop1_tasks\VSBuild_71a9a2d3-a98a-4caa-96ab-affca411ecda\1.0.45\ps_modules\MSBuildHelpers\Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll";"RootDetailId=f568d794-328b-48cf-a753-e603bc019eed|SolutionDir=\localhost\ARM-Drop1\1\s\LetsGo1"ForwardingLogger,"\localhost\ARM-Drop1_tasks\VSBuild_71a9a2d3-a98a-4caa-96ab-affca411ecda\1.0.45\ps_modules\MSBuildHelpers\Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll"
/p:VisualStudioVersion="14.0"
/p:_MSDeployUserAgent="TFS_29388952-19c1-40f9-b321-9389f9ab526b_build_17_287"
2018-12-29T11:48:43.5382020Z MSBUILD : error MSB1021: Cannot create an
instance of the logger. Could not load file or assembly
'file://\localhost\ARM-Drop1_tasks\VSBuild_71a9a2d3-a98a-4caa-96ab-affca411ecda\1.0.45\ps_modules\MSBuildHelpers\Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll'
or one of its dependencies. The system cannot find the file specified.
2018-12-29T11:48:43.5392017Z Switch:
CentralLogger,\localhost\ARM-Drop1_tasks\VSBuild_71a9a2d3-a98a-4caa-96ab-affca411ecda\1.0.45\ps_modules\MSBuildHelpers\Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll;RootDetailId=f568d794-328b-48cf-a753-e603bc019eed|SolutionDir=\localhost\ARM-Drop1\1\s\LetsGo1
2018-12-29T11:48:43.7011531Z **##[error]Process 'msbuild.exe' exited
with code '1'. 2018-12-29T11:48:43.7871273Z ##[section]Finishing:
Build solution **.sln
I have resolved this bug, as I had done lot of changes into the solution file and the build definition in order to resolve the issues but no luck, so the quickest way I have in my mind is to delete the build definition plus uninstall the agent and again reconfigure it with appropriate agent capability and create new build definition and its all work as expected and the build definition got succeeded.
I have a package which I added to to TFS feed, I can browse feed in VS 2K17, add the packge to add it to a dotnet project compile correctly and it downloads the pkg, on command line also msbuild t:restore works fine.
In TFS, I am using a
dotnet restore
step but it is failing with the following error for the same package
C:\Program Files\dotnet\sdk\2.1.500\NuGet.targets(114,5): error :
Unable to load the service index for source
http://vsalms:8080/tfs/TODOS/_packaging/e475f9ce-1afd-47c9-8aa6-2f0d54948126/nuget/v3/index.json.
[C:\agent_work\2\s\lib\CoreFlogger\CoreFlogger.csproj]
2018-12-03T14:24:46.6934510Z C:\Program
Files\dotnet\sdk\2.1.500\NuGet.targets(114,5): error : The token
supplied to the function is invalid
[C:\agent_work\2\s\lib\CoreFlogger\CoreFlogger.csproj]
I am not sure which version of nugget it uses as there is no indication in the task. I have downloaded nuget and added its path to the environment, typing nugget in console gives the following
NuGet Version: 4.8.1.5435 but when build fails, I see
Regarding dotnet version, on the commande line when I issue
dotnet.exe --version
2.1.500
In the build ouptut, I see
2018-12-03T14:24:38.9211043Z Description : Build, test, package, or
publish a dotnet application, or run a custom dotnet command. For
package commands, supports NuGet.org and authenticated feeds like
Package Management and MyGet. 2018-12-03T14:24:38.9211302Z Version :
2.131.0
On the TFS server, I also added a a key in global nuget.config as follows
What is missing? It seems that it is a connection issue but really not able to debug or find out wwhat/where to check