upgrade to version 6 of the Arcade sdk

[jmarolf]

No description provided.

[dibarbet]

From the thread I see, the suggestion was to use arcade 6 due to lts support which 5 didn't have, any reason not to do 6?

[jmarolf]

I just want to confirm that the CI succeeds for 5 first. upgrading to 6 is trivial if folks decide we should

[jmarolf]

/azp run

[azure-pipelines]

Azure Pipelines could not run because the pipeline triggers exclude this branch/path.

[jaredpar]

Problem is we specifically cannot take 5 because it doesn't meet our servicing requirements. If it's trivial to do 6 then why aren't we starting with upgrading to 6?

[jmarolf]

Problem is we specifically cannot take 5 because it doesn't meet our servicing requirements. If it's trivial to do 6 then why aren't we starting with upgrading to 6?

6 will require us to use .NET 6 SDK Preview 1. Thats a big ask on the team (and contributors). I've updated to Arcade 6 to see what it looks like. Appears that there is a VB compiler bug I need to dig into.

##[error]src/Compilers/Test/Utilities/VisualBasic/CompilationTestUtils.vb(1217,22): error BC30455: Argument not specified for parameter 'Number' of 'Public Function Str(Number As Object) As String'.

[RikkiGibson]

That looks like the same oddity we were seeing in #51596

[jaredpar]

Appears that there is a VB compiler bug I need to dig into.

That's not a VB compiler bug but a sign that a bad version of MS.VB.dll is being used.

[jmarolf]

That's not a VB compiler bug

Its never a compiler bug :)

[RikkiGibson]

I popped open the Microsoft.VisualBasic.dlls for net472 in both the 1.0.0 and 1.0.0-preview1 ref assemblies packages. The member Microsoft.VisualBasic.Conversion.Str(object) is present in both and appears identical.

I don't know what else we should try to track this down. It does look to me like we need to do something about this, though.

[jaredpar]

@RikkiGibson

The member Microsoft.VisualBasic.Conversion.Str(object) is present in both and appears identical

Guessing this specific error message is a red herring. A lot like when overload resolution fails and the compiler spits out the error message in relation to the "best option".

Consider that we don't actually use Str in the compiled code at all as evidence here.

I don't know what else we should try to track this down.

Think you'd need to find the real error here. What other error could possibly cause VB to fall back to the Str helper? That is likely the real problem.

It does look to me like we need to do something about this, though

I'd put the urgency on this low. The current use of the preview-1 reference assemblies works fine. I'm not sure why we're conflating it with a move to Arcade 6.

[RikkiGibson]

The current use of the preview-1 reference assemblies works fine.

It seems that the new netframework reference assemblies are coming along for the ride implicitly when moving to arcade 6. So perhaps we should figure out why the new version is getting picked up instead of our version. Maybe a property in Versions.Props has been renamed on the Arcade side, for example.

[jaredpar]

Maybe a property in Versions.Props has been renamed on the Arcade side, for example.

True. Seems probable.

If that is the single VB error though we could also just focus on figuring out what that is and moving past it. It's ringing a bell deep in my brain but having trouble paging it in at the moment.

[jaredpar]

It's ringing a bell deep in my brain but having trouble paging it in at the moment.

Paging operation complete. One of the following is happening:

1. The new arcade is adding new global Import statements to MS.VB projects, one of which is Microsoft.VisualBasic
2. The new arcade is adding a reference to a version of Microsoft.VisualBasic which wasn't there before

The result though is str here is being treated like the Module member Microsoft.VisualBasic.Conversions.Str not an identifier which is how we're reading it.

Simple repro of the problem is here. Delete the Import Microsoft.VisualBasic and the code will compile

https://sharplab.io/#v2:EYLgtghgzgLgpgJwDQBsQDdhJiAligHwEkwAHAewRigAIBlAT1jjAFgAoEiq2gWVwDGCclHIAzGADoAarigBXCCgBC0QRw69yAE3ko4NXhxomaABXnAUgmgDF5AOwExc5B/UowAgg+29EAOZwdDAIuA4BUAAUZhAIEGBeCPEMNLBhEbRetCEZAVEAlAU02fSh4QHGptVJKZJ0nlHpFVAFGuzV1baUNACiEAIAFmmhNETuzZlVnZ0Awm6i+pIA6mHwADLhcE2hbR00050AcnAAHjDt1QhwMPII7kfkMIMVh72+do7Org4c79qGHR6OBAA

[RikkiGibson]

@jmarolf was just telling me, IIRC, that when the build succeeds it is pulling MS.VB.dll from the system's framework folder, and when it fails it's pulling from the NuGet package. Perhaps examining the package references will shed a little light?

[jmarolf]

@jaredpar so I assume the fix is to update arcade to not import this automatically?

[jaredpar]

when the build succeeds it is pulling MS.VB.dll from the system's framework folder

What is the system folder in this case?

so I assume the fix is to update arcade to not import this automatically?

Don't know. I would take a quick look and see how it's being built today. Build that assembly, crack open the binary log and see what global Import are being specified and what references are being passed. Then do the same for Arcade 6 so we know what's happening here.

[jmarolf]

Alright, after a brief sojourn with Dante, I think this is working now. Queued a signed build to verify nothing else is horribly broken

[jaredpar]

What was the resolution of the str issue in the VB projects?

[jmarolf]

What was the resolution of the str issue in the VB projects?

We were getting moved to version 1.0 of Microsoft.NETFramework.ReferenceAssemblies instead of 1.0.0-preview.1

[jmarolf]

It seems updating to arcade 6 somehow causes us to run headlong into the brick wall that is #48816. @sharwell if you want a 100% local repo here is it. How have you been investigating these hangs?

[jaredpar]

We were getting moved to version 1.0 of Microsoft.NETFramework.ReferenceAssemblies instead of 1.0.0-preview.1

Yes but why is that an issue? The MS.VB.dll in 1.0.0 and 1.0.0-preview.1 is basically the same from what I can see. Both have Conversions.Str and hence that should not explain the issue here.

[jmarolf]

Yes but why is that an issue? The MS.VB.dll in 1.0.0 and 1.0.0-preview.1 is basically the same from what I can see. Both have Conversions.Str and hence that should not explain the issue here.

I have the commandline args to vbc and its a smoking gun. Pass 1.0 reference assemblies get the error, pass preview and build succeeds. The fix was to pin the preview versions and the build succeeds. There are two follow up items here:

• Why are the arcade targets picking the release version of these references when it explicitly states that preview versions should be used? (Tracked with Arcade 6 forces consumers to use Microsoft.NETFramework.ReferenceAssemblies 1.0.0 arcade#7053)
• What about the release reference assemblies is different to the point that it is causing the build error (Tracked here: Release reference assemblies break overload resolution in VB on .NET Framework 4.7.2 #51711)

[jmarolf]

Currently failing due to

Compilation error(s) occurred:  Cannot use file stream for [C:\h\w\A86A091F\w\BD710A50\e\testhost.deps.json]: No such file or directory
A fatal error was encountered. The library 'hostpolicy.dll' required to execute the application was not found in 'C:\h\w\A86A091F\p\dotnet-cli'.
Failed to run as a self-contained app.

The application was run as a self-contained app because 'C:\h\w\A86A091F\w\BD710A50\e\testhost.runtimeconfig.json' was not found.
If this should be a framework-dependent app, add the 'C:\h\w\A86A091F\w\BD710A50\e\testhost.runtimeconfig.json' file and specify the appropriate framework.
Expected: False
Actual:   True

I'll need to investigate why testhost.deps.json isn't being deployed

[MichaelSimons]

@jmarolf, Friendly ask if there are any updates?

[jmarolf]

superseded by #52255