Add option to Runner to analyze different stuff

[PiotrZierhoffer]

• one assembly
• a directory (recursively)
• many assemblies

[PiotrZierhoffer]

We still won't handle paths like ../file.dll, because they will jump out of the build directory. How do we handle that? Do we throw everything in one output directory? Currently we recreate the paths relative to pwd, so dir/file.dll becomes build/dir/file.dll

[PiotrZierhoffer]

I believe we should just throw them in one directory, crashing in case of name clashes.

[konrad-kruczynski]

In my opinion:

• Verify if added references have to be in the same directory #19 can be closed
• for invocation like runner.exe somefile somedir/somefile we indeed put modified files in one directory
• however for projects with sophisticated structure we offer an option to eat whole directory recursively and then we replay all the structure in the output directory

[PiotrZierhoffer]

But the question is - will such a sophisticated structure accept references in base dir?

[konrad-kruczynski]

Nope, we'll copy necessary dlls to every directory that contains modified binaries.

[PiotrZierhoffer]

I wonder how will it behave. Probably should be ok, it will load the assembly from the first directory, wherever our libs are called and then it will ignore the others. Am I right?

[konrad-kruczynski]

The scenario I had on mind was even simpler. By sophisticated structure I meant project that actually consist of a core library, and (for example) two user interfaces, so that there are multiple output exes located in different places of the tree. They are, however, independent during execution. I think this structure should be quite familiar :)