Aspnetcore: Use new file to supply a long list of assemblies to linker

[StevenTCramer]

The Mono team has resolved https://github.com/mono/linker/issues/379
Yet in preview 6 we still get https://github.com/aspnet/AspNetCore/issues/5673

I just want to track that this gets resolved as I have a fellow developer that continues to see this issue on brand new projects.

https://github.com/aspnet/AspNetCore/blob/de911255936905b01e8accc43c426688150c63fd/src/Components/Blazor/Build/src/targets/Blazor.MonoRuntime.targets#L441

I think _BlazorAssembliesToLink needs changed to pass a file instead.

If this is being tracked somewhere I apologize my searches don't find any open issues.

[mkArtakMSFT]

Thanks for contacting us, @StevenTCramer.
We're working hard on the most critical issues we have to deliver for 3.0 release and we'll be able to look into this only after that.

[stefanbemelmans]

Hello, I am the fellow developer, I hope to provide some context. this is a reproduction of the issue in a fresh blazor-hosted app (preview 6). After adding the Nethereum package only, building results in this error

My work around has been to create the project in a directory with very short names. C:\mv\nt\ for example.
this is another blazor-hosted app in a shortened directory path that builds and runs without issue.

I am running Windows 10 Pro, current build and dotnet 3.0.100-preview6-012264;

Thank you for your time.

[PhilPJL]

I hit the same issue when referencing OpenXML. The issue arises (I think) because OpenXML supports .NET Standard 1.3 but not 2.0. If I reference the latest beta of OpenXML which does support 2.0 the linker issue goes away.
I notice that Nethereum.Web3 references Newtonsoft.JSON 10.0.3 which also only supports .NET Standard 1.3. I assume that if Nethereum.Web3 was updated to use Newtonsoft.JSON 12.x your issue would also go away. Explicitly referencing Newtonsoft.JSON 12.0.2 also fixes the issue.

[PhilPJL]

I'm actually not sure if I've hit the same issue, but it's a least similar. When I reference OpenXML or ClosedXML or Nethereum.Web3 I get a linker error of: 'The command "dotnet ... lots of file paths exited with code -532462766".

For OpenXML and Nethereum.Web3 I can update the package or one if the packages dependencies so that only .NET Standard 2 is referenced. Then the linker error is solved. Unfortunately unable to workaround for ClosedXML which is what I actually want to use.

[PhilPJL]

@mkArtakMSFT You have this bug as an 'enhancement' scheduled for 3.1. However it's a complete show stopper for me. Try this. Create a new Blazor app. Add system.data.common - the app won't build. Add any other nuget package which doesn't specify .NETStandard 2.0 or has an inherited dependency which doesn't specify .NETStandard 2.0 - the app won't build. Which means there's quite a lot of packages that can't be used.

[SteveSandersonMS]

@PhilPJL Would you be able to post a new issue describing what problems you're having? I did just try adding System.Data.Common version 4.3.0 to a Blazor client-side (3.0.0 preview 6) application, and this didn't cause any compilation errors. Could you post a new issue describing what you're trying to do, as well as what steps you're taking that lead to an error?

In general, client-side Blazor supports up to and including netstandard2.0 (so earlier target frameworks such as netstandard1.3 etc also work). Client-side Blazor is not means to support .NET Framework assemblies.

[PhilPJL]

@SteveSandersonMS sorry my mistake, should have been system.drawing.common. Try adding either v4.5.1 or 4.6.0-preview6. Same problem. Both versions specify .NETStandard v2.0 = no dependencies.
WebApplication1.zip

Created new issue.

[PhilPJL]

@SteveSandersonMS
Hey Steve, I know you're busy but do you have any feedback on this issue, it's been punted around a bit.

If we add a NuGet package that references system.drawing.common then the linker fails.
Which of these options is the most likely?

• It will work when this issue 11887 is fixed?
• It won't work even when 11887 is fixed because system.drawing.common isn't supported on web assembly. Is it then the case that a Nuget package that says it supports .NET Standard 2 isn't necessarily compatible with Blazor?

[SteveSandersonMS]

It will work when this issue 11887 is fixed?

I don't have any reason to think the System.Drawing.Common issue has anything to do with #11887. It seems much more likely to be due to the assembly having native dependencies.

Is it then the case that a Nuget package that says it supports .NET Standard 2 isn't necessarily compatible with Blazor?

Strictly speaking yes, that's true. Just because an assembly targets netstandard2.0 doesn't stop it from, say shelling out to the OS to run a Windows or Linux-specific command line tool that obviously wouldn't existing in a WASM environment. More generally, the fact that assemblies can cross-compile to different platforms to embed different native dependencies or native code also implies this.

It would be interesting to consider having some way for NuGet package authors to flag whether their package is platform neutral or not. Certainly the vast majority of them already are, but cases like System.Drawing.Common can be surprising.

[pranavkm]

Blazor's linker task uses a response file to launch the linker which mitigates the command line length restriction. Closing this as the original intent of this issue has been resolved.