Closed Junjun-zhao closed 1 month ago
@marcpopMSFT Could you please take a look at this bug and help triage it? Meanwhile, could you help confirm if this is a RC2 blocker? Thanks.
Those are all c# errors/warnings and you should follow up with @jaredpar and @arkalyanms
Thank you, @marcpopMSFT .
Hi @jaredpar and @arkalyanms, this issue was found during source compat testing, could you please take a look at it and confirm if this RC2 blocker? Thanks.
Can you include the compiler log as well? That will make it easier for us to reproduce the compilation errors.
While the compilation errors are interesting and I'd like to take a look at them it's unlikely to be a compiler bug. By the error it looks like possibly bad code gen or ambiguity between namespace and types: compiler log will let us dig into that. The root cause is we are adding another generator where we weren't previously. Is that intended @marcpopMSFT, @baronfel? Think we should be looking into that.
Hi @jaredpar ,
No compilations added after executing the command.
@Junjun-zhao can you use the --all
option when creating the log?
complog create --all msbuild.binlog
This error is in the WPF temporary project and that is excluded by default. Have to use --all
to get that included.
Hi @jaredpar, No compile log is generated either.
C:\Users\AppCompat\Desktop\AppSources\Text-Grab\Text-Grab>complog create --all msbuild.binlog
Missing file, either build did not happen on this machine or the environment has changed:
cc @Sergio0694 and @manodasanW on this one as well
Mmh this does look like to be an actual issue. @Junjun-zhao would you be able to share those generated files?
Junjun mentioned that no compile logs were generated. My team(Junjun) is based in China and it is already weekend there, so it might be better to look at the repro machines to further investigate. Repro machine details are in the DevDiv bug https://devdiv.visualstudio.com/DevDiv/_workitems/edit/2261837 and VPN is needed to connect to the VMs. Please ping me if you have trouble accessing the DevDiv work item and I can share repro machine details over Teams.
This looks like we are not escaping the assembly name for all scenarios when we used it in generated sources. We have logic to escape it, but it doesn't handle dashes.
This is tracked by https://github.com/microsoft/CsWinRT/issues/1800
Thanks @jaredpar @manodasanW. Could I know what release this fix will be merged into? As we are going to sign off the validation for RC2, is it a blocker for it?
Thanks @jaredpar @manodasanW. Could I know what release this fix will be merged into? As we are going to sign off the validation for RC2, is it a blocker for it?
@Junjun-zhao Jared's team doesn't own these fixes. There are discussions going on about these fixes and associated timelines in Teams. Richa and others are aware of these issues. We need to wait for decision/update. I will let you know once an update is available in the RC2 Teams chat.
There is a workaround for this issue which is to set the below property inside of a PropertyGroup
in your csproj or props file.
<CsWinRTAotOptimizerEnabled>false</CsWinRTAotOptimizerEnabled>
Once the fix is also available in the Windows SDK projection published to NuGet, someone can also explicitly set WindowsSdkPackageVersion
property to explicitly pull in the fix until it is available in the .NET SDK by default.
This is also fixed in the updated Windows SDK projection package. Someone can get the fix to try with the repro before it is available in the .NET SDK by putting the below WindowsSdkPackageVersion
property in Text-Grab.csproj
or a common props file.
<WindowsSdkPackageVersion>10.0.20348.48</WindowsSdkPackageVersion>
Thank you @manodasanW. We verified the issue with WindowsSdkPackage#10.0.26100.48, it has been fixed.
I've hit a similar issue with the following error:
##[error]C:\a\1\s\src\Uno.UI.RuntimeTests\obj\Uno.UI.RuntimeTests.Windows\x64\Release\net8.0-windows10.0.19041.0\win-x64\intermediatexaml\WinRT.SourceGenerator\Generator.WinRTAotSourceGenerator\WinRTGenericInstantiation.g.cs(25,109):
Error CS0122: 'NotifyCollectionChangedAction' is inaccessible due to its protection level
Worked around with <CsWinRTAotOptimizerEnabled>false</CsWinRTAotOptimizerEnabled>
.
Unfortunately the October patches for the .NET SDKs (6.0.427, 8.0.403) broke several of our pipelines with errors such as:
WinRT.SourceGenerator\Generator.WinRTAotSourceGenerator\WinRTGenericInstantiation.g.cs(5453,23): error CS0101: The namespace '<global namespace>' already contains a definition for 'IList_double' [Report_uksuilbe_wpftmp.csproj]
obj\x64\Debug\WinRT.SourceGenerator\Generator.WinRTAotSourceGenerator\WinRTGlobalVtableLookup.g.cs(5,24): error CS0116: A namespace cannot directly contain members such as fields, methods or statements
As previously mentioned setting <CsWinRTAotOptimizerEnabled>false</CsWinRTAotOptimizerEnabled>
seems to work around this issue.
@manodasanW @marcpopMSFT Verified this issue with the latest build dotnet-sdk-9.0.100-rtm.24515.15, it has been fixed. Thanks
Application Name: Text-Grab OS: Windows 10 21H2 CPU: X64 .NET Build Number: dotnet-sdk-9.0.100-rc.2.24470.13 Source location or Repro machine checking at: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/2261837 Github Link: https://github.com/TheJoeFin/Text-Grab
Verify Scenarios: 1). Windows 10 21H2 AMD64 + dotnet-sdk-8.0.401(default target net8.0): Pass 2). Windows 10 21H2 AMD64 + dotnet-sdk-9.0.100-rc.1.24452.12(default target net8.0): Pass 3). Windows 10 21H2 AMD64 + dotnet-sdk-9.0.100-rc.2.24470.13(default target net8.0): Fail 4). Windows 10 21H2 AMD64 + dotnet-sdk-9.0.100-rc.2.24470.13(retarget net9.0): Fail
Description: When retargeting the 3rd party application to net9.0 and build with the latest .NET 9 sdk, it failed with errors:
App Repro Steps: The machine has dotnet-sdk-9.0.100-rc.2.24470.13 installed. Please get the repro machine information from devdiv bug 1.Open command prompt window and navigate to Text-Grab folder where Text-Grab.sln file in.
dotnet new globaljson
" to create global.json file and make sure the assigned dotnet sdk version is 9.0.100-rc.2.24466.31:dotnet build
" command.Expected Result: Build successfully.
Actual Result: Build failed with 190 errors (duplicated 5 errors):
Findings: (Please refer to binlog files on repro machine: C:\logs or attached buildlog.zip)): After comparing the binlog between 9.0.100-rc.1.24452.12 and 9.0.100-rc.2.24470.13, the 9.0.100-rc.2.24470.13 has an additional Analyzer assembly used.
Dotnet Info:
@dotnet-actwx-bot @dotnet/compat