I can successfully build my project on local. When I do via VSTS then build is not successful. I get an error message that a dll cannot be found in my sub project. And it is Rapportage.Logic. The missing dll is used by Rapportage.Logic
Does anyone know the reason?
Most of the time this type of error comes down to:
files present/edited on developer machine but not commited (usually the .csproj file)
subtle differences between Visual Studio build and MSBuild.
I would try the following:
copy the MSBuild command from Azure DevOps logs (the line containing MSBuild.exe)
change the paths in the command to match your dev environment (e.g d:\a\1\s to c:\code\myproject)
run this command
If this command fails with the same error as the build you the problem is a difference between MSbuild and Visaul Studio.
If it succeeds, you most likely have missed a commit.
Build is successful on my local but not on vsts azure DevOps
It depends on how you add ReportViewer references.
If you add the ReportViewer reference manually, you need add the ReportViewer reference to the solution/project folder, then add the reference from that folder. In this case, the path of references are not hard-coded paths. Besides, you need add those/this ReportViewer reference to the source control and submit to the Azure devops repos.
If you add the ReportViewer reference by nuget, you need add the nuget restore task to restore those nuget packages. I could see you are using nuget restore task from your build log (The second image.), but on the build definition, I did not see you have add that task (The 3rd, 4th images.). So, make sure you have restore those packages when you build on the Azure devops, and you could check the restore task if those nuget packages are restored.
Hope this helps.
Related
In my GitLab CI/CD pipeline, I use the nuget command to do a pack, push, etc. The pipeline runner is registered on a local machine. On that machine I downloaded the nuget.exe, set the first entry in the system env variables to be the path to it, and then added the source I am using via nuget source add. Locally, I can see the source has been added via nuget source list, however in the pipeline it is telling me the source does not exist. Doing a nuget source list in the pipeline job confirms the source I added isn't there.
My guess is it is using another nuget.exe, but I'm not sure where or why it would not use the system environment variable path first?
Any ideas how to resolve this?
a month ago we had a solution (big one) in .net framework 4.7.2. This was building fine on azure devops pipeline.
Now we ported our solution to net5.
Everything is working in visual studio but on azure devops, the pipeline is failing.
We had to change our Microsoft.Interop.Word (and excel, and outlook) to a com reference. Because net5 is multiplatform and interop is not.
Because we removed the nuget packages and changed to com reference the pipeline is failing.
Does anyone know how to handle this specific problem?
We can't remove the interop.excel and etc from our projects because they are dependent on it.
Beneath you see the result we have.
It feels like we have tried everything to make it work again on azure devops.
have you consider self-hosted agent since you have requirement to stay the external library in this case Microsoft.Office.Interops and I don't think Microsoft Azure DevOps Pipeline agent support that currently.
With self-hosted agent, you install the PIAs and link your library/com references to the paths.
There is problem with assembly in the code, your code may be building on local environment as it is getting references for all assemblies however when you checking in the code pipelines could not fetch the assemblies through nuget package restore, if you are referencing assembly from local machine, make sure you add its nuget package reference package.config file, so nuget restore will restore the package
can you try below
Link
I have python solution which resides in VSTS repository. Using build pipeline and private agent, the source code gets copied to VM.
After executing the python files, output is stored in 3 different files at the source directory level.
I want to download/copy these output files from private hosted VM to VSTS repository.
How can this be achieved?
Thank you
The only way to get something into the repository is by checking it in via source control.
Maybe it's enough for you to just publish these files as a build artifact. You have the option to publish directly to VSTS or to any Windows file share.
If you really want these files in your repository I'd suggest you publish them as build artifacts and check them in with a release pipeline. You could add a new stage in your existing release pipeline or add a new release pipeline that triggers automatically every time your build completes.
You can call git command to add and push changes to repository, for example:
Check Allow Scripts to access the OAuth token option
Add Command Line task (Tool:git; Arguments: add [file path]; Working folder: $(System.DefaultWorkingDirectory))
Add command line task (Tool:git; Arguments: commit –m “add build result”; Working folder: $(System.DefaultWorkingDirectory))
Add command line task (Tool: git; Arguments: push https://test:$(System.AccessToken)#{account}.visualstudio.com/{project}/_git/{repository} HEAD:master
Related article: Keep Git repository in sync between VSTS / TFS and Git
On the other hand, the better way is publishing the result files as artifact of build through Publish Build Artifact task.
I need to execute a command line utility from a package that is downloaded as part of nuget package restore in the TFS build process.
On my local computer that is stored in c:\users\me.nuget*
I've tried every permutation of that on TFS without success. I've also tried \mydir\packages with no success as well.
The biggest problem is that I have to run the package restore step before being able to see any sort of feedback from the log. That's some slow debugging.
Any ideas? Thanks ahead.
With the latest nuget/msbuild the packages folder is held under the active user's profile directory, so an appropriate Powershell command is
Get-ChildItem $(UserProfile)\.nuget\packages
This currently evaluates on the VSTS 2017 Hosted build agent to C:\Users\VssAdministrator\.nuget\packages but by using the variable you are insulated from any changes made.
Just an addition to #Paul Hatcher's answer:
I also faced the same problem in Azure DevOps build pipeline where a specific package and nuget packages directory could not be found.
It is a Xamarin.Forms app based on a .net standard library where no packages folder exists. I later noticed in build logs that the packages are restored to nuget folder under user's profile. However this particular case is not documented on https://learn.microsoft.com/en-us/azure/devops/pipelines/build/variables?view=vsts#agent-variables.
That means #Paul Hatcher's answer is also valid if you try to reference nuget package folder directly from your build pipeline. This ($(UserProfile).nuget\packages) should actually be a (standard) predefined build variable.
The Nuget package cache folder is in C:\Users\buildguest.nuget\packages, but it will be cleaned after build if you are using Hosted build server.
The simple way to verify:
Add NuGet restore or .Net Core Restore build step to restore packages
Add PowerShell build step to list files in C:\Users\buildguest.nuget\packages
Code:
Get-ChildItem -Path C:\Users\buildguest\.nuget\packages
Queue build and check the PowerShell step log (the packages’ will be listed in the log)
Remove/disable NuGet restore or .Net Core Restore build step > Save build definition
Queue build
The build will be failed, because the path does not exist.
So, the packages need to be restored before build solution/project if aren’t existing. You can add packages to source control and map to build agent to deal with the issue of too long time takes to restore packages.
I've got a build running in VSTS which is restoring NuGet packages from both nuget.org and a custom feed in VSTS. The custom feed is in the solutions NuGet.config as a <packageSource>, along with the user name and password in <packageSourceCredentials>
The build, including the restore, is working Ok, but there is a warning ...
2016-10-12T16:18:57.6589001Z ##[warning]To connect to NuGet feeds
hosted in your Team Services account/TFS project collection with
NuGet 3.1 or below, edit your build definition to specify a path
to a NuGet.config containing the package sources you wish to use.
How can I remove this?
Based on my test, that warning remains even through using higher version of nugget (e.g. 3.3) or do not restore package from VSTS feed. (Hosted build agent has the same result).
You can’t remove it unless you custom a build task to restore package through command line.
I submit a issue here.
Update:
The issue has been updated.
I see the issue in the code coming from our transition from depending
on assets coming with the agent to being deployed with the task. You
can get around this for now until we get an official change out by
either (1) choosing to use the Nuget 3.5 version radio button in the
task config or (2) supplying a path to your nuget.config.
So, you can use Nuget 3.5 version or specify nuget.config file.