reactiveui
System.InvalidOperationException: IMyInterface doesn't look like a Refit interface in builds on Azure DevOps
Recently, we are seeing very strange behaviour with our builds on Azure DevOps. Consistently, our PR builds (usually built from a feature/ branch in Azure DevOps) produce a DLL without the generated code by Refit. This results in a runtime error:
System.InvalidOperationException: IMyInterface doesn't look like a Refit interface.
Using dotPeek, I can see that one DLL has the generated code, the other one doesn't.
In most cases, the (exact same) build pipeline would produce a working version of the DLL from the master branch. However that is also flaky, and recent builds are all broken.
I'm not sure if this qualifies as a bug, but can someone perhaps point out where to look for more details and how to find the root cause? At first I thought, it started happening after updating of the Refit nuget package, but after downgrading to a version where the build used to work (6.0.24), the problem persists. So we're thinking it's related to something on the Azure DevOps build agent. Does the Analyzer pick up some environment settings and disable the code generation?
Steps To Reproduce
We are building our project from an Azure DevOps (YAML) pipeline, using dotnet build and dotnet publish.
Expected behavior In both cases, Refit should generate the code.
Environment Agent info from one of the failing builds:
Update: downgraded all the way to Refit 5.2.4. That works.
So what is different in 6.x that could behave differently on hosted builds?
Also seeing the same problem, locally 6.x.x works perfectly, just not on Azure DevOps :/
It's really inconsistent. Had a few successful builds, but now it's failing again. This particular version was upgraded to .NET 6.0
We have the same issue. In august a project with Refit 6.0.15 was getting built without issues, if we run a build on the exact same code today, the generated classes are not present in the build output.
Locally, everything works as expected even with the same version of the .NET CLI
Update: we disabled SonarQube analysis in our build pipeline which caused it to work again. Could it be that some of the Refit analyzers / source generators conflict with those from SonarQube? If so, can this be looked into please?
@rob-hendrickx-c4t Interesting, indeed we also have SonarQube on our builds. It might just be that the builds that did produce working code had it disabled (SonarQube doesn't run on manually triggered builds).
@rob-hendrickx-c4t that is interesting...we also have SonarQube running on our CI build pipeline, I will try disabling them also.
Can we close this? Looks like the culprit is SonarQube interfering with Source Generators?
I don't think it can be closed, it works on the older versions so something different in the source generators is not compatible. This is preventing us from upgrading Refit across a large number of repos.
Yeah I guess there is nothing that can be done about it in Refit, so let's close it. I'll contact the SonarQube folks to see if there's a fix.
@nuttytree if a third party is interfering with source generators, there's nothing refit can do about it. The other thing is breaking a core part of the build pipeline.