Activity overview
Latest activity by littlerk
I can share how my team obfuscates multiple assemblies in parallel (we have nine .saproj files). We create a Microsoft.Build.Traversal ( https://github.com/microsoft/MSBuildSdks/blob/main/src/Traversal/README.md ) project named something like Obfuscatable.dirs.proj, which has ProjectReferences to all the projects that need obfuscation. The traversal project contains a target modeled on the Microsoft.Build.Traversal SDK's standard targets for building/testing entire groups of projects: <Target Name="OurObfuscationTraversalTarget"> <MSBuild Projects="@(ProjectReference)" Targets="OurObfuscationTarget" BuildInParallel="true" Properties="%(ProjectReference.SetConfiguration); %(ProjectReference.SetPlatform); %(ProjectReference.SetTargetFramework)" SkipNonexistentProjects="$(SkipNonexistentProjects)" SkipNonexistentTargets="$(SkipNonexistentTargets)" StopOnFirstFailure="$(StopOnFirstFailure)" ContinueOnError="$([MSBuild]::ValueOrDefault('$(TestContinueOnError)', '$(ContinueOnError)'))" /> </Target> Then for the individual projects, we define a "OurObfuscationTarget" target, which uses the task <SmartAssembly ProjectFile="$(AssemblyName).saproj" />, and is configured to know when an obfuscation target is up-to-date an can be skipped by MSBuild. Parallel obfuscation is then performed by calling: dotnet msbuild -t:OurObfuscationTraversalTarget Obfuscatable.dirs.proj This is generally much faster than obfuscating each project one-by-one. Hope that helps!
/ comments
I can share how my team obfuscates multiple assemblies in parallel (we have nine .saproj files).We create a Microsoft.Build.Traversal ( https://github.com/microsoft/MSBuildSdks/blob/main/src/Traver...
Peter_Laws said:
Hello, Sorry for not seeing this initially, it is a very old thread. Yes .Net 8 support has been released and we're starting work on .Net 9 straight way. There was a drop in our cadence of releases while we addressed some internal architecture, which we've now completed, thank you for bearing with us. We'll keep you in the loop as things progress. The closed beta for .Net 8 support was quite successful, so we may do the same for 9. If we did, would the thread participants be interested?
I would be interested! / comments
Peter_Laws said:
Hello,Sorry for not seeing this initially, it is a very old thread.Yes .Net 8 support has been released and we're starting work on .Net 9 straight way. There was a drop in ou...
Version 8.3 with support for net8.0 was released yesterday. However, there is not yet a corresponding version of the RedGate.SmartAssembly.Installer Nuget package for CI support. / comments
Version 8.3 with support for net8.0 was released yesterday. However, there is not yet a corresponding version of the RedGate.SmartAssembly.Installer Nuget package for CI support.
Michael_S said:
However, for several reasons, we have to migrate to .NET 8 by the end of the year. SmartAssembly not supporting .NET 8 is a blocker for us.
My team is able to get around the problem building and obfuscating our apps for net7.0, then linking them into a trivial net8.0 wrapper project that just delegates to the obfuscated net7.0 assembly's entry point, and deploying the result as a self-contained net8.0 executable. It would be nice to use net8.0 features in the inner projects, but at least this way we can still satisfy our customers' requirements for delivery on an actively supported dotnet runtime. / comments
Michael_S said:
However, for several reasons, we have to migrate to .NET 8 by the end of the year. SmartAssembly not supporting .NET 8 is a blocker for us.
My team is able to get around th...
Missing Nuget package RedGate.SmartAssembly.Installer for latest version 8.2.1.5246
Can you please publish an update to RedGate.SmartAssembly.Installer for version 8.2.1.5246? It's the easiest way to update to the latest in our CI pipelines.
I tried adding a dummy method referencing DeserializingResourceReader like you suggested, which helped reveal a little about what's happening under the hood: [image] It seems that if System.Resources.Extensions is required for dotnet to build the base project, it can't be merged for this reason, but it can still be embedded along with System.Buffers and System.Memory. That will probably be sufficient for our purposes. / comments
I tried adding a dummy method referencing DeserializingResourceReader like you suggested, which helped reveal a little about what's happening under the hood:It seems that if System.Resources.Extens...
Is it possible to embed System.Resources.Extensions?
When using the .Net Core 3 build toolchain, certain .Net Framework projects must now include the GenerateResourceUsePreserializedResources attribute as well as a dependency on System.Resources.Exte...