Race condition when using C# 9.0 source generators

[pjgpetecodes]

Current behavior

Building a Hello World project in VS Code on Windows results in a build error;

error CS1061: 'MainPage' does not contain a definition for 'InitializeComponent' and no accessible extension method 'InitializeComponent'

Oddly, if I open the project in VSCode and immediately build it works... If I leave it until VS Code has finished loading everything up then it doesn't.

Building using a terminal (Both PowerShell and CMD) results in the same issue.

I've attached a binlog as requested.

I also tried a dotnet clean before a build with the same results in VSCode and a command prompt.

Expected behaviour

Build successfully.

How to reproduce it (as minimally and precisely as possible)

dotnet new --install Uno.ProjectTemplates.Dotnet::3.5.0-dev.105
dotnet new unoapp -o uno1
cd uno1\uno1.Skia.Gtk

• Open Project in VS Code
• Open new terminal in VS Code

dotnet build

Interestingly... If I try to build the project from the command line (External command prompt), with VSCode open, then the build fails as above. But, closing VSCode and simply building again works.

I wonder could this be a plugin issue? Or even an issue with Omnisharp maybe?

Workarounds

1. Downgrade the C# extension to 1.23.0 as suggested by @microhobby
2. Build immediately after opening project in VSCode (before the C# extension has time to load I guess).
3. Add the following to the csproj files as suggested my @jeromelaban;

<PropertyGroup>
  <UnoUIUseRoslynSourceGenerators>false</UnoUIUseRoslynSourceGenerators>
</PropertyGroup>

Environment

Dot NET: 5.0.102
Uno UI: 3.5.0-dev.105
Windows 10 Pro 19042.746

Build Task:

{
            "label": "build",
            "command": "dotnet",
            "type": "process",
            "args": [
                "build",
                "${workspaceFolder}/uno.Skia.Gtk.csproj",
                "/property:GenerateFullPaths=true",
                "/consoleloggerparameters:NoSummary"
            ],
            "problemMatcher": "$msCompile"
        },

Nuget Package:

• Uno.UI / Uno.UI.WebAssembly / Uno.UI.Skia
• Uno.WinUI / Uno.WinUI.WebAssembly / Uno.WinUI.Skia
• Uno.SourceGenerationTasks
• Uno.UI.RemoteControl / Uno.WinUI.RemoteControl
• Other:

Nuget Package Version(s):

• Microsoft.Extensions.Logging.Console: Version="1.1.1"
• Microsoft.Extensions.Logging.Filter: Version="1.1.1"
• Uno.UI.Skia.Gtk" Version: "3.5.0-dev.105"
• Uno.UI.RemoteControl" Version: "3.5.0-dev.105"

VS Code Extensions;

• Azurite.azurite
• cweijan.vscode-ssh
• derivitec-ltd.vscode-dotnet-adapter
• eamodio.gitlens
• estivo.csv-editor
• hbenl.vscode-test-explorer
• hbenl.vscode-test-explorer-liveshare
• humao.rest-client
• k--kato.docomment
• ms-azure-devops.azure-pipelines
• ms-azuretools.vscode-azurefunctions
• ms-azuretools.vscode-azurestorage
• ms-azuretools.vscode-docker
• ms-dotnettools.csharp
• ms-dotnettools.vscode-dotnet-runtime
• ms-mssql.mssql
• ms-python.python
• ms-toolsai.jupyter
• ms-vscode-remote.remote-containers
• ms-vscode-remote.remote-ssh-edit-nightly
• ms-vscode-remote.remote-ssh-nightly
• ms-vscode-remote.remote-wsl
• ms-vscode-remote.vscode-remote-extensionpack
• ms-vscode.azure-account
• ms-vscode.cmake-tools
• ms-vscode.cpptools
• ms-vscode.hexeditor
• ms-vscode.js-debug-nightly
• ms-vsliveshare.vsliveshare
• ms-vsliveshare.vsliveshare-audio
• ms-vsliveshare.vsliveshare-pack
• msazurermtools.azurerm-vscode-tools
• mtxr.sqltools
• mtxr.sqltools-driver-mysql
• octref.vetur
• platformio.platformio-ide
• ritwickdey.LiveServer
• Shan.code-settings-sync
• Summer.azure-event-hub-explorer
• vsciot-vscode.azure-iot-edge
• vsciot-vscode.azure-iot-toolkit
• vsciot-vscode.azure-iot-tools
• vsciot-vscode.vscode-arduino
• vsciot-vscode.vscode-dtdl
• vsciot-vscode.vscode-iot-device-cube
• vsciot-vscode.vscode-iot-workbench

Affected platform(s):

• iOS
• Android
• WebAssembly
• WebAssembly renderers for Xamarin.Forms
• macOS
• Skia
  • WPF
  • GTK (Linux)
  • Tizen
• Windows
• Build tasks
• Solution Templates

IDE:

• Visual Studio 2017 (version: )
• Visual Studio 2019 (version: )
• Visual Studio for Mac (version: )
• Rider Windows (version: )
• Rider macOS (version: )
• Visual Studio Code (version: 1.52.1)

Relevant plugins:

• Resharper (version: )

Anything else we need to know?

• I've made sure to uninstall any old versions of Uno...
• I've tried dotnet clean before building.

binlog:

msbuild.zip

[microhobby]

@pjgpetecodes oh boy, I was having the same issue here, glad to Know that is not only on my environment. But it seems to me that the root cause is not Uno. Latest versions of omnisharp are breaking Roslyn in some way. Uno use Roslyn source generators to generate XAML code behind. Using omnisharp 1.23.8 results in very intermittent builds, sometimes successful and often errors.

A workaround I tested here is to downgrade omnisharp to version 1.23.0. Let me know if this works on your side. If it works it may be the case to collect more evidence and open an issue on omnisharp.

[pjgpetecodes]

@pjgpetecodes oh boy, I was having the same issue here, glad to Know that is not only on my environment. But it seems to me that the root cause is not Uno. Latest versions of omnisharp are breaking Roslyn in some way. Uno use Roslyn source generators to generate XAML code behind. Using omnisharp 1.23.8 results in very intermittent builds, sometimes successful and often errors.

A workaround I tested here is to downgrade omnisharp to version 1.23.0. Let me know if this works on your side. If it works it may be the case to collect more evidence and open an issue on omnisharp.

Ooo... I had a sneaky feeling that this was an issue with Omnisharp for sure... I'll give that workaround a go and let you know... Thanks!

[pjgpetecodes]

@pjgpetecodes oh boy, I was having the same issue here, glad to Know that is not only on my environment. But it seems to me that the root cause is not Uno. Latest versions of omnisharp are breaking Roslyn in some way. Uno use Roslyn source generators to generate XAML code behind. Using omnisharp 1.23.8 results in very intermittent builds, sometimes successful and often errors.
A workaround I tested here is to downgrade omnisharp to version 1.23.0. Let me know if this works on your side. If it works it may be the case to collect more evidence and open an issue on omnisharp.

Ooo... I had a sneaky feeling that this was an issue with Omnisharp for sure... I'll give that workaround a go and let you know... Thanks!

Yes... This works @microhobby... Thanks!

It took a couple of goes for the downgrade to take mind you... I dunno if it's related to this issue... dotnet/vscode-csharp#3891

[microhobby]

@pjgpetecodes thanks for confirming, I have no idea what may have changed that is breaking Roslyn, but it would be good to open an issue in the omnisharp project. I will see if I can gather some logs to open this at the beginning of the week, or of course fell free to open it if you want to.

[jeromelaban]

Interesting issue. It's likely that OmniSharp is having a race condition issue with the generated editorconfig file, as there's no coordination between what omnisharp is doing, and builds done through the command line.

Can you try adding this:

<PropertyGroup>
  <UnoUIUseRoslynSourceGenerators>false</UnoUIUseRoslynSourceGenerators>
</PropertyGroup>

to your project ?

See this code for reference:

uno/src/SourceGenerators/Uno.UI.SourceGenerators/Content/Uno.UI.SourceGenerators.props

Line 23 in 10528e1

<When Condition="'$(UnoUIUseRoslynSourceGenerators)'=='true'">

It may be something that needs to be reported to the Roslyn team, I'll dig further.

[pjgpetecodes]

Interesting issue. It's likely that OmniSharp is having a race condition issue with the generated editorconfig file, as there's no coordination between what omnisharp is doing, and builds done through the command line.

Can you try adding this:

<PropertyGroup>
  <UnoUIUseRoslynSourceGenerators>false</UnoUIUseRoslynSourceGenerators>
</PropertyGroup>

to your project ?

See this code for reference:

uno/src/SourceGenerators/Uno.UI.SourceGenerators/Content/Uno.UI.SourceGenerators.props

Line 23 in 10528e1

<When Condition="'$(UnoUIUseRoslynSourceGenerators)'=='true'">

It may be something that needs to be reported to the Roslyn team, I'll dig further.

Thanks Jerome! That seems to work with the latest C# Extension installed now... It feels slower to build now, but that might just be me imagining it! Ha.

Thanks again!

[jeromelaban]

Thanks for the update!

Yes, building without the C# 9.0 generators is somewhat slower, that's one the reasons for Uno to move to this new generators framework. I'm waiting to see if the roslyn team has a cue on this.

[microhobby]

@jeromelaban it works very well and I would say it works better for those who use VS Code. With Roslyn so far to work with the IntelliSense and code tips for code behind I had to use the <EmitCompilerGeneratedFiles>true</EmitCompilerGeneratedFiles>, and this is not well documented and has some bugs yet . But using the <UnoUIUseRoslynSourceGenerators>false</UnoUIUseRoslynSourceGenerators> the XAML code behind is generated always in obj/Debug/net5.0/g. Thank you for letting us know about it.

[microhobby]

Another note about this. Using <UnoUIUseRoslynSourceGenerators>false</UnoUIUseRoslynSourceGenerators> and publishing apps for other runtime architectures, in my case arm and arm64, generates duplicate code within obj/Debug/net5.0/ for each runtime architecture. So, the omnisharp starts to complain about ambiguous definition.

Maybe a solution is add <Compile Remove=".\obj\Debug\net5.0\linux-arm64\**\*.cs" /> on the .csproj

[jeromelaban]

Related issue: dotnet/roslyn#51768

[jeromelaban]

This is fixed in uno 4.0+ builds.