We Keep Coding

How to know when a method in a class is being executed

I'm trying to write a log to monitor the execution time of a method for our application. Is it possible to know when a method in a class is being executed without using Aspect-oriented programming.
I don't want to go into every method to write a log there so I hope someone faced this issue and can give me some suggestion.
Updated: I'm writing a SharePoint application using .Net 3.5

AFAIK, without AOP or directly logging code injections the only way is a profiling API.
I wouldn't choose that way for one-time task, it isn't easy.

Try using breakpoints. Press F10 on the space at the left side of the method, and from there, the debugging starts, where you'd be able to see value and property change after its execution.

Addtional to #Dennis answer, I think System.Diagnostic.Debug is a choice to know when your method is executed beside Aspect-oriented programing. However, you need to turn on Debug build flag, or supplying argument in csc.exe
/define:DEBUG

in sp 2010 you can turn on developer dashboard (on dev stage only for safety)
this will give you abreakdown of calls and times
http://msdn.microsoft.com/en-us/library/gg512103(v=office.14).aspx

C# FTP library vs FTP command line application

I have an option to use either the C# FTP library or the standard FTP command line application to connect and to retrieve data from an FTP server.
Can some one advice on what to prefer.?
Thanks.

Why would you be using a commandline tool, intended for end users, from code? You'll be having a hard time reading and parsing stdout and stderr to get the responses or errors that result from your commands.
Just use the FtpWebRequest and FtpWebResponse since they provide in a decent, easy-to-use interface that contains error checking and so on.

Try to stay in a language's idiom where possible, so use a library when you can. Errors will be handled using C#'s Exceptions rather than checking some obscure command-line errorlevel value.

Using a Library, you have access to the classes, events, exception handling and so on, which integrate much better with your code. I would say that's more maintainable than having to interpret the text output and return codes of a commmand line application. So my suggestion is to use the library.

CSharpCodeProvider - Is it abusable?

Apologies for the shortness of the question, however I don't think it needs much elaboration.
Any there any security implications caused by using the CSharpCodeProvider and could it open a server up for attack?

It depends on how you use it. Here is a summary sorted from the safe use to a use that you certainly don't want to allow (when running the code on a server or some environment that you want to control):
If you use CSharpCodeProvider just for generating C# source code, then you only need a permission to save the generated files to some directory or to noting at all (if it is possible to get the code generated into a memory stream)
If you use it for compiling generated C# source, then you need a permission to run csc.exe (which may not be available in some limited environments such as shared hostings).
If you just generate files & compile them, then it probably won't be harmful (although someone could probably abuse your application to generate many, many files and attack the server using some kind of DOS attack.
If you also load & execute the generated code, then it depends on how you generate it. If you assume that there are no bugs in C#/CodeDOM and can guarantee that the generated code is safe, then you should be fine.
If your code contain things such as CodeSnippetExpression that can be provided by the user (in some way) than the user can write and run anything he or she wants on your server, so this would be potentially quite dangerous.

Sort of. On the surface it's not a direct risk, because you're not running code, just compiling it. However, there's nothing that says that the C# compiler doesn't contain some sort of bug that, given the right malicious input, would cause it to bail out and start executing commands directly.
However, if you later execute the compiled code (and presumably you do -- otherwise why would you compile it to begin with?), it will be running the same context as you are. Obviously, that has all kinds of unpleasant security implications, much like using the quasi-analogous eval() feature of other languages.

It depends on the source that you are compiling. If you have enough control over the source, then it might be an acceptable risk. If you are allowing someone outside of your sphere of trust supply code to the compiler, it might be an unacceptable risk.

Is it possible to call C# lexical/syntactic analyzers without compilation?

Considering this question of SO, where whole C# in-memory compiler is being called. When only lexical and syntactic analyzing is required: parse text as a stream of lexemes, check them and exit.
Is it possible in current version of System.CodeDom.Compiler, if not - will it be?

If you can use Mono, I believe it has a C# parser/lexer you may be able to use.
Here's a link to look into. As for what the MS C# team is planning to do, there is some talk of at some point making the C# compiler into a "service" - but it's unclear what that means or when that will happen.

While it might look like the code is compiled in-memory (CompilerParameters.GenerateInMemory), that's not what actually happens. The same compiler as the one used in Visual Studio is used to compile the code (csc.exe). It gets started by CreateProcess (much like Process.Start) and runs out-of-process to compile the code to an assembly on disk in a temporary folder. The GenerateInMemory option invokes Assembly.LoadFrom() to load the assembly.
You'll get the equivalent of a syntax check simply by setting GenerateInMemory to false and delete the OutputAssembly after it is done.
While this might sound kinda backwards, the huge benefit it has is that this won't put any memory pressure on your process. This will hold you over until C# 5.0 ships.

Make an executable at runtime

Ok, so I was wondering how one would go about creating a program, that creates a second program(Like how most compression programs can create self extracting self excutables, but that's not what I need).
Say I have 2 programs. Each one containing a class. The one program I would use to modify and fill the class with data. The second file would be a program that also had the class, but empty, and it's only purpose is to access this data in a specific way. I don't know, I'm thinking if the specific class were serialized and then "injected" into the second file. But how would one be able to do that? I've found modifying files that were already compiled fascinating, though I've never been able to make changes that didn't cause errors.
That's just a thought. I don't know what the solution would be, that's just something that crossed my mind.
I'd prefer some information in say c or c++ that's cross-platform. The only other language I'd accept is c#.
also
I'm not looking for 3-rd party library's, or things such as Boost. If anything a shove in the right direction could be all I need.
++also
I don't want to be using a compiler.
Jalf actually read what I wrote
That's exactly what I would like to know how to do. I think that's fairly obvious by what I asked above. I said nothing about compiling the files, or scripting.
QUOTE "I've found modifying files that were already compiled fascinating"
Please read and understand the question first before posting.
thanks.

Building an executable from scratch is hard. First, you'd need to generate machine code for what the program would do, and then you need to encapsulate such code in an executable file. That's overkill unless you want to write a compiler for a language.
These utilities that generate a self-extracting executable don't really make the executable from scratch. They have the executable pre-generated, and the data file is just appended to the end of it. Since the Windows executable format allows you to put data at the end of the file, caring only for the "real executable" part (the exe header tells how big it is - the rest is ignored).
For instance, try to generate two self-extracting zip, and do a binary diff on them. You'll see their first X KBytes are exactly the same, what changes is the rest, which is not an executable at all, it's just data. When the file is executed, it looks what is found at the end of the file (the data) and unzips it.
Take a look at the wikipedia entry, go to the external links section to dig deeper:
http://en.wikipedia.org/wiki/Portable_Executable
I only mentioned Windows here but the same principles apply to Linux. But don't expect to have cross-platform results, you'll have to re-implement it to each platform. I couldn't imagine something that's more platform-dependent than the executable file. Even if you use C# you'll have to generate the native stub, which is different if you're running on Windows (under .net) or Linux (under Mono).

Invoke a compiler with data generated by your program (write temp files to disk if necessary) and or stored on disk?
Or is the question about the details of writing the local executable format?

Unfortunately with compiled languages such as C, C++, Java, or C#, you won't be able to just ``run'' new code at runtime, like you can do in interpreted languages like PHP, Perl, and ECMAscript. The code has to be compiled first, and for that you will need a compiler. There's no getting around this.
If you need to duplicate the save/restore functionality between two separate EXEs, then your best bet is to create a static library shared between the two programs, or a DLL shared between the two programs. That way, you write that code once and it's able to be used by as many programs as you want.
On the other hand, if you're really running into a scenario like this, my main question is, What are you trying to accomplish with this? Even in languages that support things like eval(), self modifying code is usually some of the nastiest and bug-riddled stuff you're going to find. It's worse even than a program written completely with GOTOs. There are uses for self modifying code like this, but 99% of the time it's the wrong approach to take.
Hope that helps :)

I had the same problem and I think that this solves all problems.
You can put there whatever code and if correct it will produce at runtime second executable.
--ADD--
So in short you have some code which you can hard-code and store in the code of your 1st exe file or let outside it. Then you run it and you compile the aforementioned code. If eveything is ok you will get a second executable runtime- compiled. All this without any external lib!!

Ok, so I was wondering how one would
go about creating a program, that
creates a second program
You can look at CodeDom. Here is a tutorial

Have you considered embedding a scripting language such as Lua or Python into your app? This will give you the ability to dynamically generate and execute code at runtime.
From wikipedia:
Dynamic programming language is a term used broadly in computer science to describe a class of high-level programming languages that execute at runtime many common behaviors that other languages might perform during compilation, if at all. These behaviors could include extension of the program, by adding new code, by extending objects and definitions, or by modifying the type system, all during program execution. These behaviors can be emulated in nearly any language of sufficient complexity, but dynamic languages provide direct tools to make use of them.

Depending on what you call a program, Self-modifying code may do the trick.
Basically, you write code somewhere in memory as if it were plain data, and you call it.
Usually it's a bad idea, but it's quite fun.