We Keep Coding

how to make a c# library invisible by main call? [duplicate]

I wrote a windows application using C# .Net 2.0 and i want to do something which hide the source code, so when any one use refactor tool can't see the source code.
I used dotfuscator but it just changed the function names but not all the source code.
UPDATE:
I want to hide the source code, not because of hiding the key, but to hide how the code is working.
Thanks,

IL is by definition very expressive in terms of what remains in the body; you'll just have to either:
find a better (read: more expensive) obfuscator
keep the key source under your control (for example, via a web-service, so key logic is never at the client).

Well, the source code is yours and unless you explicitly provide it, youll perobably only be providing compiled binaries.
Now, these compiled binaries are IL code. To prevent someone "decompiling" and reverse engineering your IL code back to source code, you'll need to obfuscate the IL code. This is done with a code obfuscator. There are many in the marketplace.
You've already done this with dotfuscator, however, you say that it only changed the function names, not all the source code. It sounds like you're using the dotfuscator edition that comes with Visual Studio. This is effectively the "community edition" and only contains a subset of the functionality of the "professional edition". Please see this link for a comparison matrix of the features of the community edition and the professional edition.
If you want more obfuscation of your code (specifically to protect against people using tools such as Reflector), you'll need the professional edition of Dotfuscator, or another code obfuscator product that contains similar functionality.

As soon as people get a hand on your binaries they can reverse-engineer it. It’s easier with languages that are compiled to bytecode (C# and Java) and it’s harder with languages that are compiled to CPU-specific binaries but it’s always possible. Face it.

Try SmartAssembly
http://www.smartassembly.com/index.aspx

There are limits to the lengths obfuscation software can go to to hide the contents of methods, fundamentally changing the internals without affecting the correctness (and certainly performance) is extremely hard.
It is notable that code with many small methods tends to become far harder to understand once obfuscated, especially when techniques for sharing names between methods that would appear to collide to the eye but not to the runtime are employed.
Some obfuscators allow the generation of constructs which are not representable in any of the target languages, the set of all operations allowable in CIL for example is way more than that expressible through c# or even C++/CLI. However this often requires an explicit setting to enable (since it can cause problems). This can cause decompilers to fail, but some will just do their best and work around it (perhaps inlining the il it cannot handle).
If you distribute the pdb's with the app then even more can inferred due to the additional symbols.

Just symbol renaming is not enough of a hindrance to reverse-engineering your app. You also need control flow obfuscation, string encryption, resource protection, meta data reduction, anti-reflector defenses, etc, etc. Try Crypto Obfuscator which supports all this and more.

Create a setup project for your application and install the setup on your friends computer like a software. There are 5 steps to creating the setup project using microsoft visual studio.
Step 1: Create a Sample .Net Project. I have named this project as "TestProject" after that build your project in release mode.
Step 2: Add New Project using right click on your solution and select setup project and give the name this as "TestSetup".
Step 3: Right click on setup project and Add primary Output and select your project displayed.
Step 4: Right Click the setup project and select View-> File System -> Application Folder. Now copy what you want to be in installation folder.
Step 5: Now go to our project folder and open the release folder you can get the setup.exe file here. Double click on the "TestSetup" file and install your project to your and other computer.

how to explicitly link a cpp/cli file to a c# library .dll?

I have a c++/CLI library that is in turn calling a c# library. That is fine, it is linking implicitly and all is good with the world. But for various reasons the libraries are not getting quite the prefect treatment by our automated build process, and the libraries are not finding each other unless we move the libraries to locations that we would rather not have them in, and would rather not fold into our build process.
It is suggested to me that we/I could write a post-build event that uses XCOPY. but lets say we don't want to do that.
Another suggestion is to explicitly load the dll. Windows says that to link explicitly "Applications must make a function call to explicitly load the DLL at run time." The problem is that Microsoft's example is not enough for my small mind to understand how to proceed with this idea. Worse, the only example I could find is out of date. Perhaps I am not using the right search terms but I am having difficulty finding more about it with google.
How do we explicitly Link a c++/Cli Library to a C# .dll?
----edit
OK, How do we explicitly Link a C++/CLI code, which exports a library using __declspec(), to a C# .dll.

There is no such thing as a "C++/CLI library", only assemblies are supported. There is no explicit or implicit linking, binding always happens at runtime. Assemblies are found at runtime by the CLR, the rules it uses to locate them are described in detail in the MSDN library.
Copying all dependencies into the same directory as the EXE is the sane way to go about it while you are developing the code. Well supported by build system, the C# and C++ rules are however different. C++ projects build to the solution's Debug directory, C# projects build to the EXE project's bin\Debug directory. So yes, altering a C++ project's Output Directory setting or copying files with a post build event is usually required to get everything together.

C# (MSIL) into native X86 code?

I would first like to say my goal is to convert MSIL into native X86 code. I am fine with my assembly's still needing the .net framework installed. NGEN is not what I want as you still need the original assembly's.
I came across ilasm, and what I am wondering is this what I want, will this make pure assembly code?
I have looked at other projects like mono (which does not support some of the key features my app uses) and .net linkers but they simple just make a single EXE with the .net framework which is not what I am looking for.
So far any research has come up with...you can't do it. I am really no sure as to why as the JIT does it when it loads the MSIL assembly. I have my own reasons for wanting this, so I guess my question(s) come down to this.
Is the link I posted helpful in anyway?
Is there anything out there that can turn MSIL into x86 assembly?

There are various third-party code-protection packages available that hide the IL by encrypting it and packing it with a special bootloader that only unpacks it during runtime. This might be an option if you're concerned about disassembly of your code, though most of these third-party packages are also already cracked (somewhat unavoidable, unfortunately.) Simple obfuscation may ultimately be just as effective, assuming this is your underlying goal.
One the major challenges associated with 'pre-jitting' the IL is that you end up including fixed address references in the native code. These in turn will need to be 're-based' when the native code is loaded for execution under the CLR. This means you need more than just the logic that gets compiled; you also need all of the reference context information necessary to rebase the fixed references when the code is loaded. It's a lot more than just caching code.

As with most things, the first question should be why instead of how. I assume you have a specific goal in mind, if you want to generate native code yourself (also, why x86? Why not x64 too?). This is the job of the JIT compiler - to compile an optimized instruction set on a particular platform only when needed, and execute it later.
The best source I can recommend to try and understand how the CLR works and how JIT works is taking a look at SSCLI - an implementation of the CLR based on the ECMA-335 spec.

Have you considered not using C#? Given that the output of the C# compiler is MSIL, it would make sense to develop on a different platform if that is not what you want.
Alternatively it sounds like NGEN does the operation you are wanting, it just doesn't handle putting the entire thing into an executable. You could analyze the resultant NGEN image to determine what needs to be done to accomplish that (note that NGENed images are PE files per the documentation)
Here is a link on NGEN that contains information on where the images are stored: C:\windows\assembly\NativeImages_CLR_Bit for instance C:\windows\assembly\NativeImages_v2.0.50727_86. Note that .NET 3.0 and 3.5 are both part of 2.0.

Pulling out information from DLLs/header files

I am currently creating my own intellisense, and was slightly unsure on a point:
The VS Intellisense can look into referenced DLLs and pull out the namespaces, classes etc from it. Does it do this with reflection? What if I add a DLL made in java (if that can be done?)
for C++, does the intellisense simple scan header files you #include, and find available namespaces, classes etc from that?
I don't fully care about the exact implementation of intellisense in visual studio, but I am interested in how it obtains it's data.

Compiled .NET assemblies and Java classes contain all meta-information about classes and symbols that they define. Nothing like .h or .lib files is required to link against them. For these types of modules, significant amount information may be extracted directly from them.
I do not know if Visual Studio is using reflection to read metadata from managed assemblies, but reflection is certainly a correct mechanism to apply in this case. But also note that VS displays more information than there is contained in an assembly directly, namely, the /// doc-comments. These may come from source files in other projects in the solution, and from separate .XML files that come with assemblies.
For C and C++, the matter is different. There is little information available in a DLL alone. There are export symbols, but they do not usually signal whether a symbol is a function or just an extrn, and how many arguments and what types the function takes. C++ uses so called "mangled" names, from which some information may be gained. But most information that is available about a library is coming from header files. VS, as far as I know, parses sopurce files of projects and .h files included from code to get intellisense database. There are macros (#define's), and inline and template classes and functions that are not reflected in DLL extern symbols at all.
For both managed and unmanaged assemblies, sometimes debug information PDB files are available. Again, I am not sure, but I think VS is not using them for intellisense. This does not mean that you should not. There do contain extended information about external variables, classes, functions and methods. All in all, there is no "standard" intellisense approach, and you probably should consider using multiple sources for the symbolic source information.
Unfortunately, I do not know much about Java to give a detailed answer to that part of your question. Also, there is a popular IDE framework called Eclipse, but I have not looked under its hood. There must be some interesting parts hidden there, but do your own research.
A few useful references:
Visual Studio SDK. Even if you are not extending visual studio, you may want to read its documentation. It has a section on Intellisense. Also, look at open-source IDEs, such as Eclipse and #develop
System.Diagnostics.SymbolStore Namespace contains classes to access PDB files. In unmanaged world, use DbgHelp library, part of Windows SDK.
A utility called Depends was part of Win32 SDK, and is avalable separately now. It shows externals defined by an unmanaged DLL. This SO discussion reveals a few ways to access this information programmatically. DbgHelp contains functions to un-mangle C++ names, after you extract them from the PE export directory.

How is it that the Mono sources are mostly C#?

I just looked at the source of Mono for the first time and I thought I would find a bunch of C or C++ code, instead I found 26,192 .cs files and 7 .cpp files.
I am not totally shocked but it made me think of a quesiton I've always had in the back of my mind:
How does a project end up being written in "itself" like this?
Was an older version of mono more c/c++? Or was there initial effort to create some kind of machine coded compiler...
What's the "trick" here?

Mono's compiler is written in C#. You may want to read about compiler bootstrapping.

You should be looking for .c files, instead of .cpp files: the mono runtime is written in C, not C++.

I think it is also important to remember that mono is both a virtual machine runtime (the JIT compiler, garbage collector, etc.) as well as a collection of class libraries that run on this framework (the System.Linq namespace, the XML parsers, etc.).
The majority of the .cs files you see are part of the class libraries. These are basically C# code that run like your own C# code (with some exceptions, but basically it doesn't make sense for everyone to reinvent and re-distribute the wheel over and over, so these are the C# "base" class libraries). This is why you can download complex mono programs as such small file sizes if mono is already installed on the machine.
For mono, the JIT, runtime and garbage collector are largely written in C/C++ as you would expect. If you ever get a low level error, you will often see GNU debug tool dumps as you would in C, just with lots more useful information. The Mono framework is very good at taking any C# code and converting it to CIL code that can run anywhere, and they use whatever toolset is best suited to ensure the code does run anywhere (which in this case meant a C compiler runtime on linux).