Problems with CRLF line endings

We as a multi-developer team are using git version 2.31.0.windows.1 on the developer side which we use through Git Bash on Windows 10. On the server side we use Azure Dev Ops. Approximate 20 developers are working from one repository. We want all files to use CRLF line endings with working with the files. All the developers have a .bashrc file with contents of "git config --global core.autocrlf true". Additionally, the repository with a .gitattributes file with contents: *.raml text eol=crlf *.json text eol=crlf *.vb text eol=crlf *.cs text eol=crlf *.vbproj text eol=crlf *.csproj text eol=crlf The problem we are having is that when pulling branches from the repository we still have recurring files with phantom changes. We have told developer who experience this to either reset the indices cache and do a hard reset or renormalize and check in and push as indicated in a number of web sites. But it still seems to be happening. Our repository has a release branch and a develop branch and the problems seems to be happening with mainly develop which has more developer traffic.

It seems inconsistent on changes, The file will download with all CRLF endings but the file is marked as modified and it is not clear what has changed.

Does anyone have recommendations on how we can get this to work (always CRLF) without the phantom changes occurring in an apparently non-deterministic manner? Have I configured this completely?

The problem may be that one or more developers have not updated their local indices. Also would it help to have everyone do a one-time reclone the repository?

One file marked as modified has $ git ls-files --eol | grep WCAPI.Core/WCAPI.Core.csproj i/crlf w/crlf attr/text eol=crlf WCAPI.Core/WCAPI.Core.csproj

and a similar one not marked as modified has

$ git ls-files --eol | grep WCAPI/WCAPI.csproj i/lf w/crlf attr/text eol=crlf WCAPI/WCAPI.csproj

Why does the modified one have 'i/crlf' and the unmodified ones have 'i/lf'

Any help would be appreciated.