Correct Usage for ASP.NET Core 2.0

[aldycool]

Hi, I'm using Obfuscar version 2.2.11. I followed the standard instruction on how using Obfuscar. I installed the nuget package for my project in Visual Studio 2017, and edit the post-build event like this:

$(Obfuscar) obfuscar.xml

Create the obfuscar.xml file in the root project, set it to Copy to Output if newer, with the content like this:

<?xml version='1.0'?> <Obfuscator> <Var name="InPath" value=".\bin\Debug\netcoreapp2.0" /> <Var name="OutPath" value=".\bin\Debug\netcoreapp2.0\Obfuscar_Output" /> <Module file="$(InPath)\MyWebApp.dll" /> </Obfuscator>

And it generate error during the build process, like this:

Unable to resolve dependency: Microsoft.AspNetCore.Mvc.Core

I've managed to resolve this error by adding this line into the obfuscar.xml:

<AssemblySearchPath path="C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.aspnetcore.mvc.core\2.0.2\lib\netstandard2.0" />

And then, I get the next error like this:

Unable to resolve dependency: Microsoft.AspNetCore.Mvc.Razor

I can add the same AssemblySearchPath for that particular error, like this:

<AssemblySearchPath path="C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.aspnetcore.mvc.razor\2.0.2\lib\netstandard2.0" />

But, it seems this will be an endless solution (since I have to specify each search path one-by-one). Am I doing something wrong? or these kind of errors can be solved easily? Thanks.

[aldycool]

Hi,

I've managed to solve this issue by adding these lines in my .csproj file:

<PropertyGroup> <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies> </PropertyGroup>

The CopyLocalLockFileAssemblies will copy all of the DLLs from the NuGet dependencies into the output folder (in the same folder as the project's main assembly). Therefore, the AssemblySearchPath tag is not needed anymore in the obfuscar.xml, because all of the required DLLs are already there (and the Obfuscar is successully executed).

For now, I will use this method to continue using the Obfuscar for ASP.NET Core 2.0. Please let me know if there are more fine approaches for this issue. Thanks.

[lextm]

An alternative approach, is to use dotnet publish to generate the final deployment package (all assemblies should be there in the folder), and then manually call Obfuscar to obfuscate the parts you want. I did not test it myself, but I assume it should be better than hacking your project file or using extra assembly search paths.

[sadomovalex]

some information which may also help:

1

But, it seems this will be an endless solution

yes, if you try to add each assembly one by one (by using C:\Program Files\dotnet\sdk\NuGetFallbackFolder subfolders) it will be very big list. However you may also add single search path which points to C:\Program Files\dotnet\packs\Microsoft.AspNetCore.App.Ref\xxx subfolder:

<AssemblySearchPath path="C:\Program Files\dotnet\packs\Microsoft.AspNetCore.App.Ref\6.0.25\ref\net6.0" />

(here instead of 6.0.25 use .NET version used in your project - you may see details here)

2

I've managed to solve this issue by adding these lines in my .csproj file:

<PropertyGroup> <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies> </PropertyGroup>

because of some reason it didn't work for me (VS2022/.NET6/ASP.Net Core MVC web app). Even with this property in csproj file e.g. Microsoft.AspNetCore.Mvc.Razor.dll assembly was not copied to output dir.

3

An alternative approach, is to use dotnet publish to generate the final deployment package (all assemblies should be there in the folder)

on practice there are few problems with this solution. E.g. when you build ASP.Net Core web app in VS it doesn't use "dotnet publish ... --self-contained" i.e. by default not all dlls are copied to output dir (note that I'm talking here about VS, not about VSCode). So when you develop solution in VS (when you need to rebuild it quite often) you won't be able to test will it work or not in runtime. When development is finished we use "dotnet publish ... --self-contained" and then may obfuscate it with mentioned approach (yes, there won't be assemblies resolve problems, because all assemblies are in place, but since we didn't test it during development there may be runtime errors. It is quite risky to not test obfuscated web app before to use it in prod).
Second - additional tweaks are needed which are specific to ASP.Net Core web apps. I summarized found issues here. Shortly you also need to skip obfuscation of anymous types, classes from AspNetCoreGeneratedDocument namespace and middlewares (maybe there is something else which I'm not aware of yet):

  <Module file="$(InPath)\MyWebApp.dll">
    <SkipType name="*AnonymousType*" skipProperties="true" skipMethods="true" skipFields="true" skipEvents="true" skipStringHiding="true" />
    <SkipNamespace name="AspNetCoreGeneratedDocument" />
    <SkipNamespace name="MyWebApp.Middleware" />
  </Module>