I have to reference the test adapter DLL (xunit.runner.visualstudio.testadapter.dll) in our vNext Visual Studio Online build to execute the tests.
The problem is that with the new DNX structure, packages are being restored to C:\Users\{user}\.dnx\packages and are not relative to the project's path anymore.
How can I reference this location in the build?
We are using the hosted build agent.
I think the answer for your question can be found in the following StackExchange answer: Running unit tests in TFS/VSO Build vNext using xUnit adapter. Then the packages end up in a local directory and not the global .dnx cache.
...
Make a global.json file and put the following into it:
{
"packages": "packages"
}
That will force your dnu restore to put the packages into .\packages\, which will hopefully solve the problem.
Related
The CI pipeline works well if I remove the nobuild:true option from the DotNetCoreCLI#2 task to pack the Project (ie to create a NuGet package) but I am not able to understand what special except not building the project does the nobuild option brings.
I need not want to build the Project again as the Previous task have already build the Project and locked the Assembly version of DLLs generated. I want to use the same build to create the NuGet package and to do the same I need to pass the NoBuild option but doing the same breaks the pipeline.
The pipeline gives the error that the DLLs to be packed are not present at the specified location but I tried to look at the location and I could find the DLLs.One thing that confuses me is that though I have given nobuild to be true but still the tasks shows as Building the Project.
- task: DotNetCoreCLI#2
displayName: ".NET pack"
inputs:
command: pack
packagesToPack: ${{ parameters.packagesToPack }}
nobuild: true
versioningScheme: byEnvVar
versionEnvVar: CI_Version
packDirectory: $(build.artifactStagingDirectory)\${{ parameters.packTo }}
verbosityPack: 'Normal'
Its also important to note that the same thing( nobuild:true) works on Windows Agent but it fails on Ubuntu Agent.
PS: It could be a case where windows has upgraded the agent and has caused the issue. I searched over the issue and found that one has to lock the .net SDK in the build pipeline
Thanks for the other answers that may be related to the issue but things were already taken care.
The issue was only on the Linux Environment because of an issue in .NET SDK. Refer here
The error(DLLs could not be found in the path specified ) that was being generated was correct in somehow but also it was misleading. The DLLs were being generated in Release folder at the build stage and when I was packing the DLLs they were being searched in release folder.
Though Release and release remains the same in Windows Environment but Ubuntu being case sensitive generates the Error.
The SDK implementation of .Net Core missed the IgnoreCase in the Regex option and that caused the build to break on switchin to a Linux Agent.
DotnetBuild:
Dotnet Pack:
Solution: Define the folder where to generate the DLLs in the .csproj and the automatically build and pack step would pick the DLLs from there.
For this error NU5026 ,it refers to the project being packed has not been built yet and hence cannot be packed. Please view this reference.
The file ''F:\project\bin\Debug\net461\project.exe' to be packed was not found on disk.
According to your description, you canceled the automatic build before pack. There's possibility that your build task and pack task did't run with same configuration. For example, In dotnet build task, the project is automatically built with Debug configuration, and in the pack task you set the configuration as Release.
In dotnet build task, the project is automatically built with Debug configuration.
In the dotnet pack task , the default Configuration to Package is Release
If you do not cancel the automatic build before pack, in the .net pack task the project is built in Release configuration.
So please check the log of your build task and pack task, make sure the dotnet build command and dotnet pack command use the same configuration.
I am trying to run the "Visual studio build task" in VSTS CI, but its failing with the following error:
Build error
I read it here bclbuildWhat does the Microsoft.Bcl.Build NuGet package do?
and passed the MSBuild arguments as /p:BclBuildImported=Ignore but still it complains that nuget restore didn't occur. What could be the problem?
Nuget restore task:
Nuget-restore task
Firstly make sure you can build the project locally with VS. Then add Nuget Restore task in the build definition to restore the packages.
UPDATE:
Just check your Nuget.config file, make sure you have set the correct feeds/package sources you want to consume and the package Microsoft.Bcl.Build.1.0.21 is included in the sources.
See Specifying sources in NuGet.config for details.
Besides, you can also try to create a new build definition with the Nuget restore task, then provide the nuget.config file and proper path to solution, also try with other Hosted agents.
I upgraded Microsoft.AspNetCore from 2.0.3 to 2.0.5 and my WebAPI project, although running successfully locally, fails to start in production (IIS). Everything was fine in production until this upgrade. The error message produced in the log directory is as follows:
Error:
An assembly specified in the application dependencies manifest (MyProject.WebAPI.deps.json) was not found:
package: 'Microsoft.AspNetCore.Mvc.Abstractions', version: '2.0.2'
path: 'lib/netstandard2.0/Microsoft.AspNetCore.Mvc.Abstractions.dll'
This assembly was expected to be in the local runtime store as the application was published using the following target manifest files:
aspnetcore-store-2.0.5.xml
Could someone explain to me the details of exactly what this means? I assume it's a version mismatch of sorts, but why is this occurring? I thought the latest stable releases of NuGet packages weren't supposed to have such issues.
I was able to resolve the issue by downgrading Microsoft.AspNetCore.All from 2.0.5 to 2.0.3, but would like to find a better solution to the issue so I can use the most up-to-date version of this package.
Development machines usually have the SDK installed but on production the runtime only.
Add the following to your .csproj file and publish again.
<PropertyGroup>
<PublishWithAspNetCoreTargetManifest>false</PublishWithAspNetCoreTargetManifest>
</PropertyGroup>
Sometimes this is related to the Startup Project, For example if the migration is a class library in Azure Functions project. You have to make sure when you run Add-Migration while the EF Library project is selected as Startup Project.
For me, the marked answer didn't solve the issue. My issue was when trying to Add-Migration
Add-Migration -Name initial-migration -Context Mysln.Data.MyDbContext -StartupProject Mysln -Project Mysln.Core
And the error was like this:
I solved it by downgrading all my Entityframework packages to 2.0.0 instead of the latest 2.2.0-preview one.
If you have more than one project in your solution like me:
and if you want to scaffold dbcontext in your "non startup" project (InstantOrder.Functions.Data in my case)
then you should add the -StartupProject parameter of the Scaffold-DbContext command like this -
Scaffold-DbContext "Server=..." -Project InstantOrder.Functions.Data -StartupProject InstantOrder.Functions.Data
I know this may be old, but just in case it can help some one else, this one worked for me:
Adding:
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
To the PropertyGroup in the .csproj file.
To solve the first half of the error message, An assembly specified in the application dependencies manifest (…) was not found be sure to always use the publish output when deploying to a target sever.
For a self-contained application it can be found in
bin\Release\netcoreapp2.0\win81-x64\publish
or for framework-dependent deployments in
bin\Release\netcoreapp2.0\publish
The output in the directories above are meant to be used in development only, since they are specific to machine and user configuration built with.
Taken from a related answer.
2 cents: If you just take from the build folder, the dlls for the dependency aren't provided. If you publish the folder, they are. This was the fix for me.
I had this error however my solution was somewhat different from what was posted above. My problem was that I was deploying via a zip file and while building the zip file I wasn't including sub directories therefore required files were not being included.
So if you are publishing via a zip file make sure to include all sub folders while building the zip.
I got this error while running Scaffold-DbContext command on the Library project.
Solution:
Remove the Azure Function project from the solution, and then run this command.
After that, use add an existing project feature to add the Azure Function project again in the solution.
The correct .NET Core runtime was not installed on my PC. I had NETCore.App 2.1 and 2.2, but the project was targeted to 2.0.
dotnet --list-runtimes
I installed the correct runtime from the dot.net site and it resolved the issue.
In most case you get that error because there's misalignment of versions.
I changed the Microsoft.VisualStudio.Web.CodeGeneration.Design version, an it worked.
Before
<PackageReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Design" Version="3.1.0" />
After
<PackageReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Design" Version="2.2.4" />
This happened to me when I published my Lambda to AWS after renaming the project. I deleted both the obj and bin folders, rebuilt, republished and that fixed it.
I changed filters in Yaml.
Had projects called TestHelper etc...
Testrunner tried to run projects without tests, and the build was flagged as failed.
Added:
!**\*Helper*.*
To:
- task: DotNetCoreCLI#2
inputs:
command: 'test'
projects: |
**\*test*.dll
!**\*TestAdapter.dll
!**\obj\**
!**\*TestPlatform*.dll
!**\*Testing*.*
!**\*TestHost*.*
!**\*Helper*.*
I am using Continuous Integration feature in Team Services (was Visual Studio Online). My build definition targets a specific project in a solution (not the whole solution), which is ClientUI MVC website.
The solution contains three projects:
ClientUI
AdminUI
Client Services
The Build Definition for ClientUI Project:
Repository:
Nuget Installer Step:
I have tried different params but not working.
Visual Studio Build
Before trying to target the a single project, my build definition was targeting the whole solution with the following parameters:
NuGet Installer -> Path to Solution: **\*.sln
Visual Studio Build -> Solution: **\*.sln ; MSBuild Arguments: /p:outdir=$(build.artifactstagingdirectory)
It was working. However now, it generates this error in the Nugget Restore Task:
2016-04-22T21:07:00.6716725Z Set workingFolder to default: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\1.98.1\tasks\NuGetInstaller\0.1.25
2016-04-22T21:07:00.8163908Z Executing the powershell script: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\1.98.1\tasks\NuGetInstaller\0.1.25\NuGetInstaller.ps1
2016-04-22T21:07:01.5283529Z ##[error]Cannot find path 'C:\a\1\s\packages.config' because it does not exist.
2016-04-22T21:07:01.5439897Z C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\1.98.1\agent\worker\tools\NuGet.exe restore "C:\a\1\s\packages.config" -NonInteractive
2016-04-22T21:07:03.0441507Z MSBuild auto-detection: using msbuild version '14.0' from 'C:\Program Files (x86)\MSBuild\14.0\bin'.
2016-04-22T21:07:03.0597010Z ##[error]Cannot determine the packages folder to restore NuGet packages. Please specify either -PackagesDirectory or -SolutionDirectory.
2016-04-22T21:07:03.0909881Z ##[error]Unexpected exit code 1 returned from tool NuGet.exe
Try setting "Installation type" to "Install" for "Nuget Installer" task since you are using "packages.config" to install the packages.
For anyone curious, the source of the error about "Please specify either -PackagesDirectory or -SolutionDirectory" is that the build process is trying to issue a command similar to this:
C:\hostedtoolcache\windows\NuGet\4.4.1\x64\nuget.exe restore D:\a\1\s\MyProject\packages.config -PackagesDirectory packages -Verbosity Detailed -NonInteractive
The below screenshots should help if you want to build a project (rather than the solution) and your nuget "packages" folder is at the solution-level.
Additionally, you may need to specify this as the "MSBuild Argument" in the build task of your project: /p:SolutionDir="/"
I had the same thing sorted it out by changing the mapping - go to Repository tab, I had my mapping to another directory which means the nuget installer could not execute.
I am trying to use MSDeploy to deploy an MVC project to the server using TeamCity. When I do this on my computer in powershell, using the following command:
msbuild.exe .\mvc.csproj /p:PublishProfile=DevServer /p:VisualStudioVersion=11.0
/p:DeployOnBuild=True /p:Password=MyPassword /p:AllowUntrustedCertificate=true
It builds the project and deploys it to the server (info defined in the DevServer publish profile) perfectly. The output shows an MSDeployPublish section at the end, in which I see text like Starting Web deployment task from source... and then with rows telling me what files are updated, etc.
When I run this on TeamCity, using an MSBuild Build step, on the same file, with the same parameters (from the same working directory) it builds the project but does not publish it. Instead it has the regular output from a build process (CoreCompile, _CopyFilesMarkedCopyLocal, GetCopyToOutputDirectoryItems, CopyFilesToOutputDirectory) but then does not actually go and publish anything.
What changes to I need to make to the setup in TeamCity to get it to publish deploy in the same way that it works using MSBuild from my computer?
(TeamCity 7.1, MSBuild 4.0, WebDeploy 3.0, Visual Studio 12, IIS 7. Related to my previous question)
We do our WebDeploys with a TeamCity MSBuild step configured as follows:
Build File Path: Server.csproj
Command Line Parameters:
/p:Configuration=%configuration%
/p:DeployOnBuild=True
/p:DeployTarget=MSDeployPublish
/p:MsDeployServiceUrl=https://%web.deploy.server%:8172/MsDeploy.axd
/p:DeployIisAppPath=%web.deploy.site%
/p:AllowUntrustedCertificate=True
/p:Username=
/p:AuthType=NTLM
We use integrated authentication; change as necessary to fit your scheme. The value of this, I think, is that it builds everything from scratch and doesn't rely on a pre-built package. From the gist you posted I noticed that you do some DB publishing, we don't use WebDeploy for that so I can't offer any guidance there. Hope this helps.
I use MSBuild.exe to package to zip, and MSdeploy.exe to deploy in separate steps.
To deploy the package.zip file on the command line:
"C:\Program Files\IIS\Microsoft Web Deploy V2\msdeploy.exe" -verb:sync
-source:package="C:\Build\MyAppName.Debug.zip"
-dest:auto,wmsvc=webservername,username=webdeploy,password=*******
-allowUntrusted=true
This command is also worth explaining in detail:
-verb:sync : makes the web site sync from the source to the destination
-source:package="C:\Build\MyAppName.Debug.zip" : source is an MSBuild zip file package
-dest:auto,wmsvc=webservername : use the settings in the package file to deploy to the server. The user account is an OS-level account with permission. The hostname is specified, but not the IIS web site name (which is previously specified in the MSBuild project file in the project properties).
You can modify parameters based on your configuration. I like it this way because with separate steps, its easier to debug problems.
Use TeamCity build step and the command line runner.
Update:
If you want an example of how to build the ZIP package using MSBuild, try something like this:
"C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe"
MyWebApp/MyWebApp/MyWebApp.csproj
/T:Package
/P:Configuration=Debug;PackageLocation="C:\Build\MyWebApp.Debug.zip"
This should work the same on your local PC as well as on the CI server.
Here are the config settings that finally worked for me:
/p:Configuration=CONFIG-NAME
/p:DeployOnBuild=True
/p:DeployTarget=MSDeployPublish
/p:MsDeployServiceUrl=http://SITE-URL/MsDeployAgentService
/p:username="USERNAME"
/p:password=PASSWORD
/p:AllowUntrustedCertificate=True
/P:CreatePackageOnPublish=True
/p:DeployIisAppPath=SITE-URL
/p:MSDeployPublishMethod=RemoteAgent
/p:IgnoreDeployManagedRuntimeVersion=True
I had exactly the same issue! I've posted the solution I used over at: MsBuild not finding publish profile
Basics were:
Install the Azure SDK 1.8 on the build server
Force the /P:PublishProfileRootFolder value to ensure MSBuild can locate the publish profile
Ensure that you have the Microsoft Web Developer Tools feature installed for Visual Studio. This was missing on my build agent but once I added it the TeamCity build worked just fine.
This can happen when the build target paths are missing from your MSBuild directory. Instead of trying to get those to line up on every developer machine, install the targets from the Nuget. That way it will always be the same for everyone, regardless of how their machine is setup.