User Profile
varunmittal
Copper Contributor
Joined 3 years ago
User Widgets
Recent Discussions
Re: Issues Running the Local Agent
The error message "The attribute "Version" in element <PackageReference> is unrecognized" suggests that there is a problem with the version of NuGet that is being used. The version of NuGet that is being used is 6.4.0.123, which may be causing an issue with the version of the packages in your project. You can try to update NuGet to the latest version by running the following command: nuget update -self You can also try to specify the version of NuGet to use in the NuGetCommand step in your pipeline yaml file: - task: NuGetCommand@2 inputs: restoreSolution: '$(solution)' version: 'latest' Another thing you can try is to update your dotnet core version to latest version and check if it is compatible with the version of NuGet that you have installed. Finally, you can also try to delete the package references and re-adding them, or even try a different package version. To force the version of NuGet in your pipeline YAML file, you can add the version input to the NuGetCommand task. For example, if you want to use version 6.5.0 of NuGet, you can update the NuGetCommand task in your pipeline as follows: - task: NuGetCommand@2 inputs: restoreSolution: '$(solution)' version: '6.5.0' This will instruct the pipeline to use version 6.5.0 of NuGet for restoring packages. Alternatively, if you want to use the latest version of NuGet, you can specify the version as latest: - task: NuGetCommand@2 inputs: restoreSolution: '$(solution)' version: 'latest' You can check the latest version of NuGet from the official Nuget website, and update the version number accordingly. Additionally, you can also try adding the following line in the pipeline to use the nuget.exe in the NuGet tool installer step: - task: NuGetCommand@2 inputs: command: restore restoreSolution: '$(solution)' feedsToUse: 'config' nugetConfigPath: '$(NuGetToolInstaller.NuGetConfigPath)' It may be helpful to clear the NuGet package cache before. To clear the NuGet package cache, you can use the following command in the NuGet Package Manager Console: nuget locals all -clear This command will clear all the local NuGet package caches, including the packages, http-cache, and temp files. You can also use the following command to clear specific NuGet cache: nuget locals [cache-name] -clear Where [cache-name] can be one of the following: packages http-cache temp For example, to clear the packages cache, use the following command: nuget locals packages -clear Additionally, the NuGet cache can also be found in the following location on your machine: Copy code %UserProfile%\.nuget\packages You can simply delete the contents of this folder. some official documentation from NuGet on how to clear the cache and troubleshoot issues: https://docs.microsoft.com/en-us/nuget/consume-packages/managing-the-global-packages-and-cache-folders#how-to-clear-the-global-packages-folder https://docs.microsoft.com/en-us/nuget/consume-packages/managing-the-global-packages-and-cache-folders https://learn.microsoft.com/en-us/nuget/reference/nuget-exe-cli-reference Additionally, you can also find more information on NuGet's GitHub page, where you can find other users' issues and solutions, or submit your own: https://github.com/NuGet/Home/issues Please let me know if you have any other question.8KViews0likes2CommentsRe: Getting 404 Not found Error when running in Devops Pipeline
Yes, your understanding is mostly correct. When you use a self-hosted agent, the pipeline runs on the same machine as the agent, which means that the pipeline has access to the same resources and environment as the agent. However, there can be some differences between the pipeline and the agent, for example, the pipeline may be running in a different context or environment, or the pipeline may be running with different permissions or credentials. Also, there could be some network/firewall restrictions that only allow the self-hosted agent to access the server but not the pipeline. In your case, since the script works when you run it from the self-hosted agent, but it doesn't work when you run it from the pipeline, it's likely that the pipeline is running in a different context or environment and is unable to access the server, or that the pipeline is running with different permissions or credentials. It's also possible that the script is not running as expected, as there could be some logic or syntax errors in the script that are causing it to fail. I recommend checking the pipeline's configuration and environment to see if there are any differences between the pipeline and the agent, and to also check the script again for any errors or logical issues.9.4KViews0likes1CommentRe: PR done on one repo triggers the existing pipeline
This issue is likely caused by the trigger settings on the existing pipeline you mentioned. The trigger setting "include: '*'" means that the pipeline will be triggered for all branches in the repository, including new branches. To prevent the pipeline from being triggered for the new repository, you can change the trigger setting to include only the branches that you want the pipeline to run on. You can also remove the trigger settings and configure build pipeline on the new repository. You could also consider creating a new pipeline with new trigger settings that only include the branches you want it to run on and link it to your new repository. You can also use the Azure DevOps REST APIs to check the list of all the pipelines and triggers and delete the unwanted ones, if the above solution doesn't work.1.9KViews0likes1CommentRe: Issues Running the Local Agent
This error message suggests that there is an issue with the version of NuGet being used. The error message states "The attribute "Version" in element <PackageReference> is unrecognized" which suggests that the version of NuGet being used does not support the version attribute. You can try updating the NuGet version to the latest version. You can also try running the pipeline with a specific version of MSBuild by using the option -MSBuildVersion to force NuGet to use that version. Additionally, make sure that the version of dotnet-sdk that you have installed on your local agent matches the version specified in the pipeline. If the version of the SDK is not compatible with the version of NuGet, it can cause issues like this. Lastly, it is always good practice to clear the caches and temp folders in the local agent machine. Sometimes, the pipeline may be using an old version of the package, which can cause issues.8.2KViews0likes5CommentsRe: Getting 404 Not found Error when running in Devops Pipeline
It sounds like the script is trying to access a specific URL and is returning a 404 error when run from the pipeline, but works when run from the server where the self-hosted agent is located. This could be caused by a number of things, such as: The URL being accessed is incorrect or no longer valid The server hosting the URL is not accessible from the pipeline's location The script may not have the necessary permissions or credentials to access the URL when run from the pipeline The script is run in different environment or context when run from pipeline, that could cause different behavior You should check the URL to ensure that it is correct, check if the server hosting the URL is accessible from the pipeline, and ensure that the script has the necessary permissions and credentials to access the URL when run from the pipeline. It may also be helpful to check if there are any differences in the environment or context when the script is run from the pipeline versus when it is run from the server.9.5KViews0likes3CommentsRe: Migrating TFS2018 to ADO
I apologize for any confusion caused by my previous response. The TFS Migrator tool, which is used to migrate data from TFS to Azure DevOps (formerly known as Visual Studio Team Services or VSTS), is no longer available for download from the Microsoft website. The tool was retired in 2019 and Microsoft no longer supports it. Instead, Microsoft recommends using the following alternatives to migrate your data: Azure DevOps Database Import Service: This service allows you to import your TFS databases into Azure DevOps Server. This service is available for TFS 2017 and newer versions. TFS Integration Platform: This is a free, open-source tool that allows you to migrate data between TFS and Azure DevOps. Third-Party Migration Tools: There are many third-party migration tools available that can be used to migrate data from TFS to Azure DevOps. It is important to carefully research and evaluate any third-party migration tools or services before using them, to ensure that they meet your needs and requirements, and that they are compatible with your version of TFS and Azure DevOps. Also, Microsoft recommends having a backup of your data before proceeding with any migration. I apologize for any confusion or inconvenience this may have caused, and please let me know if there's anything else I can assist you with.2.3KViews0likes1CommentRe: Unable to get output variable value in the deploy stage
It looks like you are trying to access the value of the variable "varFuncAppsToDeploy" in your deployment stage, which was set in the previous job "GetTemplateAndPar" using the PowerShell task. In order to access the variable in the deployment stage, you need to reference it using the correct syntax. In your deployment stage, you can use the following syntax to access the variable: $(dependencies.GetTemplateAndPar.outputs['setVariable.varFuncAppsToDeploy']) You can also use the following way of accessing it $(varFuncAppsToDeploy) Note that the variable must be marked as an output variable using the "isOutput=true" flag in the PowerShell script, as you have done in your script. You might also need to check the pipeline's log files to see the variable's value and if it's being set or not. Also make sure that you are running the bash task in the same agent where the variable was set.841Views0likes0CommentsRe: Migrating TFS2018 to ADO
The TFS Migrator tool, which is used to migrate data from TFS to Azure DevOps (formerly known as Visual Studio Team Services or VSTS), is no longer available for download from the Microsoft website. The tool was retired in 2019 and Microsoft no longer supports it. Instead of using TFS Migrator, Microsoft recommends using the Azure DevOps Database Import service to migrate data from TFS to Azure DevOps. This service provides a supported, scalable, and more efficient way to migrate your data. Here is the link for the Azure DevOps Database Import service documentation: https://docs.microsoft.com/en-us/azure/devops/migrate/tfs-azure-devops-migration-overview?view=azure-devops It is also recommended that you plan your migration and test the migration on a non-production environment before migrating your production data. Please give like if it is helpful for you2.4KViews0likes3CommentsRe: Unable to login to azure devops, no notification in Authenticator
It sounds like there may be an issue with the Azure DevOps service or your account specifically. A few things you can try include: Check the Azure DevOps service status page to see if there are any known issues. Try using a different device or browser to see if that resolves the issue. Check that you have the latest version of the Authenticator app installed on your phone. Ensure that your phone's clock is set correctly and that you have a stable internet connection. Check the Authenticator App to make sure that your account is still linked to the App. Make sure that the phone number or email associated with your account is up to date. Try to reset your MFA for Azure DevOps. It seems that the issue may be related to the Azure DevOps service specifically, since the Authenticator notifications are working correctly for other Microsoft services. You can try the following steps: Check your notification settings on the Authenticator app to ensure that notifications are enabled for Azure DevOps. Check that the Azure DevOps service is linked to the Authenticator app and that the account is set up correctly. Make sure that you are logged in with the correct Azure DevOps account in your browser. Try disabling and re-enabling MFA for your Azure DevOps account. Check your spam/junk folder in your mail in case the notifications are being marked as spam. If none of these steps resolve the issue, you may want to contact Azure DevOps support for further assistance. They may be able to help you troubleshoot the problem or provide additional guidance.11KViews0likes1CommentRe: Is there any way to trigger a different pipeline inside of a pipeline in Azure Dev Ops
Yes, it is possible to trigger a different pipeline inside of a pipeline in Azure DevOps by using the variable you described, "IsTrigger". You can check the value of the variable within your pipeline using the "Control Options" task. You can set the condition of the task to eq(variables['IsTrigger'], 'true') and configure it to trigger another pipeline when the condition is true, You can also use the "Azure DevOps Check Condition" task and check the condition eq(variables['IsTrigger'], 'true') and use the "Azure DevOps Task Group" task to call another pipeline based on the condition being true. Note that you will have to link the pipeline you want to trigger by setting the "Task group" field of the task group task with the pipeline name.920Views0likes0CommentsRe: Can I require work item tagged 'uxdesign' require a uxdesigner role approve it before merging?
Yes, it is possible to set up a workflow that automatically notifies UX designers when a pull request (PR) is submitted with a certain tag and requires approval from at least one team member with the role of 'designer.' One way to achieve this is to use Azure DevOps' built-in pull request policies and custom tags. Here's a general outline of the steps you can take: Create a custom tag in Azure DevOps that can be used to indicate when a PR requires UX design changes. In your repository, create a pull request policy that requires the custom tag 'uxdesign' to be added to PRs that require UX design changes. Create a pull request policy that requires at least one team member with the role of 'designer' to approve PRs that require UX design changes. Set up notifications in Azure DevOps so that when a PR is submitted with the 'uxdesign' tag, the UX designers on the team are automatically notified. You can also use Azure DevOps' built-in approval feature, and assign the approval to the group that represents the UX designers. Additionally, you can use Azure DevOps' built-in code review feature, that allows you to assign reviewers to review a pull request, that way you will make sure that the UX designers will be reviewing the code changes that affects the UX. This approach will allow you to automate the process and ensure that UX design changes are reviewed and approved by the appropriate team members before being merged.1KViews0likes0CommentsRe: Azure DevOps Portal is Very Slow
Hi This might be due to the following reasons: Network connectivity issues: If there are problems with your internet connection, it could prevent the portal from loading. High traffic: If many users are accessing the portal at the same time, this could cause it to slow down or become unresponsive. Server issues: There could be problems with the servers that host the portal, which could cause it to become slow or unresponsive. Browser issues: If you are experiencing issues with your browser, such as outdated software or too many extensions, it could affect the performance of the portal. If the issue is with the Azure DevOps service itself, you can check the Azure DevOps status page https://status.dev.azure.com/ to see if there are any known issues or planned maintenance that could be causing the problem. If you are not able to resolve the issue, you can open a support ticket with Microsoft to investigate the issue further.14KViews0likes0Comments
Groups
Recent Blog Articles
No content to show