dotnet / linker Goto Github PK

C# 94.34% Shell 2.01% Batchfile 0.02% PowerShell 3.34% CMake 0.27% C++ 0.02%

linker's Introduction

LINKER REPO IS ARCHIVED

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 People

Contributors

Stargazers

Watchers

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 iserrato

linker's Issues

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.

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.

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.

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 👍.

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

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.

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.

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

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

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.

Fatal error in IL Linker during Mono.Linker.TypeReferenceExtensions.GetMethods

https://dev.azure.com/dnceng/public/_build/results?buildId=75548&view=logs&jobId=05c104f8-fcb4-51be-f321-25b9d6e03ec7&taskId=a92d3a56-b430-5652-8fab-d4edc42f6ab6&lineStart=2285&lineEnd=2300&colStart=1&colEnd=99

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

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.

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

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

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.

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.

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 form file.exe directly reads the file if it exists.
It also accepts just file and resolves the name as an assembly.
https://github.com/mono/linker/blame/master/linker/Mono.Linker/LinkContext.cs#L159-L168
-x: Does not accept files.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

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

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.

https://github.com/mono/linker/blob/7dce9327c11798b4811d2b376a8fcbc2fc399f2e/linker/Linker/Driver.cs#L508-L512

This was done in:
50c1ddb by @marek-safar

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?

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)

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?

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.

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.

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.

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)

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.

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

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]

2. Error text (trimmed)

......

Copied from original issue: aspnet/Blazor#1784

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

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.

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 ();
	}
}

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

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 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

/cc @jkotas @mjp41 @VSadov @jaredpar

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.

Skip entire assembly

Is it possible to skip an entire assembly from the xml descriptor file? If positive how?

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.

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.

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.).

" 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)

@erozenfeld

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.

@sbomer @jeffschwMSFT @brianrob

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.

@sbomer

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

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 to false.

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

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.

CI output for reference, if needed

Add members accessible due ComVisibleAttribute handling

See dotnet/corefx#32491

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

dotnet / linker Goto Github PK

linker's Introduction

LINKER REPO IS ARCHIVED

linker's People

Contributors

Stargazers

Watchers

Forkers

linker's Issues

Description

Repro

1. My dotnet --info

2. Error text (trimmed)

Issue Title

General

1. My dotnet --info

2. Error text (trimmed)

Issue

Steps

Stacktrace:

Recommend Projects

Recommend Topics

Recommend Org