I just blogged about how I made Obfuscar a Global Tool, and in this post I tried to reveal the technical details behind the scene.
First, the project file can be found at GitHub, which looks pretty simple, except the
<PackAsTool> tag. So generally speaking, this project should generate a console application. By running
dotnet pack -c release -o nupkg at command prompt, a NuGet package is generated.
Second, we analyze the contents of this package,
The contents should not surprise you, as a typical .NET Core console application always contains similar files.
Third, now you have Obfuscar installed as a global tool, do you know where the binaries are?
On Windows it goes to this folder,
Strange? Where do the previous file contents go? Did .NET Core automatically merge them altogether?
Of course not. Using ILSpy to analyze the executable I can see that none of the classes were written by me,
The .exe.config file tells the truth with more details,
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 <?xml version="1.0" encoding="utf-8"?> <!-- Generated by the .NET Core Command Line. --> <configuration> <startup> <supportedRuntime version="v2.0.50727" /> <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" /> </startup> <appSettings> <!-- To use this launcher, this value must be set. It is a file path or name of the new process being launched. <add key="entryPoint" value="%entrypoint%" /> This value may also be set. It is an path to another executable used to launch the entry point. It is treated as single argument. <add key="runner" value="%runner%" /> --> <add key="entryPoint" value="C:\Users\lextm\.dotnet\toolspkgs\Obfuscar.GlobalTool\1.0.0-beta1\Obfuscar.GlobalTool\1.0.0-beta1\tools/netcoreapp2.1/any/obfuscar.dll" /> <add key="runner" value="dotnet" /> </appSettings> </configuration>
So the command line utility
obfuscar.exe is just a wrapper (clone of the default template, and it relies on the .exe.config file to know where to find the extracted file contents from the NuGet package.