Our requirement is being able to integrate our DLLs with ClickOnce. Dotfuscator does the obfuscation job nicely but the obfuscated DLLs cannot be deployed with ClickOnce on customer side. On our side, we can handle it perfectly. Moreover, the obfuscated assemblies sometime crash our .NET CF app. It turns out to a solution that creates a temporary source and obfuscates it before compiling with VS. This ensures that the compiled assembly can be integrated with ClickOnce and fully compatible with .NET CF. What is the best tool to obfuscate C# SOURCE CODE (not assemblies)?
-
In fact, we are developing an in-house C# Source Code Obfuscator in VC++. It allows us to exclude classes and enums with Attributes. The great outcome is the obfuscated source code can be compiled normally with VS, thus the DLLs are highly compatible with ClickOnce. – Mark Attwood May 30 '10 at 21:19
4 Answers
{SmartAssembly} - Simple, efficient, brilliant and comes with more than just obfuscation.
We currently use it with ClickOnce and it supports the Compact Framework - You just add a post build script and you're done. It also has various levels of security, so you can simply go by trial and error to the most compatible level of protection.

- 25,001
- 7
- 80
- 118
-
+1 while I don't use it, they are using and happy with it where I'm working – kenny May 30 '10 at 10:45
-
I think I need to explain the situation clearly. Our complied DLLs need to be obfuscated and shipped to our customers. On customer side, they may want to integrate our DLLs with their product and deploy it with the ClickOnce tool. The problem is the obfuscated DLLs with all obfuscator tools we have tried on the market are not compatible with CLickOnce. Your solution is for your side, not customer side. – Mark Attwood May 30 '10 at 21:37
-
-
-
1@Mark - There's no difference then. You can exclude certain signatures for obfuscation so that people can use your library, and then the ClickOnce just deploys the already obfuscated library. – Kyle Rosendo May 31 '10 at 05:55
See my company's SD C# Obfuscator.

- 93,541
- 22
- 172
- 341
-
-
-
They actually obfuscate even the System.Collection namespace which is not what we want. – Mark Attwood May 30 '10 at 21:38
-
The SD obfuscator will obfuscate only the names you ask it to. If you want to leave the System Collection namespace member names unobfuscated, that's easy enough to do. – Ira Baxter May 31 '10 at 00:14
-
@BenVoigt: Thanks for noticing this. I've patched it according to SO policy rules. You'll note this is an extremely early answer, before the policy was established. I've tried to go back and modify all my old answers, some I missed. Thanks for your (yes, I remember) positive support. I'll delete this after you've deleted your note. – Ira Baxter Mar 08 '16 at 21:51
In most cases, if you're asking this question, you're using the wrong language (and framework). Many of the things that make .NET powerful are incompatible with obfuscation, so you might as well be using native C++.
ClickOnce might be an exception to this, but I think it still will severely limit the obfuscation level you can use.
If you really want to protect your IP, you should host a web service so your proprietary code never leaves your computer. Once your code is running on someone else's CPU, you've lost the battle to hide it.

- 277,958
- 43
- 419
- 720
You don't need to obfuscate the source code, you just need an assembly obfuscator which supports ClickOnce. Crypto Obfuscator supports this - it performs the obfuscation as part of the build process, so the assemblies that end up being in the ClickOnce manifest and setups are already obfuscated.

- 5,796
- 1
- 28
- 32