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.

Debugging in VS without the source code

I need to debug some assemblies due to they throw exceptions. It's my assemblies but I don't have the source code of them. What I have is their pdb files.
Is there any way to debug that assemblies by Visual Studio?
--EDIT--
Of course, I also can disassembly them to get *.il files of them. Would it help me somehow?

Actually there are a few ways to accomplish this:
Use dnSpy - a free opensource .net debugger and assembly editor https://github.com/0xd4d/dnSpy
Setup symbol server with dotPeek (also free) https://www.jetbrains.com/help/decompiler/Using_product_as_a_Symbol_Server.html
Use Resharper decompiler to load symbols for external modules in your visual studio. I think this is the easiest way. I've described the whole process on my blog https://cezarypiatek.github.io/post/debug-without-sources-part-one/

This is exactly why I paid for Reflector. Need to debug someone else's assembly? It works perfectly.

As far as I know, the PDB files are just pointers for debugging. That is, if you don't have the source code then the PDB files will only give you the stacktrace.
I don't know if Visual Studio can handle it, you might need to hook up manually to the process.

Not exactly in visual studio, but I wrote in the past such a tool inside reflector, calle d Deblector. Is no longer mantained by me but have a look. Of course the debugging experience is not the same you can have in Visual Studio, but is sometimes enought to get you out of troubles.

Check out dotPeek:
https://www.jetbrains.com/decompiler/
You can set this up as a symbol server inside visual studio to generate PDB files which allow you to debug. It is very easy to use and just as good as many of the paid products.
You can add libraries directly from nuget, or point to the DLL.

I want to make my own c# debugger - how would one do that? What tools should I be using?

I'm interested in making a program that will take c# code and allow me to step through the execution of that code line by line - a debugger.
How would I go about this project without having to write a whole c# compiler? I'm using Microsoft Visual Studio, but I want my software to be as independent of their debugger implementation as possible.

You're looking for ICorDebug, the managed debugging API.
You can use csc.exe to compile the code (this is included in a standard .Net Framework installation and wrapped by the CSharpCodeProvider class), then execute the assembly, attach the debugger, and step through the code.
Note that you would probably still need a C# parser to figure out where you are in the source.
The PDB file will contain some of this information; I'm not sure how much.
Note that most of the features in VS's debugger which we take for granted (especially the Watch window and variable tooltips) will require painful re-implementation. (Func-evals)

Are there any emacs or vim editors with code completion plugins for C#?

It would be nice if it did both a list of methods to choose from and the list of potential input parameters. This was done for powershell and I was curious if there was any similar functionality implemented for emacs or vim?
Clarification:
A fellow developer I work with wants to use either vim or emacs for the low overhead without running visual studio. In essence he would like to be able to write tests, edit code in emacs or vim then just run NANT scripts to compile the code and run the tests. The only feature from Visual Studio he wants is code completion. The rest he can live without for 98-99 percent of the time.

You can use a vim editor emulator for Visual Studio.
http://www.viemu.com/

I haven't come across an emacs mode that would offer code completion suggestions based on "knowledge" of the API(s) that the user's environment is offering. To a lot of people this is an issue which prevents them from attempting to use Emacs or VIM when working with rich/large/unwieldy (delete as applicable) APIs.
However I am wondering how much of a problem this would present during day-to-day work. I've been using Emacs with C#-mode to crank out quite a lot of C# code. I also tend to run dabbrev-mode or pabbrev-mode, which tends to take care of the more common function and variable names I tend to use. To my eternal shame I have to admit that I tend to have a browser open on the MSDN website to look up the rest - those APIs that I don't use often enough to remember. Another potential helper that your colleague might want to look into is icicles, which may also be a step in the right direction. Neither of these libraries however will offer the full breadth of completion support that something the like Visual Studio IDE will offer. I'd see this as part of the trade-off when using a more efficient editor.
As an aside, if your colleague is working in a team and other members working on the same project are using Visual Studio, MSBuild might offer a better solution for building outside of VS than Nant as MSBuild reads the same solution and project files that VS uses (in fact a lot of the build work in VS2008 is handled by MSBuild). The syntax isn't too far away from Nant and with the community tasks added (which gives you NUnit integration etc) and it'll ensure that everybody is using very similar mechanisms to build the executables.

The furthest along completion I've seen for C# is at this blog, specifically at this post. (Blog link included for context and other Emacs posts.)
If you can live with dumb completion, you might be able to roll your own with tags and tag completion.
A previous stack on the same issue.

Your source code should be processed through the CEDET framework: http://cedet.sourceforge.net/
Then either use the example UIs bundled with cedet or else try any of these two:
- company-mode: http://nschum.de/src/emacs/company-mode
- completion-ui: http://www.dr-qubit.org/emacs.php
both supporting CEDET as a completion search backend.
apa!

for emacs and C# you can look at this tool : http://code.google.com/p/idebridge/

OmniSharp provides contextual intellisense for C# in vim.

Some of the suggestions in Eclipse Style Function Completions in Emacs for C, C++ and JAVA? may be relevant for emacs.
Not c# specific, but still.

I have found the http://code.google.com/p/csense this is an emacs c# intellisense/code sense. I found it from this blog post http://osdir.com/ml/emacs.sources/2007-11/msg00018.html, this may be close to the answer I was looking for.
After looking further it has not been updated since November 2007, looks stale to me.

For Vim, you can install insenvim. It support for the C# code completion.
After download the plugin you could install the installation file or install manually by following steps:
Copy the file cs_vis.vim into your $VIM\vimfiles\ftplugin directory.
Copy the file csft.dll into your $VIM_INTELLISENSE directory.
Copy CSVimHelper.dll,reg.bat to your $VIM_INTELLISENSE directory.
Run reg.bat to register the dlls. You need to set the directory gacutil.exe
in the path. You need the latest version of .NET SDK.

Debugging a third-party DLL in Visual Studio?

I am using a third-party DLL. For some particular cases, a function in the DLL is throwing an exception. Is it possible to debug the DLL in the Visual Studio?
After the answer from Andrew Rollings, I am able to view the code, but is there any easy way to debug through the code in Visual Studio?

If the DLL is in a .NET language, you can decompile it using a tool like .NET Reflector and then debug against the source code.
Or you could ask the vendor if source code is available. That's probably the easiest way.

Building on Andrew's answer, you just treat the decompiled source code as a new library within your project and set breakpoints in the source. Remove all references to the 3rd party DLL so that it is the decompiled code that is executing.
Other things:
You may be breaking the law by decompiling the code, or breaching a licensing agreement with the 3rd party vendor. Make sure to review this with someone.
You will want to make sure that you remove references to your decompiled version if you are shipping to other developers, or checking into a larger source tree. Easy to forget this!

There are two methods I've come across:
1) Accessing the DLL project from the using project.
This involves building the DLL in a separate instance of Visual Studio and then accessing the DLL through a different project in Visual Studio (this assumes you have the source code).
There a number of ways to accomplish this:
You can add Trace.WriteLine
statements in the DLL that will show
up in the 'Output' window in Visual Studio.
You can add System.Diagnostics.Debugger.Break() statements to the DLL code. When
running the calling project in Visual Studio,
program execution will stop there.
From here you can add access the
call stack (including all function
calls in DLL itself) and set break
points (although the icon for
the breakpoint will appear disabled
and the hover text for the break
point will read "The breakpoint will
not currently be hit. No symbols
have been loaded for this document").
If the DLL is throwing an exception (which you can see from
the 'Output' window if the exception
is caught and handled by the DLL)
you can tell Visual Studio to always break when
that type of exception is thrown.
Hit Ctrl + Alt + E, find the type of
exception being thrown, and click
the 'Throw' column for that
exception. From here it is exactly
as if you had used
System.Diagnostics.Debugger.Break()
(see above).
2) Attaching a using process to the DLL project.
This involved hooking the Visual Studio debugger into a running process.
Open the DLL project in Visual Studio.
Run an application that uses the DLL (this
application can't be run from
another instance of Visual Studio since the
process will already have a debugger
attached to it).
From here you can add break points and step through
the DLL code loaded in Visual Studio (although
the break point will appear disabled
the same as in method 1).

Something that has worked for me with debugging a couple of third-party libraries as well as .NET itself is WinDbg. It is an awesome debugger from Microsoft that I have used to troubleshoot some sticky problems that were occuring deep inside the framework.
You need to use the Son of Strike (SOS) extensions if it is a managed DLL. It can debug native also. You will need to know a bit about callstacks and assembly/CIL instructions to be good at using it. You should be able to determine the exception and what is causing it. We have used WinDbg/SOS to find for instance that in HttpWebResponse, if you are using Gzip compression to download a page and the server returns a bad Gzip header, .NET runs the decompression in the threadpool and a crash will take out your process. Happy debugging.

One more option we should mention here is dotPeek 1.2 (a free decompiler from creators of ReSharper). Here is a nice post describing how to configure VS symbol server and dotPeek 1.2 to debug decompiled code from VisualStudio: http://blog.jetbrains.com/dotnet/2014/04/09/introducing-dotpeek-1-2-early-access-program

As Cesar Reyes mentioned in Stack Overflow question Visual Studio - Attach source code to reference, ReSharper 5 (and later) has this capability.

.NET Reflector 6 comes with a Visual Studio Addin that lets you use Visual Studio's step-through-debugging on assemblies that you don't have the source code for.
Have a look at this blog post:
http://www.simple-talk.com/community/blogs/alex/archive/2009/09/22/74919.aspx for more details.
This is still a very early build. So no guarantee that it'll work, and it might break your visual studio configuration or project configuration. Make sure you have backups (or source control) for any projects you use this on.
Download here:
http://www.red-gate.com/MessageBoard/viewforum.php?f=109

I thought .NET Reflector got some debugging plugins. That'd be a so much better idea because decompiling and recompiling code generally fails, and you need to do so many changes in the code to fix it.
Give .NET Reflector debugger a try. It might help you a lot.