I setting up a build in Azure devops.
My project is mvc application.
Visual studio 2019
Everything build fines except that I do not want to build one of my projects(It has some issues. I do not want to remove it so i checked it to not be built) and in the configuration Manger the Build check mark is not checked . But the devops keeps building it and it breaks my build. No issue in visual studio 2019. Not sure what to do . Here is my yml file
Any help will be much appreciate it
But the devops keeps building it and it breaks my build.
For this issue, please check the following two points:
1.Whether the changes are committed and pushed to remote azure repo.
2.Since you're build with release+any cpu mode in CI pipeline, you must make sure you unchecked the Build box for Release+Any CPU page instead of Debug+Any CPU page.
In addition, Lance Li gave a detailed analysis about this issue in this case, you can refer to it for details.
I think in some of these project someone might have manully changed the project file or solution file.Beacuse using the configuration manager was not fixing the issue .So We had to remove all the project and set them up again
Related
We have an in-house Azure DevOps 2019 server and I'm currently setting up a build for a new .Net6 solution whose projects reference various packages from both nuget.org and an in-house feed in our ADO server's "Artifacts" area.
With this being .Net6, I'm assuming I have to use the ".Net Core" restore task (black square icon), rather than the older "NuGet" restore task (blue icon)? I've therefore added the former, and configured the pertinent settings as seen below, where "NuGetPackages" is the name of our in-house feed:
When I run the build, this task is failing with the message
error NU1301: Unable to load the service index for source http://***/_packaging/2df3c440-07a5-4c01-8e5c-bfbd6e132f09/nuget/v3/index.json.
The URL of our in-house feed is:
http://***/_packaging/NuGetPackages/nuget/v3/index.json, so why has the feed name in the URL been replaced with a GUID as seen in the error message? Presumably this is why the restore fails.
Incidentally we have numerous .Net Framework 4.x solutions that reference the same packages and build fine. These use the older "NuGet" (blue icon) restore task, but the settings are identical to those in the above image, suggesting that the newer ".Net Core" task is doing something strange.
(As an aside, could someone explain the difference between the "NuGet" task and the ".Net Core" task? Could I still use the older task in my .Net6 build pipeline? I tried it briefly earlier but it complained that msbuild v17 isn't installed and didn't want to continue down that path for fear of breaking the 4.x builds).
Something that hasn't been mentioned here, but has been the source of my pain when trying to restore from a feed in a different project but the same organization was certain settings of the consuming project... (sic. https://developercommunity.visualstudio.com/t/restore-nuget-task-unable-to-load-the-service-inde/1337219)
After adding the pipeline permissions to the NuGet feed (as per https://learn.microsoft.com/en-us/azure/devops/artifacts/feeds/feed-permissions?view=azure-devops#pipelines-permissions), you need to update the Limit job authorization scope... settings in the project which is restoring the feed.
I just spent nearly two days fighting this same NU1301 error, and while my ADO instance is cloud-based and the "latest", i.e., not exactly analogous to your situation, maybe my experience will shed some light.
The tldr; is that there were permission issues for the ADO "project" build service account accessing the "organization" Artifact feed. The output from the DotNetCoreCLI#2 restore task didn't even hint in that direction, but when I dropped-back to using the NuGet restore task, the error messages were more informative and helped me discover the underlying issue.
This info doesn't shed light on the guid/name swap issue you ask, but maybe the guid is an internal ID that is first used to then resolve the name, and if a permissions issue prevents even querying the Artifacts endpoint ...
As for the msbuild v17 comment, I would heed very carefully this advice and your trepidation about messing with the existing builds. To paraphrase that old quip ... it's not really paranoia, if MS has a well-established history of breaking stuff that has worked just fine for a very long time! ;-}
HTH.
SC
Here are the steps that helped me fix this same issue in Visual Studio.
Make sure that you have Owner or Contributor permissions to the Feed in Azure DevOps. Something like this:
Then in Visual Studio make sure that you are signed in using the account that has the permissions from the previous step.
Finally rebuild the solution.
Hopefully this fix your issue too!
I create a web project with Visual Studio.
I use GitHub desktop app to push my code to my Github
I create an Azure DevOps project throught the Azure portal to create a CI and don't change anything
When I commit a change all the CI run, the build is done with success and a new deployment is done.
To be sure everything work I did 2 differents tests
First : I created a new HTML file in my project with the other HTML files. When I commit, build and deployment run on Azure Devops without error, but I cannot see my new file in the wwwroot folder
Second : I updated a existing HTML file. When I commit, build and deployment run on Azure Devops without error, and I can see my update on the file present on the web app.
Why this difference ? I would like understood why update work correctly but not the add. I don't know where start to troubleshoot the issue
Could you please check the "build action" of the new .cshtml file?
In visual studio, right click on the file and go to properties.
Check if the build action is set to "Content", if not set it to content and commit.
Other build actions sometimes will not show any error but the view file will not be copied upon build. This is not Azure DevOps issue, rather visual studio filetype issue.
Let me know if this was the case. Good luck :)
I created an Azure Functions 2.0 (C#) project in VS 2017 and put it in GitHub. If I publish to Azure directly from VS, it works just fine. Then I accessed Azure Portal in order to configure Azure Functions, and there is this option to deploy from GitHub. I configured this option and when I commit something to GitHub, the Azure Portal detects and start some process (in Deployment Center there are logs with "success" status for each change I made in GitHub) but the code isn't deployed.
Any ideas?
Thanks, guys! I found the problem! I first published my solution directly from Visual Studio to Azure. Then, all functions became read-only, so build process did executed with success, but the files aren't updated.
I erased my functions app and recreated manually, and configured deployment with Kudu, getting from GitHub, and then everything works like a charm! Each commit in github updates my app!
Make sure Visual Studio is connected to GitHub to push the azure function
In the deployement center , you need to check that deployement is connected to github
You also need to check the Azure function version 2.
Step by steps guide Referenced from my article
Continuous Azure function deployement from Github using Kudu Build Server
I'm attempting to deploy a web site to Azure using VSTS. Basically, I commit code to the GIT repo and have it setup to run CI, so it begins building as soon as I commit. However, once it hits the release section, it never copies the code to the Azure web app, rather, it gives me this line:
Info: Updating file ({projectname}\error.txt).
It doesn't copy the files I changed, but rather always just copies this file. I checked and there is indeed an error.txt file in my website directory in Azure, but it is always blank.
This build/deploy process isn't "standard" because the build step only downloads from source code, it doesn't build, because the website isn't a "web application", but rather just a "web site", meaning it doesn't need to be built.
So my build step is as follows:
Get Sources
Run on Agent - this step is empty
so the idea is that it just downloads everything from source control, that's it.
Then, my release step is as follows:
Artefacts are from build step above
deploy to environment 1 (dev)
Azure app service deploy, using "package or folder" as $(System.DefaultWorkingDirectory)/
Any idea what I might be doing wrong here?
So I actually figured this out and will leave this here in case anyone else needs it.
I admit I'm pretty new to the Azure/VSTS world, so maybe someone else is making my mistake as well.
If you don't need to "build" your project, then don't. I resolved it by simply skipping the build step altogether. What I was really after was to just download the files from source control and deploy them as-is.
In your release editor, you can specify which "artifact" you want to use to release, and one of the options is source control, which is what I did.
This would be useful for websites like mine where you don't need to build them (mine is DNN/DotNetNuke, so you don't build it before deploying).
I am using Visual Studio Team Services for my Builds and Releases. I followed Microsoft's documentation here to set up my release definition to deploy every time a linked build is created (Continuous Deployment). However the trigger is not working.
My build definition simply follows the steps bellow:
NuGet Installer
Visual Studio Build
Copy and Publish Build Artifacts
My release definition's trigger is set up as Continuous Deployment and pointing to my release definition. The environment is set up with "Automated: after release creation"
My build completes successfully but the release is never triggered. I can kick of the release manually and it works fine. I would like the release to launch immediately from the build. Any ideas why this is not working?
Here are the steps I would take to troubleshoot your problem:
Double click on one of your successful builds and download the log file. At the bottom of the log file you will see where your build was published. Does it show that you have your artifacts in your build? Is there anything highlighted in yellow?
Do you have your release definition linked to your build?
Is the path to your web deployment package associated with your build?
When I was first setting things up, I had the same problem and this is what I did to fix it:
On the build solutions section of your build , be sure that your MS Build is set to: /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true
On your CopyFiles section be sure you have your contents going to a zip folder:
***zip
On your release definition, be sure your Web Deploy package is pointing at that zip file: $(System.DefaultWorkingDirectory)***.zip
There wound up being a Db entry problem with our VSTS account. This was fixed by the rm_customer_queries_at_microsoft_dot_com team.