I have a project that was using the VS 2017 agent pool in Azure devops and building without issues. In order to use features from newer versions of C#, this has been updated to the windows-2019 Agent specification. Suddenly, the build step fails with errors following the Running Code Analysis line. Looking at the errors in the default ruleset in Visual Studio, they are all marked as warnings rather than errors so shouldn't be causing the build to fail
There are too many issues to fix right now, as this is an older project. Apart from creating a custom ruleset that disables all of these rules, is there a way to keep the new features of Windows-2019 without having code analysis fail the build?
In answer to the comment question, this is not a yaml pipeline, but done in the legacy UI
This is known issue with Visual Studio 16.8. Here is the ticket with the same issue on github.
You can try workarounds provided by this link:
Please set ‘CodeAnalysisTreatWarningsAsErrors’ property to false if
you prefer CA warnings not to be treated as errors:
https://learn.microsoft.com/dotnet/fundamentals/code-analysis/overview#treat-warnings-as-errors
If you are running legacy binary FxCop: ‘RunCodeAnalysis’ property
is used for executing deprecated binary FxCop based CodeAnalysis.
Please refer to
https://learn.microsoft.com/visualstudio/code-quality/fxcop-analyzers-faq?view=vs-2019#does-the-runcodeanalysis-msbuild-project-property-run-analyzers.
The default value for the property is false, so you should consider
just removing this property from your project file OR setting it
explicitly to false. Please consider migrating from legacy
CodeAnalysis to source based CodeAnalysis:
https://learn.microsoft.com/visualstudio/code-quality/migrate-from-legacy-analysis-to-fxcop-analyzers?view=vs-2019
Related
I just upgraded to the C++ 4.7.2 runtime source and when I build in Xcode, I get the warning
_startToken(startToken) will be initialized after _deleteConfigs(deleteConfigs)
This is in the second constructor of NoViableAltException.
Obviously I can fix this locally (warnings are considered errors in my environment) but this should probably be propagated back into the source tree. I've no idea who does that.
You usually fork ANTLR4 on Github, make your changes and create a pull request from that. You need to have a Github account for that.
However in such a simple case I can probably do the change(s), just give me a patch.
What is the best practice for using runtime version given that the runtime introduced breaking changes, and using specific version will cause issue given that runtime will be removed regularly.
https://github.com/Azure/app-service-announcements-discussions/issues/90
Please let me explain below:
Scenario 1:
When below is used,
FUNCTIONS_EXTENSION_VERSION =~2
Our code broke with the latest runtime. Because ~2 means it uses the latest version.
https://github.com/Azure/azure-functions-host/issues/4203
Scenario 2:
However, when below is used,
FUNCTIONS_EXTENSION_VERSION = specific version
Our code brok again with the latest runtime. Because the specified runtime is removed by Azure Functions, and the latest runtime with breaking changes is used instead,
https://github.com/Azure/app-service-announcements-discussions/issues/90
Again, what is the better way to reduce the error?
Updates
In terms of time frame, how a latest runtime works when it is publicly downloadable and it is rolled out on Azure Functions? For example, how advance is the runtime available before it is rolled out to Azure fucntions?
How long will an old runtime be kept for on Azure Functions after latest runtime rollout? Based on what factors are an old runtime decided to be deteled?
The best and recommended practice is to use the latest. It is a rare occurrence, but unfortunately, a regression was introduced with a new release impacting your app.
If you want to perform validation on new versions, the recommendation is to:
Subscribe to new release notifications at
https://github.com/Azure/app-service-announcements/issues
Pin yourself to the current release you've validated against
As a new version is introduced, update a test environment to adopt that new version (or have a test environment that auto updates, using ~2). If you have a test environment set with auto-updates and automated tests, this makes the process significantly simpler.
Once validated, update the production environment to that new version
If you find an issue, reporting allows us to ensure we don't remove
the version that works.
We always maintain the newly deployed version and the previous release, and, aside from hotfixes and small ad-hoc deployments, the release cadence is ~2 weeks. Anything that has been flagged as a version that needs to be kept due to issues intruduced by a release (forcing customers to pin) is also kept.
I am working on a project to develop an Azure DevOps release task extension. Recently, I am getting this warning message printed multiple times in the logs when the release task runs- "Warning: Use Cipheriv for counter mode of aes-256-ctr".
I was not getting it earlier. And the time when I started getting this error, I only changed some console.log(..), and not even any code that could possibly trigger this error. (Might be some npm dependency updates!)
Any idea regarding why am I getting this error, and how to fix it! If not, how to disable it?
P.S. - I know this question has been asked and could probably be categorized as duplicate. But I am asking in the context of Azure DevOps release tasks, others are independent node.js projects. And, those fixes didn't work for me.
This is related to the Azure-Pipelines-Task-Lib and the Azure-Pipelines-agent and outside of your control. The problem should be fixed in those projects or their dependencies.
Since these all ship with the agent installer and the tasks themselves, this is not directly under your control.
This is likely caused by the dependency of the Agent on Node 6. There is work in progress to support Node 10 LTS on the agent (Node 10 now ships side-by-side in the agent installer).
The Azure-Pipelines-Agent calls the wrong method here.
let encryptKey = crypto.randomBytes(256);
let cipher = crypto.createCipher("aes-256-ctr", encryptKey);
let encryptedContent = cipher.update(secret, "utf8", "hex");
encryptedContent += cipher.final("hex");
As far as I can tell it should call crypto.createCipheriv() instead of crypto.createCipher() when running on Node 8 or higher. The Azure-Pipelines-Task-Lib seems to rely on the same piece of code.
It looks like 2.8.0 of the Azure-Pipelines-Task-Lib fixes this. It's on npm now, so upgrade to make these warnings disappear.
I’m on a .net c# project composed by a solution with several class library projects.
The source control is managed by git using gitflow as branching model.
We have decided that we wanted to implement semantic versioning (http://semver.org/) of the project in order to follow a standard way to communicate our releases.
For that we are using GitVersionTask (via NuGet) which works pretty well with gitflow.
Every time we tag a release and we perform a build from the master branch the version of all assemblies are updated and a new release is out for delivery.
Only one of the assemblies has a public API, all the other are for internal consume. I would like to know if this is the correct way to manage the version of multiple assemblies of the same project I mean, isn’t it wrong to change the version of every assembly when only a couple (or even just one) was changed? To get thinks more complicated there is strong possibility that some of the “internal” assemblies will be used by other projects so I believe it not very wise to increment a major version of an assembly that didn’t suffer a change just because another assembly of the same project is promoting breaking changes. Should each assembly project be managed on its own repository?
Thanks in advance.
I know this is a bit of an old question, still:
I want to share a workaround that seems to be working:
GitVersion uses $(Build.SourcesDirectory) to see where the sources are located - src
We can change this using logging commands*
Workaround is to set the Build.SourcesDirectory before GitVersion task
Then gitVersion uses the GitVersion.yml from the project folder (Build.SourceDirectory) and voila - works
After that you might want to roll back the change or not - depending on your need. For me it seems it is nice to scope down to the only nuget package from the collection of nuget packages in our nugetPackages monorepo.
see GitVersion issue and comment
*Example Powershell command:
standard PowerShell task; set to inline script;
Write-Host "##vso[task.setvariable variable=Build_SourcesDirectory;]$(Build.SourcesDirectory)\$(NugetProjectName)"
There is certainly nothing in GitVersion that would help with having separate projects within the same repository. The guidance that we would offer here is that you should use different repositories for the different parts of your application. That way they can be versioned/updated at their own cadence.
I've set up a new Visual Studio 2012 Database Project to hold the assets for a database and I'm having problems getting the project to build properly. The issue that I'm facing is that we have custom code within our database scripts that does certain evaluations when executed. This is by design, and works well. However because it's more complex than the standard database script (for say a table) the project won't build. I'd like to turn off the validation so that the project can build and deploy without being failing the build. Is there a way to turn off the validation portion of the project? I'm new to working with DB project types in VS, so not sure what all may be available. Any other strategies or work-arounds are also welcome.