I'm using the Hosted Agent for release management in Visual Studio Team Services. I have a cURL Upload Files task on my release definition which was working last week and I've had several successful deployments over the past weeks.
Today I created a new release from the same release definition and I am receiving the following error on the cURL Upload Files task.
2016-03-31T08:56:43.4253012Z ##[debug]curl=null
2016-03-31T08:56:43.4263027Z ##[error]curl was not found in the path.
2016-03-31T08:56:43.4303022Z ##[debug]task result: Failed
2016-03-31T08:56:43.4313025Z Return code: 1
I have checked the System Capabilities on the Hosted Agent and it lists curl C:\Program Files (x86)\Git\bin\curl.exe as one of them.
Any one have any ideas why this has suddenly started failing?
First, sorry about this. I'm with the product team and we’ve confirmed this is a regression on our side. cURL is still on the box but it is no longer in the path. We’re working on getting this fixed on our end but it’ll likely take a day or two. In the meantime, we’d recommend doing the following:
Before your curl task, create a new powershell task
Change the type of the task to be an “Inline Script”
Change the Inline Script input to be the following:
echo "##vso[task.setvariable variable=PATH;]$env:PATH;C:\Program Files\Git\usr\bin"
Save and queue a new build.
UPDATE: We've fixed this issue now. The workaround should be no longer necessary.
Related
Trying to create an archive to make a release apk of my app, and whenever I click archive all, it instantly says the archive is completed, nothing shows in the archive manager, and there are no errors or absolutely anything for that matter shown for output.
I suspect it may have something to do with the versions as I was able to archive previously, but once I changed versions, I believe that is when the issue started. Also, the app builds and runs with no issue.
I think the tooling for publishing and archiving is still work in progress. I'm not 100% up to date with the status though. However, if you run into these things please report it through the Visual Studio Help menu and choose Provide Feedback > Report a Problem.
That will make sure it goes to the right team with all the right information attached.
As a solution for you right now, the command-line does work. Everything needed to create a version is described in the docs: https://learn.microsoft.com/dotnet/maui/android/deployment/overview
I have come across the same issue I think I may have identified the what may be causing the problem:
I did the following:
Created a new .NET MAUI App with .NET 7.0 (Standard Term Support). Without
changing anything - I selected Archive All - this worked fine.
Changed the following project property:
Changed from:
I am trying to run msbuild command line, but, I am getting in the last step of it, the error below (it is in portuguese, but is the same error in the title.
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Xamarin\iOS\Xamarin.Shared.targets(227,3): erro
r MSB4044: A tarefa "GetMinimumOSVersion" não recebeu um valor para o parâmetro obrigatório "SdkVersion". [E:\2-PROJETO
S\_ALGORIX\Projetos\ACCORD\SOLUTION\AppAlgorix\AppAlgorix.iOS\AppAlgorix.iOS.csproj]
My msbuild command is:
msbuild AppAlgorix.sln /p:Configuration=AppStore;Platform=iPhone /p:CFBundleVersion=1 /p:CFBundleShortVersionString=2.3.1 /p:ServerAddress={mac ip address} /p:ServerUser={mac user} /p:ServerPassword={mac pwd} /p:BuildIpa=true /p:IpaPackageDir="E:\8-IPAS\ACCORD" /t:Clean;Build /p:ArchiveOnBuild=false /p:IsAppDistribution=false /p:CodesignKey="{App ID identifier}" /p:CodesignProvision="{App Provisioning Profile}"
All the {} data are confidential, so I cropped them.
This command was working one day, but I don´t know when, but after some VS 2019 update, the command, stops working.
I have found some articles about it, but I can´t find a way to resolve this problem.
Onw of those articles is this:
https://www.gitmemory.com/issue/xamarin/xamarin-macios/10109/729614745
My VS 2019 is updated in version 16.8.4.
I have here, about 40 apps to build and get the ipa. I was running a dosbat to resolve it, and get those ipas, more quickly. Not having this msbuild command line working, will take me to a big problem, cause I almost every week have some updates in my apps, and build one by one, will not be a great idea.
And one more thing is.. I can build inside VS 2019, without any problem. The problem happens only via msbuild command line.
I used the post Visual Studio update (16.8.1) lead to CI build failures to resolve the error.
"This has reared it's head again in Visual Studio 2019 version 16.8.3.
Looks like they've moved the problem to: \MSBuild\Xamarin\iOS\Xamarin.Messaging.targets I was able to get
my builds running again by removing the _SayGoodbye dependency on line
52 for the _DisconnectAfterClean target."
Although I have resolved the error, now I cant generate the ios.ipa package. Now, I get only the file projectName.iOS.exe, instead of projectName.iOS.ipa.
I dont know if this workaround is the final solution for this bug, yet.
We resolved this by running the build twice in-a-row. (continue on error - ignore the failed first build)
The first time always fails with the error in the question title, but it must somehow sets things up so that the second build has what it needs to succeed. The IPA is generated, etc.
IMPORTANT: DO NOT CLEAN BETWEEN THE TWO BUILDS
I know this solution is a hack workaround, but I prefer it to manually making changes to the .targets files as I have seen suggested elsewhere (those suggestions did not work in our case anyway). Making changes like that without knowing the internals of the build process intimately could result in unintended side-effects.
NOTE: As this solution involves an expected failed partial first build, it does add to the build time, but it was only about a minute or two longer per build, and at least it works reliably.
Hope this is helpful to someone! 🤗
We recently stood up a new Azure account and are in the process of developing a new application to be deployed to it as a web app. While we are able to deploy to our staging slot from Visual Studio 2015, when attempting to deploy an automated build from Visual Studio Team Services (hosted by Microsoft) we are getting the following error:
Get-AzureWebSite -Name $APPLICATION -ErrorAction SilentlyContinue -ErrorVariable azureWebSiteError -Slot staging
System.NullReferenceException: Object reference not set to an instance of an object.
at Microsoft.WindowsAzure.Commands.Websites.GetAzureWebsiteCommand.Do(Action call) in d:\workspace\powershell-publish\src\ServiceManagement\Services\Commands\Websites\GetAzureWebSite.cs:line 138
at Microsoft.WindowsAzure.Commands.Utilities.Common.AzureSMCmdlet.ProcessRecord() in d:\workspace\powershell-publish\src\ServiceManagement\Common\Commands.ServiceManagement.Common\AzureSMCmdlet.cs:line 174
New-AzureWebSite -Name $APPLICATION -Location North Central US -Slot staging
Conflict: Website with given name $APPLICATION already exists.
Publish-AzureWebsiteProject -Name "$APPLICATION" -Package "C:\a\1\a\$APPLICATION.zip" -Slot "staging" -ErrorVariable publishAzureWebsiteError
The website $APPLICATION was not found. Please specify a valid website name.
Cannot get website, deployment status is not updated
This is a fairly significant issue since it is preventing us from using continuous deployment at this time. Are there any work around or configuration settings that we should look at to fix this?
There is a known issue that causes publishing from VSTS to fail if the Web App has VS 2015 Debugging enabled. Can you check whether it is the case for you, and try again after turning off debugging in the Azure portal?
That issue will be fixed soon, so treat this as a temporary workaround.
This was eventually traced back to two problems.
The first problem was that we needed to load up a different management certificate since the one we were using was defaulting to a different account. This goes back to the issue of having one account associated with more than one subscription. At the time of this writing, there doesn't appear to be a way of specifying which subscription to download.
The second problem appears to have been associated with the known bug mentioned by David Ebbo in their answer.
A couple things you can try:
Since you mentioned you have 2 subscriptions, make sure that script you have above is running against the correct subscription, if it's not, it would give the exact error you're seeing. Put a:
Get-AzureSubscription -Current
command at the top of your script and see if that's what you'd expect.
VSTS has a build task for deploying to a web app, can you deploy the package using that task?
So our TFS 2013 builds do everything correctly except report code coverage. I've seen similar questions here, e.g. TFS 2013 - No Code Coverage Results, but we've already tried the suggested fixes with no results.
UPDATE 1 — we've taken more steps to try to resolve this; here's the complete list:
Ensured Visual Studio Ultimate was installed on the build server
Tried setting the build definition's "CodeCoverageEnabled" to true as well as the "Code coverage is enabled" setting
Ensured the build was using the Debug configuration and that PDBs were being generated for the DLLs to be tested
Added a .runsettings file with the correct ModulePath included under <CodeCoverage> (verified in build log that the module path was being interpreted correctly; it would produce errors if we intentionally malformed it)
Checked in .runsettings file
Set build definition to "Custom" and pointed to .runsettings file
The build process itself works fine. We can get code coverage results when we build the project locally in the IDE. On the build server, both MSTest and NUnit test projects run fine, and we see pass/fail results as expected. The "No Code Coverage Results" message still plagues us though.
Update 2 -
Here is what we see in the run log:
Somebody suggested homegrown code-coverage calculator in https://stackoverflow.com/a/16198120/141508, but it'd be a crime to spend $150 bazillion-thousand dollars on TFS 2013 & VS Ultimate 2013 with MSDN and still not have this one basic function working.
Add a run settings file to source control. Set the tests to custom and point to the run settings file. More info on using the .runsettings file can be found on msdn: http://msdn.microsoft.com/en-us/library/jj159530.aspx
I was experiencing the same problem. My issue was with the ModulePath. The MSDN examples suggest you can just use the name of a target binary. That was not working for me. However, when I made the name a regular expression, it worked. I am also dumping build output into one folder so that pdb and other reference files are found. Hope that helps.
<ModulePath>.*Administration\.dll.*</ModulePath>
I am using local build server with Visual Studio online with a .runsettings file and I had exactly the same issue.
None of the trickery above helped, so I tested the build script on the hosted build controller and it worked fine, so I decided the problem must be the build server itself.
I changed the Build Service account from "Network Service" to a regular windows user account in the TFS Configuration Tool and now code coverage is collected. Note that this user will need access to the TFS build directories.
I found this question because I saw something peculiar on this article. (Look for the "Delay" setting that defaults to 60).
d. Add a new argument ‘Delay’, enter details as mentioned below
Name – Delay, Direction – In, ArgumentType-Int32, Default Value – 60
This argument is required to delay coverage check, so that required build details are filled up by the build agent, this delay varies from
system to system, in some cases this might not be required at all.
http://www.prowareness.com/blog/failing-build-on-insufficient-code-coverageblock-coverage-part-3/
Maybe try putting in a "delay" work-flow item in the template you are using.......
We use Nant to automate our builds. Everything was working fine until about a week ago when the rains caused our power to go out and the build server had to be re-booted. Now, we get the following error whenever we attempt a build:
<internalerror>
<type>System.Runtime.InteropServices.COMException</type>
<message><![CDATA[SourceSafe was unable to finish writing a file. Check your available disk space, and ask the administrator to analyze your SourceSafe database.]]></message>
<stacktrace><![CDATA[ at SourceSafeTypeLib.VSSItemClass.Get(String& Local, Int32 iFlags)
at NAnt.Contrib.Tasks.SourceSafe.GetTask.ExecuteTask()]]></stacktrace>
</internalerror>
We ran the Analyze utility on the VSS database and there appears to be plenty of room on the build server, but no luck. Any ideas? I'm at a loss.
My problem was that the current file was empty... I wrote a comment on it and everything worked ok
Ok, here is the resolution. It turns out that somehow, the version of an app.config file that was referenced in the build script was corrupted (all the previous versions, actually), which caused the VSSGet error. Updating the version to the current version fixed the errror.
I had this issue when I tried to migrate a Source Safe database to Subversion, using VSS2SVN.
This error is related to the message
There is a diff chain size mismatch in file '' (bdaaaaaa) at version (versions earlier than that version can no longer be retrieved from the database).
that may be reported by the Source Safe tool analyze.exe.
If you look into the history of the file and try to Get a version that is older than the one reported by analyze.exe, the message of this question is shown.
Microsoft provided hotfix KB927887 for cases where this was caused by XML files toggling BOM inclusion, but I did not try to apply it.
See also Message: SourceSafe was unable to finish writing a file