The dotnet linker is now being developed in the dotnet/runtime
repo at https://github.com/dotnet/runtime/tree/main/src/tools/illink. Please file issues and make changes in https://github.com/dotnet/runtime instead.
linker's Introduction
linker's People
Forkers
erozenfeld sbomer spouliot marek-safar unity-technologies vargaz briansull swaroop-sridhar shjgiser rolfbjarne tralivali1234 vrishe michalstrehovsky radekdoulik devlead 07101994 pbzyy neoayi chamons jonpryor josephtremoulet andreyakinshin akoeplinger tmat baulig kikkoi ocdsoft ericstj awesomedotnetcore dagood lambdageek jkoritzinsky cshung praeclarum kant2002 kjpou1 sywhang lewing fadimounir alexanderkyte mattgal woxihuanjia chcosta jpapp05 jangocheng dayfox5317 oberdanf tlakollo vitek-karas tklebanoff mmitche directhex besmith43 grabyourpitchforks kg stevesandersonms mateoatr riarenas terrajobst nudtlio fornever mrclan eerhardt yas-mnkornym layomia agocke pranavkm lakshanf epananth zjoch stjordanis satoshi-bitcoin freyreeste youssef1313 tannergooding amieres omajid dseefeld majacq michaelsimons mu-l devbox10 geoffkizer zhamppx97 jonfortescue am11 lpatalas isabella232 lbussell vseanreesermsft jtschuster jonathanpeppers hyunbin7303 permyakov alexandersemenyak shreyasjejurkar sillsdev javiersanros wildernesslabs iserratolinker's Issues
Use arcade to build linker
@marek-safar We would like the linker to participate in .NET Core product construction using https://github.com/dotnet/arcade. I'm hoping to do the work in a way that benefits mono as well as the dotnet product construction, and am looking for input on how to best accomplish that.
The arcade infrastructure uses wrapper scripts that download a bootstrap dotnet sdk and use its nuget/msbuild to restore and build a solution in the repo root. It has some conventions around directory structure, package dependencies, flowing dependencies between repos, etc. To what extent are you interested in reusing arcade infrastructure for the monolinker.exe (as opposed to illink and ILLink.Tasks) build? It seems there are options like:
- building with mono vs dotnet SDK
- arcade wrapper scripts vs Makefiles
- mono project jenkins vs Azure DevOps
- nunit vs xunit
I also noticed that https://github.com/mono/mono has a submodule dependency on mono/linker. It looks like there are dependencies on the source files in https://github.com/mono/mono/blob/master/mcs/tools/linker/monolinker.exe.sources and https://github.com/mono/mono/blob/master/mcs/tools/linker-analyzer/illinkanalyzer.exe.sources. Similarly for cecil at https://github.com/mono/mono/blob/c5b88ec4f323f2bdb7c7d0a595ece28dae66579c/mcs/class/Mono.Cecil/Mono.Cecil.dll.sources. I'm not familiar with the mono project's build.
- Are there any restrictions on what changes can be made to this repo's build? (Would you prefer the file layout to stay as-is, or may we move them around?)
I'd also like to use this as an opportunity to look into simplifying the configurations we use to build illink (and possibly monolinker). Currently, Mono.Linker/illink_Debug depends on Mono.Cecil/netstandard_Debug. The .NET SDK doesn't support configuration-specific dependencies, so we have hacks in place that explicitly inject the configuration into Mono.Linker and its dependencies. The workaround isn't so bad, but it gets worse every time we add another project (Mono.Cecil.Pdb/Mdb, an ILLink.Tasks.Tests project, etc.).
- I'd like to set up a build of the linker (and cecil, @jbevain ) that uses a normal SDK project (
<Project Sdk="Microsoft.NET.Sdk">
) and supported mechanisms for publishing for different Target Frameworks. This means setting the TargetFramework independently of the configuration, and using only Debug/Release configurations. Is this a change you'd like me to pipe through the mono build as well, or should it be kept in a separate project file? It looks like it has been attempted for cecil at least in jbevain/cecil#442 and jbevain/cecil#527. @jbevain, it would be wonderful to get your opinion on this.
Fatal error by latest linker release 0.1.5-preview-1461378
https://github.com/lextm/restructuredtext-antlr
It uses the release of 0.1.4-preview-981901
, and dist.server.sh
can be used on Mac to call all dotnet publish
commands without a problem.
But once upgrading to 0.1.5-preview-1461378
, dotnet publish
fails like below,
LexdeMacBook-Pro:Server lextm$ dotnet publish -r win-x64 -c release -o ../output/win32_x64
Microsoft (R) Build Engine version 15.7.177.53362 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.
Restoring packages for /Users/lextm/restructuredtext-antlr/Server/Server.csproj...
Restoring packages for /Users/lextm/restructuredtext-antlr/ReStructuredText/ReStructuredText.csproj...
Restore completed in 458.93 ms for /Users/lextm/restructuredtext-antlr/ReStructuredText/ReStructuredText.csproj.
Restore completed in 971.48 ms for /Users/lextm/restructuredtext-antlr/Server/Server.csproj.
ReStructuredText -> /Users/lextm/restructuredtext-antlr/ReStructuredText/bin/release/netstandard1.3/ReStructuredText.dll
...
Server -> /Users/lextm/restructuredtext-antlr/Server/bin/release/netcoreapp2.0/win-x64/Server.dll
Restoring packages for /Users/lextm/restructuredtext-antlr/ReStructuredText/ReStructuredText.csproj...
/Users/lextm/restructuredtext-antlr/ReStructuredText/ReStructuredText.csproj : error NU1202: Package Microsoft.NETCore.App 2.0.0 is not compatible with netstandard1.3 (.NETStandard,Version=v1.3). Package Microsoft.NETCore.App 2.0.0 supports: [/Users/lextm/restructuredtext-antlr/Server/Server.csproj]
/Users/lextm/restructuredtext-antlr/ReStructuredText/ReStructuredText.csproj : error NU1202: - netcoreapp (.NETCoreApp,Version=v0.0) [/Users/lextm/restructuredtext-antlr/Server/Server.csproj]
/Users/lextm/restructuredtext-antlr/ReStructuredText/ReStructuredText.csproj : error NU1202: - netcoreapp2.0 (.NETCoreApp,Version=v2.0) [/Users/lextm/restructuredtext-antlr/Server/Server.csproj]
/Users/lextm/restructuredtext-antlr/ReStructuredText/ReStructuredText.csproj : error NU1202: Package Microsoft.NETCore.App 2.0.0 is not compatible with netstandard1.3 (.NETStandard,Version=v1.3) / win-x64. Package Microsoft.NETCore.App 2.0.0 supports:[/Users/lextm/restructuredtext-antlr/Server/Server.csproj]
/Users/lextm/restructuredtext-antlr/ReStructuredText/ReStructuredText.csproj : error NU1202: - netcoreapp (.NETCoreApp,Version=v0.0) [/Users/lextm/restructuredtext-antlr/Server/Server.csproj]
/Users/lextm/restructuredtext-antlr/ReStructuredText/ReStructuredText.csproj : error NU1202: - netcoreapp2.0 (.NETCoreApp,Version=v2.0) [/Users/lextm/restructuredtext-antlr/Server/Server.csproj]
Generating MSBuild file /Users/lextm/restructuredtext-antlr/Server/obj/release/netcoreapp2.0/win-x64/crossgen/ReStructuredText.csproj.nuget.g.props.
Generating MSBuild file /Users/lextm/restructuredtext-antlr/Server/obj/release/netcoreapp2.0/win-x64/crossgen/ReStructuredText.csproj.nuget.g.targets.
Restore failed in 30.67 ms for /Users/lextm/restructuredtext-antlr/ReStructuredText/ReStructuredText.csproj.
Support for RuntimeReflectionExtensions.GetRuntimeMethod
Reading on Xamarin's IOS linking (https://developer.xamarin.com/guides/ios/advanced_topics/linker/), and I'm guessing this is the tool they use to link (right?), they write that reflection is not supported by the linker, but if nameof is used (see also discussion here: autofac/Autofac#841) can we add support for the linker to assume that the method in the nameof is being also being used and not strip it out?
Fatal error in IL Linker with same build output
Fatal error in IL Linker
System.NullReferenceException: Object reference not set to an instance of an object.
at Mono.Cecil.MetadataBuilder.GetExportedTypeScope(ExportedType exported_type)
at Mono.Cecil.MetadataBuilder.AddExportedTypes()
at Mono.Cecil.MetadataBuilder.BuildModule()
at Mono.Cecil.MetadataBuilder.BuildMetadata()
at Mono.Cecil.ModuleWriter.<>c.<BuildMetadata>b__2_0(MetadataBuilder builder, MetadataReader _)
at Mono.Cecil.ModuleDefinition.Read[TItem,TRet](TItem item, Func`3 read)
at Mono.Cecil.ModuleWriter.BuildMetadata(ModuleDefinition module, MetadataBuilder metadata)
at Mono.Cecil.ModuleWriter.Write(ModuleDefinition module, Disposable`1 stream, WriterParameters parameters)
at Mono.Cecil.ModuleWriter.WriteModule(ModuleDefinition module, Disposable`1 stream, WriterParameters parameters)
at Mono.Cecil.ModuleDefinition.Write(String fileName, WriterParameters parameters)
at Mono.Linker.Steps.OutputStep.WriteAssembly(AssemblyDefinition assembly, String directory, WriterParameters writerParameters)
at Mono.Linker.Steps.OutputStep.WriteAssembly(AssemblyDefinition assembly, String directory)
at Mono.Linker.Steps.OutputStep.OutputAssembly(AssemblyDefinition assembly)
at Mono.Linker.Steps.OutputStep.ProcessAssembly(AssemblyDefinition assembly)
at Mono.Linker.Steps.BaseStep.Process(LinkContext context)
at Mono.Linker.Pipeline.Process(LinkContext context)
at Mono.Linker.Driver.Run(ILogger customLogger)
at Mono.Linker.Driver.Execute(String[] args, ILogger customLogger)
I reproduced it by calling dotnet build -c Release -o out
with ILLink.Tasks 0.1.5-preview-1461378
twice to the same directory. Normally second build would just update the directory with new content, and therefore it's entirely valid, but mono linker seems to have some difficulties with that.
This issue is not reproducible if you manually remove out
directory before calling dotnet build
for the second time. I reproduced this one on Windows and had no luck doing the same on Linux.
Thank you in advance.
C:\Users\Archi>dotnet --info
Narzędzia wiersza polecenia programu .NET (2.1.100)
Product Information:
Version: 2.1.100
Commit SHA-1 hash: b9e74c6520
Runtime Environment:
OS Name: Windows
OS Version: 10.0.16299
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\2.1.100\
Microsoft .NET Core Shared Framework Host
Version : 2.0.5
Build : 17373eb129b3b05aa18ece963f8795d65ef8ea54
Support a response file
Currently there is support to pass in a file for certain parameters but a pattern followed by most .NET tools is to pass in @foo.rsp
that has all the commandline options verbatim as if they were passed on the commandline. This is convenient for rerun and also handles command-line length limitations on various OSes.
Linker cannot remove unused static vars which have an initializer
Testcase:
using System;
public class Tests
{
public static int foo = 5;
public static void Main () {
Console.WriteLine ("Hello!");
}
}
Run with:
monolinker -a bug.exe
If = 5 is removed, the 'foo' variable is also removed.
ILLink.Task fails when used in latest SDK
/cc @sbomer
Using the latest dotnet SDK, add the following
<PackageReference Include="ILLink.Tasks" Version="0.1.5-preview-1461378" />
Publish the project.
It will fail with
2>The "GetRuntimeLibraries" task failed unexpectedly.
2>System.InvalidCastException: [A]NuGet.ProjectModel.LockFile cannot be cast to [B]NuGet.ProjectModel.LockFile. Type A originates from 'NuGet.ProjectModel, Version=4.7.0.5, Culture=neutral, PublicKeyToken=31bf3856ad364e35' in the context 'LoadFrom' at location 'C:\Program Files\dotnet\sdk\2.1.300-rc1-008673\Sdks\Microsoft.NET.Sdk\tools\net46\NuGet.ProjectModel.dll'. Type B originates from 'NuGet.ProjectModel, Version=4.3.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' in the context 'LoadFrom' at location 'C:\Users\ericstj\.nuget\packages\illink.tasks\0.1.5-preview-1461378\tools\net46\NuGet.ProjectModel.dll'.
2> at Microsoft.NET.Build.Tasks.LockFileCache.GetLockFile(String path)
2> at ILLink.Tasks.GetRuntimeLibraries.Execute()
2> at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
2> at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()
This is the same bug I fixed/worked-around here: dotnet/standard#722
@nguerrera do you have an idea about a public contract we can have around this to avoid these issues in the future? Either we get everyone to agree on where to load NuGet from or we version the cache objects (like I did in my PR). The latter is less good since it means we don't benefit from the cache when we get out of sync.
Building linker on windows requires Developer Prompt or Visual Studio 2015
After cloning this repository, I noticed that it requires VS2015 to build on Windows. Is there any chance we can enable building with VS2017 or VS2019 (likely just requires using vswhere to locate an installation)? I would prefer to not have to go install VS2015 just for this repository.
Fatal error in IL Linker with latest SDK
ILLINK : warning : unresolved assembly System.Runtime [/home/archi/ArchiSteamFarm/ArchiSteamFarm/ArchiSteamFarm.csproj]
ILLINK : warning : unresolved assembly System.Threading.Tasks [/home/archi/ArchiSteamFarm/ArchiSteamFarm/ArchiSteamFarm.csproj]
ILLINK : warning : unresolved assembly System.Collections [/home/archi/ArchiSteamFarm/ArchiSteamFarm/ArchiSteamFarm.csproj]
ILLINK : warning : unresolved assembly System.Runtime.Extensions [/home/archi/ArchiSteamFarm/ArchiSteamFarm/ArchiSteamFarm.csproj]
ILLINK : warning : unresolved assembly System.Diagnostics.Debug [/home/archi/ArchiSteamFarm/ArchiSteamFarm/ArchiSteamFarm.csproj]
ILLINK : warning : unresolved assembly System.Threading [/home/archi/ArchiSteamFarm/ArchiSteamFarm/ArchiSteamFarm.csproj]
ILLINK : warning : unresolved assembly System.Xml.ReaderWriter [/home/archi/ArchiSteamFarm/ArchiSteamFarm/ArchiSteamFarm.csproj]
ILLINK : warning : unresolved assembly System.Linq.Expressions [/home/archi/ArchiSteamFarm/ArchiSteamFarm/ArchiSteamFarm.csproj]
ILLINK : warning : unresolved assembly System.Collections.Concurrent [/home/archi/ArchiSteamFarm/ArchiSteamFarm/ArchiSteamFarm.csproj]
ILLINK : warning : unresolved assembly System.Threading.Timer [/home/archi/ArchiSteamFarm/ArchiSteamFarm/ArchiSteamFarm.csproj]
ILLINK : warning : unresolved assembly System.IO.FileSystem.Watcher [/home/archi/ArchiSteamFarm/ArchiSteamFarm/ArchiSteamFarm.csproj]
ILLINK : warning : unresolved assembly System.IO.Compression [/home/archi/ArchiSteamFarm/ArchiSteamFarm/ArchiSteamFarm.csproj]
ILLINK : warning : unresolved assembly System.Collections.Specialized [/home/archi/ArchiSteamFarm/ArchiSteamFarm/ArchiSteamFarm.csproj]
ILLINK : warning : unresolved assembly System.Security.Cryptography.Csp [/home/archi/ArchiSteamFarm/ArchiSteamFarm/ArchiSteamFarm.csproj]
ILLINK : warning : unresolved assembly System.Text.RegularExpressions [/home/archi/ArchiSteamFarm/ArchiSteamFarm/ArchiSteamFarm.csproj]
ILLINK : warning : unresolved assembly System.Linq [/home/archi/ArchiSteamFarm/ArchiSteamFarm/ArchiSteamFarm.csproj]
ILLINK : warning : unresolved assembly System.Security.Cryptography.Algorithms [/home/archi/ArchiSteamFarm/ArchiSteamFarm/ArchiSteamFarm.csproj]
ILLINK : warning : unresolved assembly System.Net.WebSockets [/home/archi/ArchiSteamFarm/ArchiSteamFarm/ArchiSteamFarm.csproj]
ILLINK : warning : unresolved assembly System.Net.Primitives [/home/archi/ArchiSteamFarm/ArchiSteamFarm/ArchiSteamFarm.csproj]
ILLINK : warning : unresolved assembly System.Net.HttpListener [/home/archi/ArchiSteamFarm/ArchiSteamFarm/ArchiSteamFarm.csproj]
ILLINK : warning : unresolved assembly System.Diagnostics.Process [/home/archi/ArchiSteamFarm/ArchiSteamFarm/ArchiSteamFarm.csproj]
ILLINK : warning : unresolved assembly System.Net.WebSockets.Client [/home/archi/ArchiSteamFarm/ArchiSteamFarm/ArchiSteamFarm.csproj]
ILLINK : warning : unresolved assembly System.Resources.ResourceManager [/home/archi/ArchiSteamFarm/ArchiSteamFarm/ArchiSteamFarm.csproj]
ILLINK : warning : unresolved assembly System.Console [/home/archi/ArchiSteamFarm/ArchiSteamFarm/ArchiSteamFarm.csproj]
ILLINK : warning : unresolved assembly System.Net.Http [/home/archi/ArchiSteamFarm/ArchiSteamFarm/ArchiSteamFarm.csproj]
ILLINK : warning : unresolved assembly System.Diagnostics.Tools [/home/archi/ArchiSteamFarm/ArchiSteamFarm/ArchiSteamFarm.csproj]
ILLINK : warning : unresolved assembly System.IO.FileSystem [/home/archi/ArchiSteamFarm/ArchiSteamFarm/ArchiSteamFarm.csproj]
ILLINK : warning : unresolved assembly System.IO.Compression.ZipFile [/home/archi/ArchiSteamFarm/ArchiSteamFarm/ArchiSteamFarm.csproj]
ILLINK : warning : unresolved assembly System.Security.Cryptography.Primitives [/home/archi/ArchiSteamFarm/ArchiSteamFarm/ArchiSteamFarm.csproj]
ILLINK : warning : unresolved assembly System.Linq.Parallel [/home/archi/ArchiSteamFarm/ArchiSteamFarm/ArchiSteamFarm.csproj]
ILLINK : warning : unresolved assembly System.Runtime.InteropServices.RuntimeInformation [/home/archi/ArchiSteamFarm/ArchiSteamFarm/ArchiSteamFarm.csproj]
ILLINK : warning : unresolved assembly System.Runtime.InteropServices [/home/archi/ArchiSteamFarm/ArchiSteamFarm/ArchiSteamFarm.csproj]
ILLINK : warning : unresolved assembly System.Net.ServicePoint [/home/archi/ArchiSteamFarm/ArchiSteamFarm/ArchiSteamFarm.csproj]
ILLINK : warning : unresolved assembly Microsoft.CSharp [/home/archi/ArchiSteamFarm/ArchiSteamFarm/ArchiSteamFarm.csproj]
ILLINK : warning : unresolved assembly System.ComponentModel.TypeConverter [/home/archi/ArchiSteamFarm/ArchiSteamFarm/ArchiSteamFarm.csproj]
Fatal error in IL Linker
Mono.Linker.Steps.XmlResolutionException: Failed to process XML description: <unspecified> ---> System.NullReferenceException: Object reference not set to an instance of an object.
at Mono.Linker.LinkContext.ResolveReferences(AssemblyDefinition assembly)
at Mono.Linker.Steps.ResolveFromXmlStep.ProcessReferences(AssemblyDefinition assembly, LinkContext context)
at Mono.Linker.Steps.ResolveFromXmlStep.GetAssembly(LinkContext context, AssemblyNameReference assemblyName)
at Mono.Linker.Steps.ResolveFromXmlStep.ProcessAssemblies(LinkContext context, XPathNodeIterator iterator)
at Mono.Linker.Steps.ResolveFromXmlStep.Process()
--- End of inner exception stack trace ---
at Mono.Linker.Steps.ResolveFromXmlStep.Process()
at Mono.Linker.Steps.BaseStep.Process(LinkContext context)
at Mono.Linker.Pipeline.Process(LinkContext context)
at Mono.Linker.Driver.Run(ILogger customLogger)
at Mono.Linker.Driver.Execute(String[] args, ILogger customLogger)
The same project compiled exactly the same under 2.1.3
SDK works fine.
Thank you in advance.
.NET Core SDK (reflecting any global.json):
Version: 2.1.300-preview2-008375
Commit: 04ba0c9523
Runtime Environment:
OS Name: debian
OS Version:
OS Platform: Linux
RID: debian-x64
Base Path: /opt/dotnet/sdk/2.1.300-preview2-008375/
Host (useful for support):
Version: 2.1.0-preview2-26313-01
Commit: 3c802455b2
.NET Core SDKs installed:
2.1.300-preview2-008375 [/opt/dotnet/sdk]
.NET Core runtimes installed:
Microsoft.AspNetCore.All 2.1.0-preview2-30338 [/opt/dotnet/shared/Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.0-preview2-30338 [/opt/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.1.0-preview2-26313-01 [/opt/dotnet/shared/Microsoft.NETCore.App]
To install additional .NET Core runtimes or SDKs:
https://aka.ms/dotnet-download
Unobserved task exceptions only on linked apps
Please refer to my original issue on dotnet/corefx: https://github.com/dotnet/corefx/issues/26830
After deeper analysis it turns out that only apps after ILLink.Tasks step suffer from this issue, as I couldn't reproduce it on normal output. I'm not entirely sure how that is possible considering the issue looks like runtime issue (and that got me fooled at first), but I suspect that mono linker could alter some default routines and make previously observed task being unobserved, or that it introduced some kind of race condition during the linking process.
I'm not much of a help here since I'm not entirely sure what could be the root cause, I hope you'll be able to reproduce it. I explained all details in above issue, as well as with code sample. Of course I'm using latest ILLink.Tasks version, 0.1.5-preview-1461378
.
If you'd like to see output of affected app, e.g. for analyzing output websocket dlls for comparison, feel free to check this one.
Thank you in advance for looking into this.
.NET Command Line Tools (2.1.103)
Product Information:
Version: 2.1.103
Commit SHA-1 hash: 60218cecb5
Runtime Environment:
OS Name: Windows
OS Version: 10.0.14393
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\2.1.103\
Microsoft .NET Core Shared Framework Host
Version : 2.0.6
Build : 74b1c703813c8910df5b96f304b0f2b78cdf194d
Dependency trees, or: why is System.Drawing.Primitives being deployed in a console app?
From dotnet/standard#703:
@voltagex wrote:
I've got a console app that I've turned on linking and trimming for. A complete standalone version targetting win-x64 is about 40MB, which isn't too bad I guess.
What I can't work out is why some of the runtime is being included in a simple app, e.g.
- System.Security.Claims.dll (unused)
- System.IO.Compression.dll (unused)
- System.Drawing.Primitives.dll (System.Drawing is removed by linking/trimming but this one isn't)
I'd like to be able to see why certain assemblies are being pulled in, and if they're not needed, get rid of them completely.
Support for default interface methods
.NET Core 3.0 (and possibly .NET Standard 2.1) is adding support for non-abstract instance methods on interfaces in support of the C# 8.0 language feature. Spec here.
IL Linker will need to understand what this semantic means and:
- Be able to scan instance methods on interfaces
- If IL Linker has any sort of interface method resolution logic, this logic will need to be updated to understand the resolution to default interface methods
- Tests will have to be added
As an aside, C# 8.0 is also adding support for static methods and fields on interface types. The ECMA-335 standard has supported this for a while, but it's likely the scenario is untested in IL Linker (e.g. support for static constructors in interfaces, etc.).
Linker - Failed to resolve assembly: 'System.Private.CoreLib'
From @Symbai on December 29, 2018 16:53
Issue
Linker thrown an exception when I tried to follow the docs building the sample.
Windows 10 64-Bit
Click to expand
Host (useful for support):
Version: 3.0.0-preview-27224-1
Commit: b9d9540371
.NET Core SDKs installed:
2.1.202 [C:\Program Files\dotnet\sdk]
2.1.403 [C:\Program Files\dotnet\sdk]
2.1.500 [C:\Program Files\dotnet\sdk]
2.1.600-preview-009426 [C:\Program Files\dotnet\sdk]
3.0.100-preview-009812 [C:\Program Files\dotnet\sdk]
3.0.100-preview-009844 [C:\Program Files\dotnet\sdk]
.NET Core runtimes installed:
Microsoft.AspNetCore.All 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.0.0-preview-18579-0056 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.0.0-preview-27122-01 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.0.0-preview-27218-01 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.0.0-preview-27224-1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 3.0.0-alpha-27128-4 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 3.0.0-alpha-27218-3 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Steps
- Downloaded sample linked in the docs https://github.com/dotnet/dotnet-docker-samples/archive/master.zip
- Extracted to desktop
- Run commands
cd C:\Users\...\Desktop\dotnet-docker-samples-master\dotnetapp-selfcontained
dotnet publish -c release -r win-x64 -o selfcontained-win-x64
Stacktrace:
dotnetapp -> C:\Users\...\Desktop\dotnet-docker-samples-master\dotnetapp-selfcontained\bin\release\netcoreapp2.0\win-x64\dotnetapp.dll
Fatal error in IL Linker
Mono.Cecil.AssemblyResolutionException: Failed to resolve assembly: 'System.Private.CoreLib, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' ---> Mono.Cecil.AssemblyResolutionException: Failed to resolve assembly: 'System.Private.CoreLib, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'
at Mono.Linker.DirectoryAssemblyResolver.Resolve(AssemblyNameReference name, ReaderParameters parameters)
at Mono.Linker.AssemblyResolver.Resolve(AssemblyNameReference name, ReaderParameters parameters)
at Mono.Linker.LinkContext.Resolve(IMetadataScope scope)
at Mono.Linker.LinkContext.Resolve(IMetadataScope scope)
at Mono.Linker.LinkContext.Resolve(String name)
at Mono.Linker.Steps.ResolveFromAssemblyStep.Process()
at Mono.Linker.Steps.BaseStep.Process(LinkContext context)
at Mono.Linker.Pipeline.Process(LinkContext context)
at Mono.Linker.Driver.Run()
at Mono.Linker.Driver.Main(String[] args)
Copied from original issue: dotnet/core#2193
Fatal error in IL Linker during Mono.Linker.TypeReferenceExtensions.GetMethods
2019-01-18T00:59:53.2367971Z Fatal error in IL Linker
2019-01-18T00:59:53.2565546Z System.InvalidOperatoinException: Operation is not valid due to the current state of the object.
2019-01-18T00:59:53.2566112Z at Mono.Collections.Generic.Collection`1.Enumerator.CheckState()
2019-01-18T00:59:53.2566269Z at Mono.Collections.Generic.Collection`1.Enumerator.MoveNext()
2019-01-18T00:59:53.2566430Z at Mono.Linker.TypeReferenceExtensions.GetMethods(TypeReference type)+MoveNext()
2019-01-18T00:59:53.2566570Z at Mono.Linker.Steps.TypeMapStep.TryMatchMethod(TypeReference type, MethodDefinition method)
2019-01-18T00:59:53.2569179Z at Mono.Linker.Steps.TypeMapStep.GetBaseMethodsInInterfaceHierarchy(TypeReference type, MethodDefinition method)+MoveNext()
2019-01-18T00:59:53.2569344Z at Mono.Linker.Steps.TypeMapStep.MapVirtualInterfaceMethod(MethodDefinition method)
2019-01-18T00:59:53.2569482Z at Mono.Linker.Steps.TypeMapStep.MapVirtualMethod(MethodDefinition method)
2019-01-18T00:59:53.2570485Z at Mono.Linker.Steps.TypeMapStep.MapVirtualMethods(TypeDefinition type)
2019-01-18T00:59:53.2570907Z at Mono.Linker.Steps.TypeMapStep.MapType(TypeDefinition type)
2019-01-18T00:59:53.2571018Z at Mono.Linker.Steps.TypeMapStep.ProcessAssembly(AssemblyDefinition assembly)
2019-01-18T00:59:53.2571142Z at Mono.Linker.Steps.BaseStep.Process(LinkContext context)
2019-01-18T00:59:53.2571284Z at Mono.Linker.Pipeline.Process(LinkContext context)
2019-01-18T00:59:53.2571396Z at Mono.Linker.Driver.Run(ILogger customLogger)
2019-01-18T00:59:53.2571616Z at Mono.Linker.Driver.Execute(String[] args, ILogger customLogger)
Same code succeeds on rebuild. It appears that something is modifying the collection while enumerating it. https://github.com/mono/mono-basic/blob/e31cb702937a0adcc853250a0989c5f43565f9b8/vbnc/cecil/Mono.Collections.Generic/Collection.cs#L444
Fatal error in IL Linker
I thought I'd try linking my netcoreapp2.1 AWS lambda package, but very quickly ran into the following issue:
ILLINK : warning : unresolved assembly System.Runtime [C:\Users\kent\Repository\<<redacted>>.Services\Src\LambdaFunctions\LambdaFunctions.csproj]
ILLINK : warning : unresolved assembly System.Threading.Tasks [C:\Users\kent\Repository\<<redacted>>.Services\Src\LambdaFunctions\LambdaFunctions.csproj]
ILLINK : warning : unresolved assembly System.Diagnostics.Debug [C:\Users\kent\Repository\<<redacted>>.Services\Src\LambdaFunctions\LambdaFunctions.csproj]
ILLINK : warning : unresolved assembly System.Net.Primitives [C:\Users\kent\Repository\<<redacted>>.Services\Src\LambdaFunctions\LambdaFunctions.csproj]
ILLINK : warning : unresolved assembly System.Collections.Immutable [C:\Users\kent\Repository\<<redacted>>.Services\Src\LambdaFunctions\LambdaFunctions.csproj]
ILLINK : warning : unresolved assembly System.Runtime.Extensions [C:\Users\kent\Repository\<<redacted>>.Services\Src\LambdaFunctions\LambdaFunctions.csproj]
ILLINK : warning : unresolved assembly System.Runtime.Serialization.Primitives [C:\Users\kent\Repository\<<redacted>>.Services\Src\LambdaFunctions\LambdaFunctions.csproj]
ILLINK : warning : unresolved assembly System.Data.Common [C:\Users\kent\Repository\<<redacted>>.Services\Src\LambdaFunctions\LambdaFunctions.csproj]
ILLINK : warning : unresolved assembly System.Collections [C:\Users\kent\Repository\<<redacted>>.Services\Src\LambdaFunctions\LambdaFunctions.csproj]
ILLINK : warning : unresolved assembly System.Linq [C:\Users\kent\Repository\<<redacted>>.Services\Src\LambdaFunctions\LambdaFunctions.csproj]
ILLINK : warning : unresolved assembly System.Threading [C:\Users\kent\Repository\<<redacted>>.Services\Src\LambdaFunctions\LambdaFunctions.csproj]
ILLINK : warning : unresolved assembly netstandard [C:\Users\kent\Repository\<<redacted>>.Services\Src\LambdaFunctions\LambdaFunctions.csproj]
ILLINK : warning : unresolved assembly System.Threading.Tasks.Extensions [C:\Users\kent\Repository\<<redacted>>.Services\Src\LambdaFunctions\LambdaFunctions.csproj]
ILLINK : warning : unresolved assembly System.Resources.ResourceManager [C:\Users\kent\Repository\<<redacted>>.Services\Src\LambdaFunctions\LambdaFunctions.csproj]
ILLINK : warning : unresolved assembly System.Reflection [C:\Users\kent\Repository\<<redacted>>.Services\Src\LambdaFunctions\LambdaFunctions.csproj]
ILLINK : warning : unresolved assembly System.Xml.ReaderWriter [C:\Users\kent\Repository\<<redacted>>.Services\Src\LambdaFunctions\LambdaFunctions.csproj]
ILLINK : warning : unresolved assembly System.Runtime.Numerics [C:\Users\kent\Repository\<<redacted>>.Services\Src\LambdaFunctions\LambdaFunctions.csproj]
ILLINK : warning : unresolved assembly System.IO [C:\Users\kent\Repository\<<redacted>>.Services\Src\LambdaFunctions\LambdaFunctions.csproj]
ILLINK : warning : unresolved assembly System.Globalization [C:\Users\kent\Repository\<<redacted>>.Services\Src\LambdaFunctions\LambdaFunctions.csproj]
ILLINK : warning : unresolved assembly System.Text.Encoding [C:\Users\kent\Repository\<<redacted>>.Services\Src\LambdaFunctions\LambdaFunctions.csproj]
ILLINK : warning : unresolved assembly System.Reflection.Extensions [C:\Users\kent\Repository\<<redacted>>.Services\Src\LambdaFunctions\LambdaFunctions.csproj]
ILLINK : warning : unresolved assembly System.Security.Cryptography.Algorithms [C:\Users\kent\Repository\<<redacted>>.Services\Src\LambdaFunctions\LambdaFunctions.csproj]
ILLINK : warning : unresolved assembly System.Security.Cryptography.Primitives [C:\Users\kent\Repository\<<redacted>>.Services\Src\LambdaFunctions\LambdaFunctions.csproj]
ILLINK : warning : unresolved assembly System.ObjectModel [C:\Users\kent\Repository\<<redacted>>.Services\Src\LambdaFunctions\LambdaFunctions.csproj]
ILLINK : warning : unresolved assembly System.IO.FileSystem [C:\Users\kent\Repository\<<redacted>>.Services\Src\LambdaFunctions\LambdaFunctions.csproj]
ILLINK : warning : unresolved assembly System.Net.Http [C:\Users\kent\Repository\<<redacted>>.Services\Src\LambdaFunctions\LambdaFunctions.csproj]
ILLINK : warning : unresolved assembly System.Net.Requests [C:\Users\kent\Repository\<<redacted>>.Services\Src\LambdaFunctions\LambdaFunctions.csproj]
ILLINK : warning : unresolved assembly System.Xml.XDocument [C:\Users\kent\Repository\<<redacted>>.Services\Src\LambdaFunctions\LambdaFunctions.csproj]
ILLINK : warning : unresolved assembly System.Threading.Timer [C:\Users\kent\Repository\<<redacted>>.Services\Src\LambdaFunctions\LambdaFunctions.csproj]
ILLINK : warning : unresolved assembly System.Threading.Thread [C:\Users\kent\Repository\<<redacted>>.Services\Src\LambdaFunctions\LambdaFunctions.csproj]
ILLINK : warning : unresolved assembly System.Text.RegularExpressions [C:\Users\kent\Repository\<<redacted>>.Services\Src\LambdaFunctions\LambdaFunctions.csproj]
ILLINK : warning : unresolved assembly System.Text.Encoding.Extensions [C:\Users\kent\Repository\<<redacted>>.Services\Src\LambdaFunctions\LambdaFunctions.csproj]
ILLINK : warning : unresolved assembly System.Reflection.TypeExtensions [C:\Users\kent\Repository\<<redacted>>.Services\Src\LambdaFunctions\LambdaFunctions.csproj]
ILLINK : warning : unresolved assembly System.Runtime.InteropServices.RuntimeInformation [C:\Users\kent\Repository\<<redacted>>.Services\Src\LambdaFunctions\LambdaFunctions.csproj]
ILLINK : warning : unresolved assembly System.Console [C:\Users\kent\Repository\<<redacted>>.Services\Src\LambdaFunctions\LambdaFunctions.csproj]
ILLINK : warning : unresolved assembly System.IO.FileSystem.Primitives [C:\Users\kent\Repository\<<redacted>>.Services\Src\LambdaFunctions\LambdaFunctions.csproj]
ILLINK : warning : unresolved assembly System.Runtime.InteropServices [C:\Users\kent\Repository\<<redacted>>.Services\Src\LambdaFunctions\LambdaFunctions.csproj]
Fatal error in IL Linker
Mono.Cecil.ResolutionException: Failed to resolve System.Security.Permissions.SecurityPermissionAttribute
at Mono.Linker.Steps.MarkStep.MarkSecurityAttribute(SecurityAttribute sa)
at Mono.Linker.Steps.MarkStep.MarkSecurityDeclaration(SecurityDeclaration sd)
at Mono.Linker.Steps.MarkStep.MarkSecurityDeclarations(ISecurityDeclarationProvider provider)
at Mono.Linker.Steps.MarkStep.MarkAssembly(AssemblyDefinition assembly)
at Mono.Linker.Steps.MarkStep.InitializeAssembly(AssemblyDefinition assembly)
at Mono.Linker.Steps.MarkStep.Initialize()
at Mono.Linker.Steps.MarkStep.Process(LinkContext context)
at Mono.Linker.Pipeline.Process(LinkContext context)
at Mono.Linker.Driver.Run(ILogger customLogger)
at Mono.Linker.Driver.Execute(String[] args, ILogger customLogger)
Inconsistent assembly resolution via -x and -a
The assemblies provided via -a
argument and within the xml file provided via -x
are processed differently:
-a
: Accepts arguments of the formfile.exe
directly reads the file if it exists.
It also accepts justfile
and resolves the name as an assembly.
https://github.com/mono/linker/blame/master/linker/Mono.Linker/LinkContext.cs#L159-L168-x
: Does not acceptfiles.exe
form, just assembly names.
Processing the argument of -a
in two ways causes confusion, and results in some assemblies being processed twice with different names.
For example:
monolinker -a reflect.exe -x reflect.xml
Silently produces undesirable effect by
- processing the reflect.exe assembly twice and
- creating duplicate TypeDefinitions for all the types referenced in reflect.xml
This effectively nullifies reflect.xml file and causes unexpected output.
Some possible fixes are:
- Strip the extensions from
-a
arguments effectively causing (2) in this case - Always have
LinkContext::Resolve
resolve by name and not FileName
Mono.Cecil.ResolutionException: Failed to resolve System.Void Microsoft.Net.Http.Headers.EntityTagHeaderValue::.ctor(System.String)
Try to compile the AspNetCore 2.0 project with IL Linker nuget
dotnet publish -c release -r linux-x64 -o out /p:ShowLinkerSizeComparison=true
Fatal error in IL Linker
Mono.Linker.MarkException: Error processing method: 'System.Boolean Microsoft.AspNetCore.StaticFiles.StaticFileContext::LookupFileInfo()' in assembly: 'Microsoft.AspNetCore.StaticFiles.dll' ---> Mono.Cecil.ResolutionException: Failed to resolve System.Void Microsoft.Net.Http.Headers.EntityTagHeaderValue::.ctor(System.String)
at Mono.Linker.Steps.MarkStep.HandleUnresolvedMethod(MethodReference reference)
at Mono.Linker.Steps.MarkStep.MarkMethod(MethodReference reference)
at Mono.Linker.Steps.MarkStep.MarkInstruction(Instruction instruction)
at Mono.Linker.Steps.MarkStep.MarkMethodBody(MethodBody body)
at Mono.Linker.Steps.MarkStep.ProcessMethod(MethodDefinition method)
at Mono.Linker.Steps.MarkStep.ProcessQueue()
--- End of inner exception stack trace ---
at Mono.Linker.Steps.MarkStep.ProcessQueue()
at Mono.Linker.Steps.MarkStep.ProcessEntireQueue()
at Mono.Linker.Steps.MarkStep.Process()
at Mono.Linker.Steps.MarkStep.Process(LinkContext context)
at Mono.Linker.Pipeline.Process(LinkContext context)
at Mono.Linker.Driver.Run()
at Mono.Linker.Driver.Main(String[] args)
Fails on Microsoft.CodeAnalysis.CSharp.Features
If you add the following to your project:
<PackageReference Include="Microsoft.CodeAnalysis.CSharp.Features" Version="2.9.0" />
... then the linker fails with the following error:
1>Mono.Cecil.AssemblyResolutionException: Failed to resolve assembly: 'C:\Users\username\.nuget\packages\microsof.codeanalysis.workspaces.common\2.9.0\lib\netstandard1.3\es\Microsoft.CodeAnalysis.Workspaces.resources.dll, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' ---> Mono.Cecil.AssemblyResolutionException: Failed to resolve assembly: 'C:\Users\username\.nuget\packages\microsof.codeanalysis.workspaces.common\2.9.0\lib\netstandard1.3\es\Microsoft.CodeAnalysis.Workspaces.resources.dll, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'
1> at Mono.Linker.DirectoryAssemblyResolver.Resolve(AssemblyNameReference name, ReaderParameters parameters)
1> at Mono.Linker.AssemblyResolver.Resolve(AssemblyNameReference name, ReaderParameters parameters)
1> at Mono.Linker.LinkContext.Resolve(IMetadataScope scope)
1> at Mono.Linker.LinkContext.Resolve(IMetadataScope scope)
1> at Mono.Linker.LinkContext.Resolve(String name)
1> at Mono.Linker.Steps.ResolveFromAssemblyStep.Process()
1> at Mono.Linker.Steps.BaseStep.Process(LinkContext context)
1> at Mono.Linker.Pipeline.ProcessStep(LinkContext context, IStep step)
1> at Mono.Linker.Pipeline.Process(LinkContext context)
1> at Mono.Linker.Driver.Run(ILogger customLogger)
1> at Mono.Linker.Driver.Execute(String[] args, ILogger customLogger)
It looks like it incorrectly thinks the embedded resources are a reference to an external assembly, but they aren't.
mono-linker is no longer able to optimize targets for non-native runtimes
C:\Program Files\dotnet\sdk\2.1.4\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.CrossGen.targets(72,5): error : Unable to find resolved path for 'C:\Users\appveyor\.nuget\packages\runtime.linux-arm.microsoft.netcore.app\2.0.0\runtimes\linux-arm\native\..\..\..\tools\crossgen.exe'. [C:\projects\archisteamfarm\ArchiSteamFarm\ArchiSteamFarm.csproj]
The last working version is 0.1.4-preview-1222833
, ILLink.Tasks
in version preview-13*
fails for non-native runtime identifiers.
It should be possible to reproduce easily with dotnet publish -r linux-x64
(on Windows). Thank you in advance for looking into this.
Linker doesn't like Assembly names to be different from file names
If we have a file containing a module with a different name, the linker crashes in the mark step.
For example, in A.exe
if we have
.assembly B {}
.class B
extends [mscorlib]System.Object
{
...
.method private hidebysig static int32 Main(string[] args) cil managed
{
...
}
When A.exe is processed by the linker, the assembly is entered AssemblyCache as _assemblies["A"]
However, when the linker is marking the methods of class B, it looks for methods in assembly scope B
.
It cannot find it in the assembly-cache or a file named B.exe
/B.dll
and therefore fails.
I think the correct fix for this is to insert assemblies to the cache by assembly-name, and not file name.
Support list of files for references
It's not always convenient to provide a directory for references. Some times existing directories have too many other files and copying to a directory is excess work. Please add the ability to specify references by file.
win-x64 publish with Core3 Preview and VS2019 results in ""CheckEmbeddedRootDescriptor" task was not given a value for the required parameter "AssemblyPath""
From @stefanov-stefan on December 5, 2018 16:11
I have been trying to publish a plain dotnet new winforms app by following the steps here, but I end up with error: error MSB4044: The "CheckEmbeddedRootDescriptor" task was not given a value for the required parameter "AssemblyPath".
See attached image for the whole process.
I am running VS2019 Preview and have the following SDKs installed: https://www.screencast.com/t/29MbjIeY04
Any advice on how I can overcome this?
Copied from original issue: dotnet/winforms#210
Linker removes needed runtime dependency
Full repro: https://github.com/swratten/docker-test just git clone
and docker build
Exception at runtime:
Unhandled Exception: System.TypeLoadException: Could not load type 'Microsoft.Extensions.FileProviders.CompositeFileProvider' from assembly 'Microsoft.AspNetCore.Mvc.Razor.Extensions, Version=2.1.2.0, Culture=neutral
....
at Microsoft.Extensions.DependencyInjection.ServiceProviderServiceExtensions.GetRequiredService(IServiceProvider provider, Type serviceType)
at Microsoft.Extensions.DependencyInjection.ServiceProviderServiceExtensions.GetRequiredService[T](IServiceProvider provider)
at Microsoft.AspNetCore.Builder.MvcApplicationBuilderExtensions.UseMvc(IApplicationBuilder app, Action`1 configureRoutes)
at DockerTest.Startup.Configure(IApplicationBuilder app, IHostingEnvironment env) in /app/Startup.cs:line 45
Culprit removed library:
Before linking (B) After linking (B) Size decrease
----------- ----------- ----------- -----------
Total size of assemblies 69,785,560 43,704,832 37.373%
----------- ----------- ----------- -----------
...
Microsoft.Extensions.FileProviders.Composite.dll 17,400 0 100.000%
This is a simple barebones webapi generated through the dotnet cli
My build commands are in the dockerfile:
https://github.com/swratten/docker-test/blob/master/Dockerfile
As suggested at #314 I ran into this previous error, so I added the workaround for that issue
In the meantime, you can work around this by setting the property
CrossGenDuringPublish
tofalse
.
Running monolinker against itself
Just for chuckles I ran monolinker against itself:
# mono monolinker.exe -a monolinker.exe -c link -u link -d /root/linker/linker/bin/Debug
Fatal error in Mono CIL Linker
Mono.Linker.MarkException: Error processing method: 'System.Int32 Mono.Linker.Driver::Main(System.String[])' in assembly: 'monolinker.exe' ---> Mono.Cecil.ResolutionException: Failed to resolve System.Void System.Console::WriteLine(System.Object)
at Mono.Linker.Steps.MarkStep.HandleUnresolvedMethod (Mono.Cecil.MethodReference reference) [0x0001a] in <b086ec9851fd46808828fe74fca2942a>:0
at Mono.Linker.Steps.MarkStep.MarkMethod (Mono.Cecil.MethodReference reference) [0x00064] in <b086ec9851fd46808828fe74fca2942a>:0
at Mono.Linker.Steps.MarkStep.MarkInstruction (Mono.Cecil.Cil.Instruction instruction) [0x0004f] in <b086ec9851fd46808828fe74fca2942a>:0
at Mono.Linker.Steps.MarkStep.MarkMethodBody (Mono.Cecil.Cil.MethodBody body) [0x000a5] in <b086ec9851fd46808828fe74fca2942a>:0
at Mono.Linker.Steps.MarkStep.ProcessMethod (Mono.Cecil.MethodDefinition method) [0x001a4] in <b086ec9851fd46808828fe74fca2942a>:0
at Mono.Linker.Steps.MarkStep.ProcessQueue () [0x0001f] in <b086ec9851fd46808828fe74fca2942a>:0
--- End of inner exception stack trace ---
at Mono.Linker.Steps.MarkStep.ProcessQueue () [0x0004e] in <b086ec9851fd46808828fe74fca2942a>:0
at Mono.Linker.Steps.MarkStep.ProcessPrimaryQueue () [0x00012] in <b086ec9851fd46808828fe74fca2942a>:0
at Mono.Linker.Steps.MarkStep.Process () [0x00144] in <b086ec9851fd46808828fe74fca2942a>:0
at Mono.Linker.Steps.MarkStep.Process (Mono.Linker.LinkContext context) [0x0000f] in <b086ec9851fd46808828fe74fca2942a>:0
at Mono.Linker.Pipeline.Process (Mono.Linker.LinkContext context) [0x0001f] in <b086ec9851fd46808828fe74fca2942a>:0
at Mono.Linker.Driver.Run () [0x0053b] in <b086ec9851fd46808828fe74fca2942a>:0
at Mono.Linker.Driver.Main (System.String[] args) [0x0001e] in <b086ec9851fd46808828fe74fca2942a>:0
How to whitelist third-party resources?
I'm using Humanizer library in my app in order to provide nice localization of TimeSpans
. I noticed that mono-linker (ILLink.Tasks 0.1.4-preview-1222833
) automatically removes Humanizer resources (those under e.g. pl/Humanizer.resources.dll
) as apparently they're not detected as being used. The core library itself (Humanizer.dll
) is being linked properly, but even its root resources (Humanizer.resources.dll
) are not.
I tried to root entire <assembly fullname="Humanizer" />
in order to "force" inclusion of the resources, but without much luck as despite of entire library being properly linked, its resources are still being removed. I also tried to root <assembly fullname="Humanizer.resources" />
, but since there is no such assembly (as those are resource files only), mono-linker can't locate them.
Is there any way to keep third-party resources (localization) files while still using mono-linker? Perhaps there is some switch I'm not aware of. If not, it'd probably be a good idea to add support for this.
Thank you in advance for response.
Latest ILLink.Task is failing for osx-x64 Runtime Identifier
When I do dotnet publish -c release -r osx-x64
after adding ILLink.Tasks nuget package version 0.1.5-preview-1841731, it fails with the following error:
C:\Program Files\dotnet\sdk\2.1.500\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.CrossGen.targets(72,5): error NETSDK1016: Unable to find resolved path for '...\.nuget\packages\runtime.osx-x64.microsoft.netcore.app\2.1.6\runtimes\osx-x64\native\..\..\..\tools\crossgen.exe'. [....csproj]
Looks like its searching for crossgen.exe
for Mac version, instead of crossgen
.
I tried using older versions (0.14 preview) and it failed with error The "GetRuntimeLibraries" task failed unexpectedly.
I believe this is the same issue discussed in #308 which I think is resolved in later versions.
Blazor error MSB3073 (.Net Core SDK 3.0.100)
This error showes after installing nuget packages EntityFrameworkCore.SqlServer in new project that based on template "Blazor (ASP.NET Core hosted)"
1. My dotnet --info
PM> dotnet --info
.NET Core SDK (reflecting any global.json):
Version: 3.0.100-preview-010184
Commit: c57bde4593
Runtime Environment:
OS Name: Windows
OS Version: 10.0.17134
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\3.0.100-preview-010184\
Host (useful for support):
Version: 3.0.0-preview-27324-5
Commit: 63a01b08e5
.NET Core SDKs installed:
2.1.503 [C:\Program Files\dotnet\sdk]
2.2.103 [C:\Program Files\dotnet\sdk]
3.0.100-preview-010184 [C:\Program Files\dotnet\sdk]
.NET Core runtimes installed:
Microsoft.AspNetCore.All 2.1.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.2.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.2.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.0.0-preview-19075-0444 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.1.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.2.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.0.0-preview-27324-5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 3.0.0-preview-27325-3 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
2. Error text (trimmed)
Error MSB3073
The command "dotnet "C:\Users\User.nuget\packages\microsoft.aspnetcore.blazor.mono\0.8.0-preview-20190204.1\build\netstandard1.0../../tools/illink/illink.dll" -l none --verbose --strip-security true --exclude-feature com --exclude-feature sre -v false -c link -u link -b true -d
"C:\Users\User.nuget\packages\microsoft.aspnetcore.blazor.mono\0.8.0-preview-20190204.1\build\netstandard1.0../../tools/mono/bcl/" -d
"C:\Users\User.nuget\packages\microsoft.aspnetcore.blazor.mono\0.8.0-preview-20190204.1\build\netstandard1.0../../tools/mono/bcl/Facades/" -o
"D:\Projects_awr\Home\WebApplication1\WebApplication1.Client\obj\Debug\netstandard2.0\blazor\linker/" -x
"C:\Users\User.nuget\packages\microsoft.aspnetcore.blazor.build\0.8.0-preview-19104-04\targets\BuiltInBclLinkerDescriptor.xml" -x
"D:\Projects_awr\Home\WebApplication1\WebApplication1.Client\obj\Debug\netstandard2.0\blazor\linker.descriptor.xml" -a
"C:\Users\User.nuget\packages\microsoft.aspnetcore.blazor\0.8.0-preview-19104-04\lib\netstandard2.0\Microsoft.AspNetCore.Blazor.dll" -a
"C:\Users\User.nuget\packages\microsoft.aspnetcore.components\3.0.0-preview-19075-0444\lib\netstandard2.0\Microsoft.AspNetCore.Components.dll" -a
"C:\Users\User.nuget\packages\microsoft.aspnetcore.components.browser\3.0.0-preview-19075-0444\lib\netstandard2.0\Microsoft.AspNetCore.Components.Browser.dll" -a
"C:\Users\User.nuget\packages\microsoft.entityframeworkcore\2.2.1\lib\netstandard2.0\Microsoft.EntityFrameworkCore.dll" -a
"C:\Users\User.nuget\packages\microsoft.entityframeworkcore.abstractions\2.2.1\lib\netstandard2.0\Microsoft.EntityFrameworkCore.Abstractions.dll" -a
"C:\Users\User.nuget\packages\microsoft.entityframeworkcore.relational\2.2.1\lib\netstandard2.0\Microsoft.EntityFrameworkCore.Relational.dll" -a
"C:\Users\User.nuget\packages\microsoft.entityframeworkcore.sqlserver\2.2.1\lib\netstandard2.0\Microsoft.EntityFrameworkCore.SqlServer.dll" -a
"C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.extensions.caching.abstractions\2.2.0\lib\netstandard2.0\Microsoft.Extensions.Caching.Abstractions.dll" -a
"C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.extensions.caching.memory\2.2.0\lib\netstandard2.0\Microsoft.Extensions.Caching.Memory.dll" -a
"C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.extensions.configuration\2.2.0\lib\netstandard2.0\Microsoft.Extensions.Configuration.dll" -a
......
"C:\Program Files\dotnet\sdk\NuGetFallbackFolder\system.security.principal.windows\4.5.0\runtimes\win\lib\netstandard1.3\System.Security.Principal.Windows.dll" -a "C:\Program Files\dotnet\sdk\NuGetFallbackFolder\system.text.encoding.codepages\4.5.0\runtimes\win\lib\netstandard2.0\System.Text.Encoding.CodePages.dll" -a "D:\Projects_awr\Home\WebApplication1\WebApplication1.Shared\bin\Debug\netstandard2.0\WebApplication1.Shared.dll" -a "D:\Projects_awr\Home\WebApplication1\WebApplication1.Client\obj\Debug\netstandard2.0\WebApplication1.Client.dll"
" exited with code 1.
WebApplication1.Client
C:\Users\User.nuget\packages\microsoft.aspnetcore.blazor.build\0.8.0-preview-19104-04\targets\Blazor.MonoRuntime.targets 439
Add members accessible due ComVisibleAttribute handling
The linker was trimming an internal interface because it didn't see any uses, but it would be used by COM. The managed code passes the object implementing that interface to native code and the native code would QI for the interface. Runtime would return the CCW for the interface but that would be missing the necessary methods and native code AV'ed when calling it.
We should look at a heuristic for identifying these interfaces.
@jkotas suggests looking at the ComImportAttribute: I'm not sure that's sufficient. I think technically any COMVisible interface would fall in this bucket. I believe most interfaces are COMVisible by default, but @luqunl would know better here.
/cc @sbomer @erozenfeld
NullReferenceException at Mono.Linker.Steps.MarkStep.SearchPropertiesForMatchingFieldDefinition.
Dear, after update Visual Studio 2017 to 15.5.2 when I try generate a new Android release of my app I get this error:
error MSB4018: The "LinkAssemblies" task failed unexpectedly.
error MSB4018: System.NullReferenceException: Object reference not set to an instance of an object.
error MSB4018: at Mono.Linker.Steps.MarkStep.SearchPropertiesForMatchingFieldDefinition(FieldDefinition field)
error MSB4018: at Mono.Linker.Steps.MarkStep.MarkFields(TypeDefinition type, Boolean includeStatic, Boolean markBackingFieldsOnlyIfPropertyMarked)
error MSB4018: at Mono.Linker.Steps.MarkStep.ApplyPreserveInfo(TypeDefinition type)
error MSB4018: at Mono.Linker.Steps.MarkStep.MarkType(TypeReference reference)
error MSB4018: at MonoDroid.Tuner.MonoDroidMarkStep.MarkType(TypeReference reference)
error MSB4018: at Mono.Linker.Steps.MarkStep.InitializeType(TypeDefinition type)
error MSB4018: at Mono.Linker.Steps.MarkStep.InitializeAssembly(AssemblyDefinition assembly)
error MSB4018: at Mono.Linker.Steps.MarkStep.Initialize()
error MSB4018: at Mono.Linker.Steps.MarkStep.Process(LinkContext context)
error MSB4018: at Mono.Linker.Pipeline.Process(LinkContext context)
error MSB4018: at MonoDroid.Tuner.Linker.Process(LinkerOptions options, LinkContext& context)
error MSB4018: at Xamarin.Android.Tasks.LinkAssemblies.Execute(DirectoryAssemblyResolver res)
error MSB4018: at Xamarin.Android.Tasks.LinkAssemblies.Execute()
error MSB4018: at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
error MSB4018: at Microsoft.Build.BackEnd.TaskBuilder.d__26.MoveNext()
I already reported the issue on VS community (https://developercommunity.visualstudio.com/content/problem/175090/the-linkassemblies-task-failed-unexpectedly-with-v.html), but, anybody know some productive way of I investigate/debug this issue? How can I collect more clues about the problem? Although configured VS in diagnostic mode, I do not see any useful information in the logs that might indicate the motivation for the problem.
Are there some way of detect what the specific motivation of the exception?
Provide a clearer error message when IL Linker fails due to a native dependency
From @Awr0ra on Friday, 08 February 2019 23:17:09
This error showes after installing nuget packages EntityFrameworkCore.SqlServer in new project that based on template "Blazor (ASP.NET Core hosted)"
1. My dotnet --info
PM> dotnet --info
.NET Core SDK (reflecting any global.json):
Version: 3.0.100-preview-010184
Commit: c57bde4593
Runtime Environment:
OS Name: Windows
OS Version: 10.0.17134
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\3.0.100-preview-010184\
Host (useful for support):
Version: 3.0.0-preview-27324-5
Commit: 63a01b08e5
.NET Core SDKs installed:
2.1.503 [C:\Program Files\dotnet\sdk]
2.2.103 [C:\Program Files\dotnet\sdk]
3.0.100-preview-010184 [C:\Program Files\dotnet\sdk]
.NET Core runtimes installed:
Microsoft.AspNetCore.All 2.1.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.2.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.2.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.0.0-preview-19075-0444 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.1.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.2.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.0.0-preview-27324-5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 3.0.0-preview-27325-3 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
2. Error text (trimmed)
Error MSB3073
The command "dotnet "C:\Users\User.nuget\packages\microsoft.aspnetcore.blazor.mono\0.8.0-preview-20190204.1\build\netstandard1.0../../tools/illink/illink.dll" -l none --verbose --strip-security true --exclude-feature com --exclude-feature sre -v false -c link -u link -b true -d
"C:\Users\User.nuget\packages\microsoft.aspnetcore.blazor.mono\0.8.0-preview-20190204.1\build\netstandard1.0../../tools/mono/bcl/" -d
"C:\Users\User.nuget\packages\microsoft.aspnetcore.blazor.mono\0.8.0-preview-20190204.1\build\netstandard1.0../../tools/mono/bcl/Facades/" -o
"D:\Projects_awr\Home\WebApplication1\WebApplication1.Client\obj\Debug\netstandard2.0\blazor\linker/" -x
"C:\Users\User.nuget\packages\microsoft.aspnetcore.blazor.build\0.8.0-preview-19104-04\targets\BuiltInBclLinkerDescriptor.xml" -x
"D:\Projects_awr\Home\WebApplication1\WebApplication1.Client\obj\Debug\netstandard2.0\blazor\linker.descriptor.xml" -a
"C:\Users\User.nuget\packages\microsoft.aspnetcore.blazor\0.8.0-preview-19104-04\lib\netstandard2.0\Microsoft.AspNetCore.Blazor.dll" -a
"C:\Users\User.nuget\packages\microsoft.aspnetcore.components\3.0.0-preview-19075-0444\lib\netstandard2.0\Microsoft.AspNetCore.Components.dll" -a
"C:\Users\User.nuget\packages\microsoft.aspnetcore.components.browser\3.0.0-preview-19075-0444\lib\netstandard2.0\Microsoft.AspNetCore.Components.Browser.dll" -a
"C:\Users\User.nuget\packages\microsoft.entityframeworkcore\2.2.1\lib\netstandard2.0\Microsoft.EntityFrameworkCore.dll" -a
"C:\Users\User.nuget\packages\microsoft.entityframeworkcore.abstractions\2.2.1\lib\netstandard2.0\Microsoft.EntityFrameworkCore.Abstractions.dll" -a
"C:\Users\User.nuget\packages\microsoft.entityframeworkcore.relational\2.2.1\lib\netstandard2.0\Microsoft.EntityFrameworkCore.Relational.dll" -a
"C:\Users\User.nuget\packages\microsoft.entityframeworkcore.sqlserver\2.2.1\lib\netstandard2.0\Microsoft.EntityFrameworkCore.SqlServer.dll" -a
"C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.extensions.caching.abstractions\2.2.0\lib\netstandard2.0\Microsoft.Extensions.Caching.Abstractions.dll" -a
"C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.extensions.caching.memory\2.2.0\lib\netstandard2.0\Microsoft.Extensions.Caching.Memory.dll" -a
"C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.extensions.configuration\2.2.0\lib\netstandard2.0\Microsoft.Extensions.Configuration.dll" -a
......
"C:\Program Files\dotnet\sdk\NuGetFallbackFolder\system.security.principal.windows\4.5.0\runtimes\win\lib\netstandard1.3\System.Security.Principal.Windows.dll" -a "C:\Program Files\dotnet\sdk\NuGetFallbackFolder\system.text.encoding.codepages\4.5.0\runtimes\win\lib\netstandard2.0\System.Text.Encoding.CodePages.dll" -a "D:\Projects_awr\Home\WebApplication1\WebApplication1.Shared\bin\Debug\netstandard2.0\WebApplication1.Shared.dll" -a "D:\Projects_awr\Home\WebApplication1\WebApplication1.Client\obj\Debug\netstandard2.0\WebApplication1.Client.dll"
" exited with code 1.
WebApplication1.Client
C:\Users\User.nuget\packages\microsoft.aspnetcore.blazor.build\0.8.0-preview-19104-04\targets\Blazor.MonoRuntime.targets 439
Copied from original issue: aspnet/Blazor#1784
The linker should root methods on COM interfaces when running with -r option
When running with -r the linker roots only methods visible from outside of the assembly (unlike with -a, which roots all methods in an assembly).
Methods on interfaces marked by System.Runtime.InteropServices.InterfaceTypeAttribute can be called from native code via COM-callable wrappers so they should be rooted.
We ran into this in dotnet/corefx#30092
Getting NU1202 Package Microsoft.NETCore.App 2.0.9 is not compatible with netstandard2.0
From @Petermarcu on September 11, 2018 20:18
@MihaMarkic commented on Tue Sep 11 2018
Issue Title
When publishing project, I'm getting some NU1202 errors:
...\AutoMasshTik.Engine.csproj : error NU1202: Package Microsoft.NETCore.App 2.0.9 is not compatible with netstandard2.0 (.NETStandard,Version=v2.0). Package Microsoft.NETCore.App 2.0.9 supports: [...\AutoMasshTik\src\AutoMasshTik.UI\AutoMasshTik.UI.csproj]
...\AutoMasshTik.Engine.csproj : error NU1202: - netcoreapp (.NETCoreApp,Version=v0.0) [...\AutoMasshTik\src\AutoMasshTik.UI\AutoMasshTik.UI.csproj]
...\AutoMasshTik.Engine.csproj : error NU1202: - netcoreapp2.0 (.NETCoreApp,Version=v2.0) [...\AutoMasshTik\src\AutoMasshTik.UI\AutoMasshTik.UI.csproj]
...\AutoMasshTik.Engine.csproj : error NU1202: Package Microsoft.NETCore.App 2.0.9 is not compatible with netstandard2.0 (.NETStandard,Version=v2.0) / win10-x86. Package Microsoft.NETCore.App 2.0.9 supports: [...\AutoMasshTik\src\AutoMasshTik.UI\AutoMasshTik.UI.csproj]
...\AutoMasshTik.Engine.csproj : error NU1202: - netcoreapp (.NETCoreApp,Version=v0.0) [...\AutoMasshTik\src\AutoMasshTik.UI\AutoMasshTik.UI.csproj]
...\AutoMasshTik.Engine.csproj : error NU1202: - netcoreapp2.0 (.NETCoreApp,Version=v2.0) [...\AutoMasshTik\src\AutoMasshTik.UI\AutoMasshTik.UI.csproj]
General
The project in question is AutoMasshTik.
I invoke something like
dotnet publish -o somepath\files -r win10-x86 -c release /p:ShowLinkerSizeComparison=true
and get those errors.
dotnet restore
does not have issues and the project can be published/run just fine otherwise.
Note: you have to add latest ILLink.Tasks 0.1.5-preview-1841731 to AutoMasshTik.UI.csproj.
Copied from original issue: dotnet/coreclr#19896
CodeOptimizations should be in its own file
For consumers who don't use Driver.cs (have our own Main
, it's inconvenient to have CodeOptimizations
which is used by LinkerContext
declared in Driver.cs.
This was done in:
50c1ddb by @marek-safar
Linker incorrectly removes event implementation
Testcase:
public delegate void VectorChangedEventHandler<T>();
public interface IObservableVector<T>
{
event VectorChangedEventHandler<T> Foo;
void bar ();
}
class BaseFoo {
public event VectorChangedEventHandler<object> Foo;
public BaseFoo () {
}
}
class ClassFoo : BaseFoo, IObservableVector<object>
{
public void bar () {
}
}
class BaseFoo2 : IObservableVector<object>
{
public event VectorChangedEventHandler<object> Foo;
public BaseFoo2 () {
Foo ();
}
public void bar () {
}
}
public class Tests
{
public static void Main (String[] args) {
IObservableVector<object> f2 = new BaseFoo2 ();
f2.Foo += delegate () {};
IObservableVector<object> f = new ClassFoo ();
f.bar ();
}
}
Link with:
monolinker -a bug.exe -c link
In the resulting IL, the ClassFoo class implements IObservableVector, but neither it or its base type contains the implementations for the add_Foo/remove_Foo methods from IObservableVector.
Linker doesn't remove overridden methods in unused classes
The linker doesn't remove overridden methods even if no instances of the containing type are created,
which means the ctors are removed, so there is no way to create instances of the type.
This affects code in mscorlib, i.e. the override ModuleBuilder::GetTypes () is retained even if SRE is not used, causing a large part of SRE to also be retained, since GetTypes () ends up calling TypeBuilder::CreateType ().
Testcase:
using System;
public class ParentClass
{
public virtual void foo () {
}
}
public class ChildClass : ParentClass
{
// This ends up being retained
public override void foo () {
}
public void bar () {
}
}
public class Tests
{
public static void Main () {
var p = new ParentClass ();
var t = typeof (ChildClass);
Activator.CreateInstance (t);
p.foo ();
}
}
Single Linker config for .NET Native and Mono
I fully support the idea of a linker in .NET Core but please consolidate the linker directives. There's rd.xml for .NET Native and this new thing. Please pick one and use it for both toolchains. Otherwise we'll need to duplicate linker directives and that's going to lead to errors.
ILLink.Tasks fails on latest dotnet sdk
Using the 3.0 dotnet SDK, create a new project and add a reference to the latest illink.tasks.
C:\Users\ericstj\.nuget\packages\illink.tasks\0.1.5-preview-1841731\build\ILLink.Tasks.targets(511,11): error MSB4057: The target "_HandlePublishFileConflicts" does not exist in the project.
This was broken by dotnet/sdk@1936ebd /cc @peterhuene @dsplaisted
We either need to react to that change in the SDK or undo it.
This is related to discussion here: dotnet/sdk#2583
Using linker for a solution
Hi! I have a set of .NET Core projects which I output into same directory. I use self-contained deployment and equalize package versions with an extra script.
Is there a way I can benefit from using linker? Can I use it on a solution somehow?
Maybe it can have an option to exclude only completely unused assemblies.
Add optimisation step for Invariant Arrays
Classes that don't pass their arrays out by reference; and only directly instantiate them (new T[n]
) (rather than setting the array field to something passed by argument or result of external call, could have their element stores changed from covariant stores to invariant stores.
From https://github.com/dotnet/corefx/issues/23689#issuecomment-378283974
@Suchiman I like your idea of enabling this optimization without requiring code changes everywhere! We can start with implementing it in ILLinker to measure the benefit and prove its usefulness, and maybe later in Roslyn. We have taken the same journey for SkipLocalsInit. The implementation in ILLinker can:
- Do escape analysis to identify all arrays that are just used as internal implementation detail (that do not escape outside the assembly - assuming there is no private reflection) and that do not use array covariance
- Use alternative more efficient sequence for storing elements into them.
For example the store in coreclr List<T>.Add(T)
public partial class List<T>
{
private T[] _items;
public void Add(T item)
{
_version++;
T[] array = _items;
int size = _size;
if ((uint)size < (uint)array.Length)
{
_size = size + 1;
array[size] = item; // array element store
}
else
{
AddWithResize(item);
}
}
}
Could have the il changed from something like
ldloc.0
ldloc.1
ldarg.1
stelem !T // Covariant store
To something like
ldloc.0
ldloc.1
readonly.
ldelema !T
ldarg.1
stobj !T // Invariant store
IL Linker does not remove unused classes / methods
It is stated here that
The linker removes code in your application and dependent libraries that are not reached by any code paths
I am following these instructions. Before publishing the app I add unused class to the project:
echo internal class UnusedClass { private class UnusedNestedClass { private void UnusedMethod() { System.Console.WriteLine("This method is never called.");}}}> UnusedClass.cs
To make sure the linker processes the main assembly add these lines to the testapp.csproj
file:
<PropertyGroup>
<ExtraLinkerArgs>-c link -u link -t -l none -b true --skip-unresolved true --verbose</ExtraLinkerArgs>
</PropertyGroup>
My publish command:
dotnet publish -c release -r win-x64 -o out /p:ShowLinkerSizeComparison=true
After publishing decompile out/testapp.dll
(I use ILSpy).
Expected: UnusedClass is removed.
Actual: UnusedClass is still there.
dotnet --version: 2.1.300-preview2-008533
IL Linker from this package
Need a safe way to supply a long list of assemblies to link
While investigating #369, I found that the reason the linker was complaining that it couldn't find certain assemblies was because it was looking for malformed paths. Certain characters were missing from apparently random places in the middle of path strings.
The reason for this appears to be:
- Blazor's build config generates a command for the linker that includes
-a path1\Assembly1.dll -a path2\Assembly2.dll -a path3\Assembly3.dll ...
, where the list of assemblies is all those transitively reachable from the app's entrypoint assembly - All those assemblies can be in totally different directories because of how NuGet works. Therefore if the linker is to find them, we have to specify their locations explictly with an
-a path\AssemblyName.dll
entry for each one, or alteratively specify-d path
for each one, which is equally problematic. - The
Microsoft.CodeAnalysis.CSharp.Features
assembly pulls in a long list of transitive dependencies, as do various other NuGet packages in real-world use. - The total length of the generated command, then, can easily be many thousands of characters, given that each dependency's path could be 100-200 chars.
- MSBuild has a longstanding bug whereby extremely long commands get corrupted, removing characters from arbitrary points in the middle: dotnet/msbuild#2530
- Thus the linker receives corrupted paths and fails
Proposed workaround:
- Is there any existing way to specify the paths to a large number of transitive dependencies without including them all in the command-line command? For example, do any of the linker config file formats allow us to give path hints for transitive dependencies? Blazor already generates a linker config file as part of its build process, so we could extend this to making it list all the dependencies and their paths.
- Or if not, would you be open to adding a further option to the linker, which is to let the user pass a file that gives the paths to all the dependencies, or perhaps just a list of directory paths in which to search for referenced assemblies?
Unable to find resolved path for 'coreclr'
Description
NBxplorer is a netcoreapp2.1
referencing NBXplorer.Client, a library in the same project targetting netcoreapp2.1
.
Compiling NBXplorer with ILLink gives Unable to find resolved path for 'coreclr'
error.
Note: If NBXplorer.Client is targetting netstandard2.0
, it does not work either. If I target netstandard2.0
I get NBXplorer.Client depends on Microsoft.AspNetCore.App (>= 2.1.0-rc1) but Microsoft.AspNetCore.App 2.1.0-rc1 was not found
.
Despite the fact NBXplorer.Client does not depend on it.
Repro
git clone https://github.com/dgarage/NBXplorer
cd NBXplorer
git checkout smalldocker
docker build -t nicolasdorier/nbxplorer .
For convenience, here is the dockerfile
FROM microsoft/dotnet:2.1.300-rc1-sdk-alpine3.7 AS builder
WORKDIR /source
COPY NBXplorer/NBXplorer.csproj NBXplorer/NBXplorer.csproj
# Cache some dependencies
RUN cd NBXplorer && dotnet restore && cd ..
COPY . .
RUN cd NBXplorer && \
dotnet add package ILLink.Tasks --version 0.1.5-preview-1461378 --source https://dotnet.myget.org/F/dotnet-core/api/v3/index.json && \
dotnet publish --output /app/ --configuration Release -r linux-musl-x64
FROM microsoft/dotnet:2.1.0-rc1-runtime-deps-alpine3.7
WORKDIR /app
RUN mkdir /datadir
ENV NBXPLORER_DATADIR=/datadir
VOLUME /datadir
COPY --from=builder "/app" .
ENTRYPOINT ["./NBXplorer"]
Building without ILLink works fine.
Linker shrinks too aggressively
Hi, Team.
I have a small .NET Core console app using this linker
. Here's my repository:
https://github.com/TeamYARM/YARM-CLI
When I build and publish the console app without linker, it works perfectly fine. However, when I build and publish it with linker, it throws the following error:
Unhandled Exception: System.AggregateException: One or more errors occurred. (The SSL connection could not be established, se
e inner exception.) ---> System.Net.Http.HttpRequestException: The SSL connection could not be established, see inner excepti
on. ---> System.IO.IOException: Unable to write data to the transport connection: The lazily-initialized type does not have a
public, parameterless constructor.. ---> System.MissingMemberException: The lazily-initialized type does not have a public,
parameterless constructor.
at System.Threading.LazyInitializer.EnsureInitializedCore[T](T& target)
at System.Net.Sockets.Socket.SendAsyncForNetworkStream(ReadOnlyMemory`1 buffer, SocketFlags socketFlags, CancellationToken
cancellationToken)
at System.Net.Sockets.NetworkStream.WriteAsync(Byte[] buffer, Int32 offset, Int32 size, CancellationToken cancellationToke
n)
--- End of inner exception stack trace ---
at System.Net.Sockets.NetworkStream.WriteAsync(Byte[] buffer, Int32 offset, Int32 size, CancellationToken cancellationToke
n)
at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest
)
at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)
at System.Net.Security.SslStream.BeginAuthenticateAsClient(SslClientAuthenticationOptions sslClientAuthenticationOptions,
CancellationToken cancellationToken, AsyncCallback asyncCallback, Object asyncState)
at System.Net.Security.SslStream.<>c.<AuthenticateAsClientAsync>b__47_0(SslClientAuthenticationOptions arg1, CancellationT
oken arg2, AsyncCallback callback, Object state)
at System.Threading.Tasks.TaskFactory`1.FromAsyncImpl[TArg1,TArg2](Func`5 beginMethod, Func`2 endFunction, Action`1 endAct
ion, TArg1 arg1, TArg2 arg2, Object state, TaskCreationOptions creationOptions)
at System.Net.Security.SslStream.AuthenticateAsClientAsync(SslClientAuthenticationOptions sslClientAuthenticationOptions,
CancellationToken cancellationToken)
at System.Net.Http.ConnectHelper.EstablishSslConnectionAsyncCore(Stream stream, SslClientAuthenticationOptions sslOptions,
CancellationToken cancellationToken)
--- End of inner exception stack trace ---
at System.Net.Http.ConnectHelper.EstablishSslConnectionAsyncCore(Stream stream, SslClientAuthenticationOptions sslOptions,
CancellationToken cancellationToken)
at System.Net.Http.HttpConnectionPool.CreateConnectionAsync(HttpRequestMessage request, CancellationToken cancellationToke
n)
at System.Net.Http.HttpConnectionPool.WaitForCreatedConnectionAsync(ValueTask`1 creationTask)
at System.Net.Http.HttpConnectionPool.SendWithRetryAsync(HttpRequestMessage request, Boolean doRequestAuth, CancellationTo
ken cancellationToken)
at System.Net.Http.RedirectHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
at System.Net.Http.HttpClient.FinishSendAsyncUnbuffered(Task`1 sendTask, HttpRequestMessage request, CancellationTokenSour
ce cts, Boolean disposeCts)
at System.Net.Http.HttpClient.GetStringAsyncCore(Task`1 getTask)
at Yarm.ConsoleApp.Converter.ReadFileAsync(String filepath, HttpClient client) in C:\Dev\TY\YARM-CLI\src\Yarm.ConsoleApp\C
onverter.cs:line 95
at Yarm.ConsoleApp.Converter.ParseAsync(Options options, HttpClient client) in C:\Dev\TY\YARM-CLI\src\Yarm.ConsoleApp\Conv
erter.cs:line 34
--- End of inner exception stack trace ---
at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken)
at Yarm.ConsoleApp.Program.<>c.<Main>b__3_1(Options options) in C:\Dev\TY\YARM-CLI\src\Yarm.ConsoleApp\Program.cs:line 25
at CommandLine.ParserResultExtensions.WithParsed[T](ParserResult`1 result, Action`1 action)
at Yarm.ConsoleApp.Program.Main(String[] args) in C:\Dev\TY\YARM-CLI\src\Yarm.ConsoleApp\Program.cs:line 25
Apparently, it removes something too aggressively. Would you be able to look at the issue, please? You can reproduce the same error by following the steps below:
- Clone my repo: https://github.com/TeamYARM/YARM-CLI
- Build the app with this command:
dotnet build -c Release -r win-x64
- Publish the app with this command:
dotnet publish -c Release -r win-x64 -o published /p:ShowLinkerSizeComparison=true
- Run the console app with this command:
yarm -i https://raw.githubusercontent.com/TeamYARM/YARM-CLI/master/samples/azuredeploy.yaml
Of course the error message above is only applicable for my case, but linker
has certainly impacts on publishing my app.
Preserve more context for EventDataAttribute
Two common patterns for trace logging payload is using classes marked by [EventData] or using anonymous types: https://docs.microsoft.com/en-us/windows/desktop/tracelogging/tracelogging-managed-quick-start . EventSource uses reflection to get to the properties of the payload.
The linker already preserves public instance methods of reachable types with [EventData] attribute: https://github.com/mono/linker/blob/master/linker/Linker.Steps/MarkStep.cs#L1012
It should do the same for reachable anonymous types.
Emit deterministic output
Currently, the linker output is not deterministic since the generated assemblies contain a random guid.
Emitting a computed guid like csc does with /deterministic would help build systems avoid rebuilding things which depend on the linker outputs.
This will require changes in both cecil and the linker.
Add TypeDescriptor.GetConverter heuristic
System.ComponentModel.TypeDescriptor.GetConverter
can't properly work if these types are linked away. And it's reflection based, so linker is unable to find any references.
For now we are using https://raw.githubusercontent.com/wieslawsoltes/Core2D/04f95ee8c83e1bc5d4246db805dedfaec3156e3d/apps/Core2D.Avalonia.NetCore/linker.xml configuration file, but that should be excluded on linker level, I think.
" Too many open files" in ModuleDefinition.ReadModule
We got this reported one-off in building .NET CoreFX for Mac. May not be actionable - but here you are in case. Perhaps a dispose is missing on some FileStream, so it's possible for too many to get opened at once.
On Mac, Build.sh –Release failed, please see below output. Please give some suggestion for this if you can.
Fatal error in IL Linker
System.IO.IOException: Too many open files
at Interop.ThrowExceptionForIoErrno(ErrorInfo errorInfo, String path, Boolean isDirectory, Func`2 errorRewriter)
at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String path, OpenFlags flags, Int32 mode)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options)
at Mono.Cecil.ModuleDefinition.ReadModule(String fileName, ReaderParameters parameters)
at Mono.Linker.DirectoryAssemblyResolver.GetAssembly(String file, ReaderParameters parameters)
at Mono.Linker.DirectoryAssemblyResolver.SearchDirectory(AssemblyNameReference name, IEnumerable`1 directories, ReaderParameters parameters)
at Mono.Linker.DirectoryAssemblyResolver.Resolve(AssemblyNameReference name, ReaderParameters parameters)
at Mono.Linker.AssemblyResolver.Resolve(AssemblyNameReference name, ReaderParameters parameters)
at Mono.Linker.DirectoryAssemblyResolver.Resolve(AssemblyNameReference name)
at Mono.Cecil.MetadataResolver.Resolve(TypeReference type)
at Mono.Linker.TypeReferenceExtensions.<GetMethods>d__4.MoveNext()
at Mono.Linker.Steps.TypeMapStep.TryMatchMethod(TypeReference type, MethodDefinition method)
at Mono.Linker.Steps.TypeMapStep.GetBaseMethodInTypeHierarchy(TypeDefinition type, MethodDefinition method)
at Mono.Linker.Steps.TypeMapStep.GetBaseMethodInTypeHierarchy(MethodDefinition method)
at Mono.Linker.Steps.TypeMapStep.MapVirtualBaseMethod(MethodDefinition method)
at Mono.Linker.Steps.TypeMapStep.MapVirtualMethod(MethodDefinition method)
at Mono.Linker.Steps.TypeMapStep.MapVirtualMethods(TypeDefinition type)
at Mono.Linker.Steps.TypeMapStep.MapType(TypeDefinition type)
at Mono.Linker.Steps.TypeMapStep.ProcessAssembly(AssemblyDefinition assembly)
at Mono.Linker.Steps.BaseStep.Process(LinkContext context)
at Mono.Linker.Pipeline.Process(LinkContext context)
at Mono.Linker.Driver.Run()
at Mono.Linker.Driver.Main(String[] args)
Skip entire assembly
Is it possible to skip an entire assembly from the xml descriptor file? If positive how?
Unhandled exception on linked app
I'm using ILLink.Tasks in version 0.1.4-preview-981901.
During runtime of my linked app I've stumbled upon the following issue:
2017-10-23 13:19:33|ArchiSteamFarm-9808|FATAL|ASF|OnUnhandledException() System.ArgumentNullException: Value cannot be null.
Parameter name: method
at System.Linq.Expressions.Expression.Call(MethodInfo method, Expression arg0)
at System.Runtime.CompilerServices.CallSite`1.CreateCustomNoMatchDelegate(MethodInfo invoke)
at System.Runtime.CompilerServices.CallSite`1.MakeUpdateDelegate()
at System.Runtime.CompilerServices.CallSite`1.GetUpdateDelegate(T& addr)
at System.Runtime.CompilerServices.CallSite`1.Create(CallSiteBinder binder)
at ArchiSteamFarm.ArchiWebHandler.<GetServerTime>d__39.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at ArchiSteamFarm.MobileAuthenticator.<GetSteamTime>d__22.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at ArchiSteamFarm.MobileAuthenticator.<GenerateToken>d__15.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at ArchiSteamFarm.Bot.<OnConnected>d__141.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadPoolWorkQueue.Dispatch()
I suspect this is because GetServerTime()
uses dynamic
field inside, therefore reflection. Could you help me with creating appropriate linker.xml
for this case? I've tried to use <LinkerRootAssemblies Include="System.Runtime" />
but without luck. I'd appreciate a helpful hand, thank you in advance 👍.
Automagically remove F# compilation resources
The linker can/should automatically remove any .NET manifest assembly resources named FSharpSignatureData.*
and FSharpOptimizationData.*
during linking.
These are only ever needed for F# compilation which doesn't happen on-device and given the aims of the linker it is reasonable to assume this data is unreachable.
My understanding is that removing these would trim about 1.5MB off the size of all applications using FSharp.Core.dll, and about 3MB off all applications using Elmish.XamarinForms.dll.
Here's an example of how the resources look in ILDASM:
.mresource public FSharpSignatureData.Elmish.XamarinForms
.mresource public FSharpOptimizationData.Elmish.XamarinForms
Thanks
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.