We Keep Coding

Approach to obfuscate an embedded dll in a WPF application

I have a WPF application whose output is a.exe. This application is dependent on an external b.dll (whose source code I have access to).
Requirements:
The output should only be a.exe which should contain the dll. I don't want to provide my users with a separate dll (if it can be avoided)
I should be able to obfuscate the code. (I don't want anyone to be able to modify it).
Approaches tried:
I embedded b.dll inside a.exe, it worked. But I was not able to obfuscate the exe as it gave an error that it was unable to find b.dll.
I obfuscated a.exe and b.dll but it did not work. It was unable to find b.dll.
Alternate approach :
Is there any way that I can perhaps add the spruce code of b.dll to my project and have the dll be compiled to the exe itself rather than a separate dll.
Is it possible to make this alternate approach work or are there any other ways ?
If nothing works, I know that I can compile a and b separately, obfuscate a and provide b as a separate file (what I'm trying to avoid).
Apologies for the formatting issues, if any, I'm using the android app. Let me know if you need any details.

I have had great success with Eazfuscator.Net in the past.
http://www.gapotchenko.com/eazfuscator.net
To run it from the command line enter the following command:
Eazfuscator.Net.exe -n a.exe b.dll
It will combine the two files into a single exe. The main program will be able to access the dll.
You can even set up Visual Studio so that the command line above runs as a post compile event.

Assembly embedding may seem quite confusing, so here is how it's usually done:
The dependencies are obfuscated if needed.
The target assembly is obfuscated. At this point, the obfuscator is also instructed to embed certain dependencies as a part of obfuscation process.
As a result, the embedded assemblies are stored as a resource of the target assembly.
In order to load dependencies at runtime, obfuscators usually install a handler for AppDomain.AssemblyResolve event that is raised by CLR when it fails to resolve an assembly automatically.
The handler extracts and loads an embedded assembly from the resource.
That's it. A good obfuscation tool allows achieving that quite easily. I don't see why it wouldn't work in the case with WPF application. If there are problems, I would recommend contacting product support.
Another option is assembly merging. Unlike embedded, the merged assemblies become an inseparable part of the target assembly code. For this reason, the assembly merging often helps to achieve a better obfuscation coverage and application startup time comparing to embedding. Although it may look a better option, merging may sometimes break the application functionality.

Building C# App with Internal DLLs

Is there a way to keep any DLLs needed for my Visual C# program (such as SQLite) inside the actual EXE so it doesn't require the files to be present?
If not, can anyone show me how to make a wrapper for my program (independent of .NET, so maybe C++?) to copy/load required files to the working directory before starting the program itself.
What I intend to end up with is a single EXE file that can be deployed anywhere and set itself up like a transformer. All it requires is the following criteria:
SQLite is present
OpenHardwareMonitorLib is present
.NET 2.0 is installed (if not, offer install with redistributable package)

Microsoft provide a tool for merging DLLs. It's called ILMerge.
It doesn't always work, I believe certain things can cause problems. But it's definitely the easier option!

If the problem is redistribute only one file, you can create a "installer" exe, that unpack all your dependencies (from executable content).
If you don't want to leave all dlls in your production environment, you can merge all IL code in the main executable. you can use ILMerge (but it's not the only product that can do this)

You can merge the dependencies into the main executable. After your build completes you run an additional tool that combines the IL code into a single assembly.
ILMerge can do this but is a bit cumbersome to use.
Some (proprietary) tools can do this as well. I know of at least one obfuscator (DeepSea) that can do this. DeepSea also allows you to specify what you want to include and what types you want to expose from the resulting assembly.
Full disclosure: I know the guys that build DeepSea Obfuscator.

I guess you could embed the target assemblies as resources and then unpack them in some custom assembly resolution code?
Edit: there's an example of this here: Embedding assemblies inside another assembly

Strongly Named assembly validation failed, referenced from non signed project

after one hour googling, I can't find the right answer to the issue I'm experiencing, hope you can help me.
I have a C# framework 3.5 class library project, so I signed it creating a simple key (NOT delayed signin) and then I obsfuscated the DLL.
Then I'm trying to access that assembly from a Windows form application, but when I make some call to any method of the assembly I get the error: "Strong Name Validation Failed".
I don't know if I should sign the Windows application too to refer to the strongly named assembly, or add some sort of special tag at the using directives in the source code of the Windows application.
I'm new working with strong names, so please give me some advice in how to deal with this. I need to strongly name the assembly in order to guarantee that no intruder could replace my version of the assembly.
Thanks in advance.

sorry for taking away your time, I found the reason for my issue and the solution for it:
First of all, when I obsfuscated the assembly, the generated SNK didn't worked anymore, so the solution is to re-generate the SNK after obsfuscating the assembly.
Second, I needed to include the SNK file on my Windows Application in order to validate the strongly named assembly.
With both changes, everything worked fine for me.
Thanks anyway for your time.

AssemblyInfo.cs , .net applications versions

I would like to keep version in my .net applications and let the .net to manage it. I don't really understand how it works. Is the version number per project ? How .net manages versions? If anyone could please explain it briefly i will be grateful.

What I usually do is to keep a SolutionInfo.cs that contains all the attributes that are common for the projects of my solution, for example the version-number. I keep this file in the solution root.
I then link that file into the project (right click the project and Add->Exsiting item... -> Add as link (the little arrow on the add button)).
I then can increment the version number in a single place and it will be updated in all the projects that links that file.
For more information on that for example see: http://jebsoft.blogspot.com/2006/04/consistent-version-numbers-across-all.html

The version number is per-project (.csproj file), so per built .dll or .exe file. The version number is embedded in the .dll or .exe, and can be viewed using (for example) Windows Explorer by right-clicking on the file and selecting Properties.
MSDN contains an explanatory article about how to use AssemblyVersion and AssemblyFileVersion at http://support.microsoft.com/kb/556041

[AssemblyVersion] is a very big deal in .NET. Every type in your program is imprinted with the assembly version, it is part of the type identity. In other words, when the version of your type changes then you should also change the assembly version. This forces all other assemblies that use your type to be recompiled.
One thing you can do is to let the build system automatically increment the version. You can't call this 'managing the version' by any stretch of imagination. Because now just rebuilding your assembly, even without making any change in the source code, will make your assembly incompatible with other code that uses the types in that assembly.
Clearly this can only work well if you recompile all the code in your solution.
Well, that's not great unless you like sword fighting. Furthermore, sometimes you want to make a simple bug-fix in your code. The result is an assembly that's still 100% compatible with the original version. And you don't need nor want to recompile everything else that uses it. You just want to send that one assembly to your customer. Clearly that can only work well if you don't let the version increment automatically.
So what you really need is some kind of tool that can magically determine that your source code, the publicly visible part of it, is no longer compatible with a previous version. Or the changes you made to the non-visible part of it are changing the behavior of the code too much to disallow other code that use your types to continue to use it without some changes in their code.
There's only one tool that I know of that can do this, the one we have between our ears.

How does the CLR know which if the given assembly is the correct one?

If we have a .NET executable that's using a .NET library, how does the CLR ensure you are using the correct version of the dll? CLRwise what is considered be the "correct dll version", to start with?
Does it only look at the version? Looks also at the build-time(?). Maybe it looks at an hash or something?
Thanks

You may start to learn about .NET versioning,
http://msdn.microsoft.com/en-us/library/51ket42z(VS.71).aspx

It takes the one used during compile, identified by fully qualified name - which includes not only the assembly name, but also the complete version information AND the digital signature fingerprint if one was available.

The other answers already cover the essence of it.
Basically, the Framework checks for assembly name, version, and signature of an assembly to find a match.
The name and version (and more stuff!) you can set from code (AssemblyVersion attributes), and you can easily sign it with the help of VS, too.
The signature involves creating a .pfx file (VS will generate one for you), and checking the "sign assembly" in the build settings. This will ensure that more than one assemblies can coexist with the same name and version.
(So if two companies accidentally created two things with the same name, you can still use them together.)