Develop Reference

An alternative for .NET Script Editor

I am developing an API for some application. And I need to attach there a script engine to make it possible to invoke API from script.
It would be quite nice to have autocomplete, syntax highlight and debug in scripts.
I have found this solution: http://www.codeproject.com/Articles/27744/Net-Script-Editor-C-Vb-net-Mini-IDE
But there are a lot of bugs.
Does anybody have any ideas of alternative solution?

LinqPad has many of the features you are looking for - some of them cost a small extra fee, but it's probably worth the fee!
http://www.linqpad.net/

Snippet Compiler is a nice tool.

You don't mention which language your scripts are in, but based on your other question about debuggers I'll assume you are using IronPython.
The most complete (free/open source) option that I've been able to find is SharpDevelop. It includes all of the features you've mentioned for IronPython as well as a debugger. It is open source and includes many useful extensibility points, so it should provide a good starting point to fix bugs and add additional language support if needed (provided your use conforms to its license terms).
If your situation requires use beyond what is provided by the LGPL then the best choice (though not standalone or free) is to extend Visual Studio (there's already an extension for IronPython though I'm unsure if it supports debugging).
It doesn't sound like you're looking to do much, if any, development of your own for this but if I'm misreading your question then there are some editor controls available that provide the features listed (and then some) for .NET (not exhaustive):
Scintilla.Net
AvalonEdit (used by SharpDevelop)
An example of a project that uses Scintilla.Net is Peter.

You can try with SharpDevelop .

Parse/Refactor C# via C# code

Is there any libraries from Microsoft or from Mono project that allow you to do sweeping changes on a C# code base via code? Anything in Cecil for this? I think Cecil would only allow you to work at the bytecode level - anything to work on the language level?
I have already identified the issues I'd like to correct. Just could use some help with the Search/Replace in a C# syntax-aware fashion.

You should look at Roslyn - it's only in the preview stage at the moment, but it sounds like just what you want. (There are various blog posts about it, including this introductory one.)

There's a reasonably powerful search and replace in Resharper if that's appropriate to your situation.
http://blogs.jetbrains.com/dotnet/2010/04/introducing-resharper-50-structural-search-and-replace/

Is the source code visible through the binary file ? (C#)

I have written a program in c# with Vistual studio 2008.
I've compiled and build it and got a .EXE file. My question is this - if I give someone else this .EXE file can he in any way see the source code? functions, variables, calls, stack states, anything? I wish to keep those as discreet as possible.

They can use a tool like Reflector to decompile the executable, this will not be identical to your code, but they will be able to see most of what you wrote. It is a free tool, so you can download it to see what it can do with your exe.
You will need to obfuscate your code if you want to keep others from seeing it easily (though even that can be overcome with enough time and determination). A tool you can use for this is dotfuscator.

According to this SO post, one can reverse engineer a given executable and obtain the code that was used to build it. This msdn blog shows some ways you can make the process of reverse engineering a bit tougher, mainly through the use of obfuscation.

The exact same source code as you have written it no. But he could use tools like Reflector to disassemble it. In order to make the disassembled code difficult to read you could obfuscate it.

Yes.
You can use reflector to decompile any .net assembly.
http://www.red-gate.com/products/dotnet-development/reflector/
There are tools that will obfuscate your code. But it will still be visible. Security by obscurity does not work anyway.

As all have said - it's easy to decompile an assembly. Obfuscation offers very little real protection unless you're using some of the really high end commercial tools. The key things to really watch out for is if you have things like encryption keys or security tokens/credentials in your source code these are pretty easy to find.
There are a range of products available that will allow you to compile a .net app to native code which offers much greater protection.

Building An App With Plug-in Support

I'm starting a new project which would greatly benefit from program add-ons. The program in its most basic form reads data from a serial port and parses it into database records. Examples of add-ons that could be written would be an auto-archive add-on, an add-on to filter records, etc. I'm writing both the program and the add-ons, but some customers need custom solutions, so instead of branching off and making a completely separate program, add-ons would be great. The simplest add-on would probably be a form who's constructor takes an object reference, manipulates the object in some way, then closes.
Unfortunately, I have absolutely no idea where to start coding, and almost as little idea where to search. Everything I search for turns up browser add-ons. From what I have gathered, I need to look into dynamic loading DLLs. Besides that, I'm clueless. Does anyone have any good resources or examples I that they know of?
I'm happy to provide more details, but this project is in its inception, so I don't have a ton of specific details (specifics kind of defeats the point of add-ons, too.)

You should seriously consider using the Managed Extensibility Framework (MEF) to handle your plugin architecture. It requires thinking about things a little differently, but it is well worth the mind-stretch.

This is a simple example to illustrate the basic technique.
codeproject.com - Plugin Architecture using C#
This article demonstrates to you how
to incorporate ... as a
plugin for another application or use
it as a standalone application.
in .NET 4 you now have the Managed Extensibility Framework (MEF) to do much of the plumbing.
In .NET 3.5 you had the System.AddIn but it was deemed by many to be far too complex.
codeproject.com - AddIn Enabled Applications with System.AddIn
AddIns (sometimes called Plugins) are
seperately compiled components that an
application can locate, load and make
use of at runtime (dynamically). An
application that has been designed to
use AddIns can be enhanced (by
developing more AddIns) without the
need for the orginal application to be
modified or recompiled and tested

You really need to look at Managed Extensibility Framework (MEF). This is specifically designed to help support add-ons and other extensibility.

A very basic description (basically, your plugins must implement a special interface):
http://martinfowler.com/eaaCatalog/plugin.html
Much better article, in C#:
http://www.drdobbs.com/184403942;jsessionid=TVLM2PGYFZZB1QE1GHPCKHWATMY32JVN

I think Reflection will play a major role.
I expirimented with an app that had a plugin folder. A filesystem watcher would watch the folder, and when a new DLL was placed in it, it would use reflection to determine which types of plugins it included, loaded them, and added them to the list of available classes, etc.

Try using the term 'add-in' or 'plug-in' for your research instead of 'add-on'. That should help some.
If you're using .Net 4, there's an add-in namespace in the framework that will get you partway there.
Writing plug-in support for an app is no simple task. You'll have to maintain pretty strict separation-of-concerns across your interfaces, you'll need to provide an interop library that defines ALL of the supported plug-in types, and you'll want to do some research into dependency injection & inversion of control, in addition to the previously-suggested reflection research.
It sounds like you might have a busy weekend doing research.

How can I create my custom Shell Context Handlers for Windows?

Problem
Language: C# 2.0 or later
I would like to register context handlers to create menues when the user right clicks certain files (in my case *.eic). What is the procedure to register, unregister (clean up) and handle events (clicks) from these menues?
I have a clue it's something to do with the windows registry, but considering how much stuff there is in .net, I wouldn't be surprised if there are handy methods to do this clean and easy.
Code snippets, website references, comments are all good. Please toss them at me.
Update
Obviously there is a slight problem creating context menues in managed languages, as several users have commented. Is there any other preferred way of achieving the same behaviour, or should I spend time looking into these workarounds? I don't mind doing that at all, I'm glad people have put effort into making this possible - but I still want to know if there is a "proper/clean" way of achieving this.

Resist writing Shell Extensions in managed languages - there are a multitude of things that could go bang if you pursue this route.
Have a browse through this thread for more details. It contains links to do it if really want, and sagely advice of why it can be done, but shouldn't.
http://social.msdn.microsoft.com/Forums/en-US/netfxbcl/thread/1428326d-7950-42b4-ad94-8e962124043e/
You're back to unmanaged C/C++ as your only real tools here.

This is not a good idea because of potential dependency issues between different versions of the .NET Framework. Your shell extension could be expecting one version, while a different version may have already been loaded by the application that's currently running.
This thread contains a good summary of the situation.

While others already mentioned that writing shell extensions in pure .NET is a bad idea due to framework conflicts, you should still note that:
There are 3rd party drivers out there (see Eldos or LogicNP) that do the unmanaged side for you, allowing you to write managed code that talks to the native driver, thus preventing shell-related CLR version conflicts.
A recent MSDN article mentioned that Microsoft has solved this problem for the CoreCLR, as used by Silverlight. They've accomplished this by allowing multiple versions of the CLR to run in the same process, thus fixing the problem. The author further stated that this fix in Silverlight will be rolled into future versions of the full CLR. (Meaning, in the future, it will be quite feasible to write shell extensions in managed code.)

I've done them before in C#. It ends up being a hell of a lot harder than it should be. Once you get the boilerplate code down, though, it is easy to roll out new items. I followed this link:
Link To Info

As the prior comments mention, it isn't the best idea to write shell extensions in managed languages, but I thought I'd share an Open Source project that is doing just that :)
ShellGlue is a managed shell extension that is actually quite helpful. The source also might be helpful to you if you're interested in pursuing writing a shell extension in C/C++.

Aside from the caveats that have been mentioned concerning the implementation of shell extensions in managed code, what you'd basically need to do is the following:
First, create a COM component in C# that implements the IShellExtInit IContextMenu interfaces. How to create COM components in C# is described here. How to implement the necessary interfaces is described in this article. While the description is for a C++ implementation, you can apply that knowledge to you C# version.
Your COM component will have GUID called the Class-ID or CLSID. You need to register that ID with your file type as a context-menu shell extension:
HKEY_CLASSES_ROOT\.eic\ShellEx\ContextMenuHandlers\MyShellExt
(Default) -> {YOUR-COMPONENTS-CLSID}
Also make sure that you registered your component correctly as described in the C# COM tutorial. You should find it in the registry under
HKEY_CLASSES_ROOT\CLSID\{YOUR-COMPONENTS-CLSID}
InprocServer32
(Default) -> C:\WINDOWS\system32\mscoree.dll
Class -> YourImplClass
assembly -> YourAssembly, version=..., Culture=neutral, PublicKey=...
...
Good luck...

As others have pointed out, shell extensions are not practical in windows development currently.
I asked a similar question recently which was answered with a link to a guide to do exactly what I wanted to do