man/illinkanalyzer.1

   1 .TH illinkanalyzer 1
   2 .SH NAME
   3 illinkanalyzer \- Mono's linker analyzer tool
   4 .SH SYNOPSIS
   5 .B illinkanalyzer
   6 \fR[\fIoptions\fR] <\fIlinker-dependency-file.xml.gz\fR>
   7 .SH DESCRIPTION
   8 Linker analyzer is a command line tool to analyze dependencies, which
   9 were recorded during linker processing, and led linker to mark an item
  10 to keep it in the resulting linked assembly.
  11 .PP
  12 It works on an oriented graph of dependencies, which are collected and
  13 dumped during the linker run. The vertices of this graph are the items
  14 of interest like assemblies, types, methods, fields, linker steps,
  15 etc. The edges represent the dependencies.
  16 .SH HOW TO DUMP DEPENDENCIES
  17 The linker analyzer needs a linker dependencies file as an input. It
  18 can be retrieved by enabling dependencies dumping during linking of a
  19 Xamarin.Android or a Xamarin.iOS project.
  20 .PP
  21 That can be done on the command line by setting LinkerDumpDependencies
  22 property to true and building the project. (make sure the
  23 LinkAssemblies task is called, it might require cleaning the project
  24 sometimes) Usually it is enough to build the project like this:
  25 .PP
  26 .nf
  27 .RS
  28 rm -f obj/Release/link.flag
  29 msbuild /p:LinkerDumpDependencies=true /p:Configuration=Release YourAppProject.csproj
  30 .RE
  31 .fi
  32 .PP
  33 After a successful build, there will be a linker-dependencies.xml.gz
  34 file created, containing the information for the analyzer.
  35 .SH OPTIONS
  36 .nf
  37 .RS
  38   -a, --alldeps              show all dependencies
  39       --csvoutput=VALUE      outputs types and optionally size analysis to CSV
  40                                file
  41   -h, --help                 show this message and exit.
  42   -l, --linkedpath=VALUE     sets the linked assemblies directory path. Enables
  43                                displaying size estimates.
  44   -r, --rawdeps=VALUE        show raw vertex dependencies. Raw vertex VALUE is
  45                                in the raw format written by linker to the
  46                                dependency XML file. VALUE can be regular
  47                                expression
  48       --roots                show root dependencies.
  49       --stat                 show statistic of loaded dependencies.
  50       --tree                 reduce the dependency graph to the tree.
  51       --types                show all types dependencies.
  52   -t, --typedeps=VALUE       show type dependencies. The VALUE can be regular
  53                                expression
  54   -f, --flat                 show all dependencies per vertex and their distance
  55   -v, --verbose              be more verbose. Enables stat and roots options.
  56 .RE
  57 .fi
  58 .SH EXAMPLES
  59 Let say you would like to know, why a type, Android.App.Activity for
  60 example, was marked by the linker. So run the analyzer like this:
  61 .PP
  62 .nf
  63 .RS
  64 illinkanalyzer -t Android.App.Activity linker-dependencies.xml.gz
  65 .fi
  66 .RE
  67 .PP
  68 Output:
  69 .PP
  70 .nf
  71 .RS
  72 Loading dependency tree from: linker-dependencies.xml.gz
  73
  74 --- Type dependencies: 'Android.App.Activity' -----------------------
  75
  76 --- TypeDef:Android.App.Activity dependencies -----------------------
  77 Dependency #1
  78         TypeDef:Android.App.Activity
  79         | TypeDef:XA.App.MainActivity [2 deps]
  80         | Assembly:XA.App, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null [3 deps]
  81         | Other:Mono.Linker.Steps.ResolveFromAssemblyStep
  82 .fi
  83 .RE
  84 .PP
  85 The output contains dependencies string(s), starting with the type and
  86 continuing with the item of interest, which depends on the type. The
  87 dependency could be result of multiple reasons. For example the type
  88 was referenced from a method, or the type was listed in the linker xml
  89 file to be protected.
  90 .PP
  91 In our example there is only one dependency string called Dependency
  92 #1. It shows us that the type Android.App.Activity was marked during
  93 processing of type XA.App.MainActivity by the linker. In this case
  94 because the MainActivity type is based on the Activity type and thus
  95 the linker marked it and kept it in the linked assembly. We can also
  96 see that there are 2 dependencies for the MainActivity class. Note
  97 that in the string (above) we see only 1st dependency of the 2, the
  98 dependency on the assembly XA.App. And finally the assembly vertex
  99 depends on the ResolveFromAssemblyStep vertex. So we see that the
 100 assembly was processed in the ResolveFromAssembly linker step.
 101 .PP
 102 Now we might want to see the MainActivity dependencies. That could be done by the following analyzer run:
 103 .PP
 104 .nf
 105 .RS
 106 illinkanalyzer -r TypeDef:XA.App.MainActivity linker-dependencies.xml.gz
 107 .fi
 108 .RE
 109 .PP
 110 Output:
 111 .PP
 112 .nf
 113 .RS
 114 Loading dependency tree from: linker-dependencies.xml.gz
 115
 116 --- Raw dependencies: 'TypeDef:XA.App.MainActivity' -----------------
 117
 118 --- TypeDef:XA.App.MainActivity dependencies ------------------------
 119 Dependency #1
 120         TypeDef:XA.App.MainActivity
 121         | Assembly:XA.App, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null [3 deps]
 122         | Other:Mono.Linker.Steps.ResolveFromAssemblyStep
 123 Dependency #2
 124         TypeDef:XA.App.MainActivity
 125         | TypeDef:XA.App.MainActivity/<>c__DisplayClass1_0 [2 deps]
 126         | TypeDef:XA.App.MainActivity [2 deps]
 127         | Assembly:XA.App, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null [3 deps]
 128         | Other:Mono.Linker.Steps.ResolveFromAssemblyStep
 129 .fi
 130 .RE
 131 .SH SEE ALSO
 132 \fBmsbuild\fR(1)