Skip to Content
Nueva versión 12 disponible 🎉
ObfuscatorPaquete NuGetConfiguración del paquete

Configuración del paquete

Cómo poner el paquete Babel.Obfuscator a disposición de sus compilaciones, hacer referencia a él desde un proyecto, activar la licencia y verificar la primera compilación ofuscada.

Alojar el paquete

Los paquetes NuGet de Babel no están publicados en nuget.org. Toda compilación que haga referencia a Babel.Obfuscator debe poder restaurarlo desde una fuente que usted controle:

  • Una fuente privada, como Azure Artifacts, GitHub Packages, GitLab, MyGet o un servidor NuGet alojado por usted. Es la opción adecuada para los servidores de compilación y los equipos de trabajo. El ejemplo GitHub Actions muestra cómo publicar el paquete en GitHub Packages y cómo autenticar el paso de restauración con un token.
  • Una carpeta local registrada como origen de paquetes, que basta para el equipo de un solo desarrollador.

Ambas opciones se describen paso a paso en Instalación. Elija la que elija, mantenga la configuración de la fuente en un archivo NuGet.config junto a la solución, de modo que dotnet restore encuentre el paquete en todos los equipos, incluidos los agentes de CI:

<?xml version="1.0" encoding="utf-8"?> <configuration> <packageSources> <add key="nuget.org" value="https://api.nuget.org/v3/index.json" /> <add key="babel" value="https://nuget.pkg.github.com/YOUR_ORG/index.json" /> </packageSources> </configuration>

Añadir la referencia de paquete

Desde Visual Studio

Haga clic con el botón derecho en el proyecto en Solution Explorer (explorador de soluciones), elija Manage NuGet Packages… (administrar paquetes NuGet), seleccione el origen de paquetes que aloja los paquetes de Babel e instale Babel.Obfuscator. Visual Studio añade al archivo de proyecto un PackageReference con los metadatos correctos.

Desde la CLI de dotnet

dotnet add package Babel.Obfuscator

Editando el archivo de proyecto

Añada el elemento siguiente al archivo .csproj o .vbproj:

<ItemGroup> <PackageReference Include="Babel.Obfuscator" Version="12.0.0"> <PrivateAssets>all</PrivateAssets> <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets> </PackageReference> </ItemGroup>

Los dos elementos de metadatos son importantes:

  • PrivateAssets establecido en all marca el paquete como dependencia de desarrollo, de modo que no se propaga a los proyectos o paquetes que hacen referencia al suyo.
  • IncludeAssets incorpora los recursos build, que es donde están los archivos .props y .targets del paquete. Sin build en la lista, la tarea Babel no llega a conectarse al proyecto y no se ofusca nada.

Si escribe el PackageReference a mano, incluya siempre los metadatos anteriores. Hacer referencia al paquete sin ellos puede añadir las herramientas de Babel como referencia de su ensamblado y dejar la compilación sin ofuscar.

Varios proyectos en una solución

Para ofuscar varios proyectos sin repetir la referencia, póngala en un archivo Directory.Build.props en la raíz del repositorio. Una condición deja fuera los proyectos de pruebas y los demás proyectos que no se distribuyen:

<Project> <ItemGroup Condition="!$(MSBuildProjectName.EndsWith('.Tests'))"> <PackageReference Include="Babel.Obfuscator" Version="12.0.0"> <PrivateAssets>all</PrivateAssets> <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets> </PackageReference> </ItemGroup> </Project>

Si usa la administración central de paquetes , declare la versión una sola vez con un elemento PackageVersion en Directory.Packages.props y quite el atributo Version del PackageReference.

Activar la licencia

La tarea Babel necesita una licencia válida cada vez que se ejecuta. El paquete la busca en este orden:

  1. La propiedad BabelLicense, cuando está establecida en el proyecto.
  2. Un archivo babel.licenses en la carpeta del proyecto o en cualquier carpeta superior. Por tanto, basta con copiar el archivo de licencia junto al archivo de la solución para que sirva a todos los proyectos de la solución.

BabelLicense acepta los mismos valores que la opción --license de la línea de comandos: la ruta de un archivo de licencia, una clave de licencia o la clave de usuario de una licencia flotante:

<PropertyGroup> <!-- A license file --> <BabelLicense>$(MSBuildThisFileDirectory)build\babel.licenses</BabelLicense> <!-- or a license key held in an environment variable (a build server secret) --> <BabelLicense>$(BABEL_LICENSE)</BabelLicense> <!-- or a floating license user key --> <BabelLicense>floating:P1N1J-EH5VA-VGSFU-7EOK8</BabelLicense> </PropertyGroup>

En los servidores de compilación, mantenga la clave fuera del repositorio: guárdela como secreto, expóngala al paso de compilación como variable de entorno y haga referencia a esa variable desde BabelLicense, como hace el ejemplo GitHub Actions. Las licencias flotantes se describen en Activación del producto.

Un archivo de licencia está vinculado a una versión del producto. Cuando actualice el paquete a una versión nueva, instale el archivo de licencia recibido con esa versión. Desde la versión 11.8, una licencia proporcionada explícitamente que no es válida para la versión en ejecución detiene la compilación con un error, en lugar de pasar en silencio al modo de evaluación.

Modo de evaluación

Cuando no se encuentra ninguna licencia, Babel se ejecuta en modo de evaluación: solo se aplica el renombrado de símbolos, y el ensamblado ofuscado deja de funcionar al cabo de un período breve, como indica la advertencia W00000 en el registro de compilación. Para asegurarse de que un ensamblado así nunca salga del servidor de compilación, convierta esa advertencia en error:

<PropertyGroup> <BabelWarningsAsErrors>W00000</BabelWarningsAsErrors> </PropertyGroup>

Compilar y verificar

Compile el proyecto como de costumbre, desde Visual Studio, con dotnet build o con msbuild. El registro de Babel se escribe en la salida de la compilación con el nivel de detalle establecido por VerboseLevel (1 de forma predeterminada).

dotnet build -c Release

Salida de Babel Obfuscator en Visual Studio

Para ver exactamente cómo invoca el paquete a Babel, establezca BabelProvideCommandLineArgs en true: la línea de comandos completa se escribe en el registro y se guarda en el elemento @(BabelCommandLineArgs), lo que resulta útil para reproducir un problema de compilación con la herramienta de línea de comandos. GenerateLogFile escribe el registro completo de la ofuscación en un archivo junto al ensamblado de destino, o en la ruta establecida por BabelLogFile.

Confirme que la salida está ofuscada abriendo el ensamblado compilado con un descompilador, o leyendo las estadísticas que se muestran al final del registro de Babel. Babel procesa el ensamblado que el compilador escribe en la carpeta intermedia obj, de modo que las copias de bin y de la carpeta de publicación están todas ofuscadas. Consulte Pipeline de compilación.

Desactivar la ofuscación en una configuración

La ofuscación rara vez interesa en las compilaciones Debug. Establezca BabelEnabled en false en la configuración Debug y el paquete omitirá todos los pasos de Babel, incluidas las adaptaciones de la publicación:

<PropertyGroup Condition="'$(Configuration)' == 'Debug'"> <BabelEnabled>false</BabelEnabled> </PropertyGroup>

La misma propiedad puede cambiarse desde la línea de comandos para una compilación puntual sin ofuscar:

dotnet build -c Release -p:BabelEnabled=false

Actualizar el paquete

Cada versión de Babel incluye una versión nueva del paquete junto con un archivo de licencia nuevo. Para actualizar:

Publicar el paquete nuevo

Publique el paquete Babel.Obfuscator nuevo en su fuente.

Actualizar la versión

Actualice a la versión nueva el atributo Version del PackageReference, o la entrada PackageVersion.

Sustituir el archivo de licencia

Sustituya babel.licenses por el archivo recibido con la versión nueva.

Mantenga Babel.Obfuscator y Babel.Obfuscator.Tool en la misma versión cuando use ambos.

Last updated on