We've been decomposing our .NET application so projects which are used in multiple solutions are built and consumed as NuGet packages. Some of these projects need to be obfuscated (we use Eazfuscator) and I'm unsure what the right workflow should be.
Right now our CI process compiles the code, runs inspections, and runs automated unit tests. This is working well. If I introduce obfuscation with each build, though, I'll have to break the unit tests which rely on our use of the InternalsVisibleToAttribute. I could run the existing process and then assuming everything is good (compiles, hasn't introduced inspection errors, and the unit tests pass) do a subsequent build for a different configuration which can be obfuscated. But then I'm not testing the obfuscated code exactly.
What has worked for your shop?
Also, I haven't tried it but is having an obfuscated assembly delivered via NuGet reduce the usefulness of having the symbol server set up? What is the debugging situation like?
Note: These packages are all for internal consumption until we get to the consuming application which is provided to our customers, which is why I'm asking about debugging into the package.
UPDATE 12/12/2016
The workflow we ended up using was to have the build server:
- Compile normally
- Run unit tests and inspections
- Compile again - this time with a parameter being passed in which enables a conditional compilation symbol of
OBFUSCATE- Now the
InternalsVisibleToAttributewill be suppressed (and any tests where we're referencing internals)
- Now the
- Publish to our internal feed
This and another change to include the ObfuscateAsemblyAttribute results in assemblies which have been marked as appropriate to obfuscate when the consuming application(s) are built. That build task does the actual obfuscation.
I'm not 100% happy with this, but it means we're not using multiple build configurations.
I'm still interested in what other people are doing, though.
