Okay.
Your criteria/explanations are still a bit jumbled up and I'm still having a hard time envisioning this but I'm getting a better idea of your plan (I think). -i.e. sometimes you are describing a library, and sometimes you're describing a file sync thing, and other times you're describing a processor of sorts.
I think a library (a set of DLLs you can use in your projects) is the best solution:
Pros:
1. No code to copy around.
2. Conforms to the whole .Net concept.
3. Easy to use.
4. Updates are automatic.
5. Quick turn around (fast to get up and running).
Cons:
1. Not sure how VS handles distributions (how to get all referenced DLLs in a package for distribution).
However, if you're dead-set on *not* building and maintaining a library I have some contentions with the processor/file sync thing concepts we'd need to work out later. Namely:
1. What sync method(s) are you planing on, and how are you going to determine which file is outdated?
2. What protocols are looking to sync over (local drive, LAN, WAN)?
3. Are you planning on using compression to keep things small and fast?
But for now we probably start formulating a plan of attack for this
thing you have envisioned.
I took a quick look at your github code and I don't really see any "processor" code at all. I mean, I didn't see any sort of tokenizer, lexer, or a sold parser really (I see a bunch of code that looks more procedural in nature than anything). ...I think you should scrap this and start over. Your
thing will have to be able to operate on at least a few different file types/languages source code files (C# language), IDE project files (XML).
Assuming the simpler/easier to write/maintain recursive-decent type parser, here's how I think you should start:
1. Build a in/out buffer to handle the file/console read/writes.
2. Pick one of the file types to work on first (C# or XML).
3. Develop a good set of tokens and a rock solid lexer base for handling some parts of the file type.
4. Start building an abstract syntax tree for what you have so far.
5. Start building your base-level and your top-level parsers.
6. Build a main driver.
7. Start building tests.
8. Repeat steps 3-5 and 7 to add to your parser parts until you are able to parse one/all of the file types.
Obviously, you need to work on your criteria and this initial plan will change but this should at least get us speaking the same `language'. I also think XML will kill the recursive-decent type processor plan but we need to start somewhere and I think if you only offer limited abilities in your parser
thing you'll be alright.
Sounds to me like you are making this far too complicated and you should step back and work on not only your read me but your criteria as well.
<TLDR>
Um, yeah. I think you got me there. This one is less complicated than my previous efforts but it's still not a "click...next..Yay!" solution. By the time I'm 80 I'll have this nailed. Maybe. The readme definitely needs an edit, it's a midnight braindump.
If all you have in your source project is *.cs files then importing the files with a wildcard into your new project is the easiest solution. Job Done. Ditto if the source project is quite static, nothing much changes. I want a solution that can automatically keep the projects in sync, even if the original source changes radically. I want it to be Visual Studio friendly. I want more coffee.
</TLDR>
Code Cloner is definitely half-baked. Here's the proof (I wrote the following first)...
...you could use a preprocessor to generate code files for you (and update them before you compile)...
That's basically what I want Code Cloner to do, sort of. I want to work with the original files, not proliferate copies all over the place that need to be kept track of and in sync with the original. If I have a bright idea and add it to a target project (because I'm tired and forgot to switch to the original source project) then I want the changes to propagate to all projects - linked files solves that. One version of the Truth. I also want it to work as an easy drop-in on an existing project. You make a call to CodeCloner.exe whenever you want to refresh the target projects. You can check the projects against each other in a text-diff to see what is missing, as a confidence test. As an example, diff the 2x csproj files in the Github project after you build them a couple of times, you will see the added lines in the XML and how they compare to the original.
a use case is ...
- I have a project (or a few, let's stick to one here) in Visual Studio I have written for AutoCAD 2015
- I decide I want to build a version for, say, BrisCAD with the same code (more or less)
- I create a new Solution folder in the solution root called "_Builds". I just pulled that name from the same place John just put his foot. Call it anything you like
- oh, thank you (for nothing!) Visual Studio, now I got to the actual physical folder tree on disk and create the folder in real life. I give it the same name for consistency's sake.
- In this folder I add / copy / whatever new csproj Project. Hmm, this sounds a little like "magic just happened, you got that right?". ok, you can
- copy the existing csproj and hand-delete all the compile stuff then add it as an existing project
- or you can create a new project of the same type. You will need to make sure the namespaces etc match.
- Physically copying the csproj may be easier. Actually, something that automagically clones the guts of the project would be easier
- the new project is the target project. Delete all the code, add the "Clone Zone" placeholders.
- Add a call to CodeCloner.exe as a post-build process. Or pre-build. I made it post-build in the original project because it actually has to build before it can use itself, it was a chicken/egg thing.
- Most of your editing is done in the original source project, you're really only tweaking the target(s) to make them compatible with their target platform.
- ok, I'm bored now, somebody should automate all this crap and get back to me when it works
- time passes...
Well, that was crap. Next!
- I have a project (or a few, let's stick to one here) in Visual Studio I have written for AutoCAD 2016 (time passed, for those of you who noticed)
- I decide I want to build a version for, say, BrisCAD with the same code (more or less)
- I drop CodeCloner.exe in the Solution root (optional, the .exe can live anywhere, that's up to you)
- I call CodeCloner.exe init "_Builds", "_Builds" being the folder name I want to use for the new builds
- New project(s) magically appear under a new Solution Folder. At this stage they are basically clones of the existing project(s).
- In the target project(s) change the AutoCAD References for BricsCAD references and the .NET framework, if required. I will probably want to add/remove/change some conditional compilation symbols. Or not, whatever is your preference
- Fix what broke
- Ship it. Tests? Meh.
I still think that, for a Visual Studio addict like me, linked source code is still the most usable way of using the same code multiple times. I, personally, want to look through the code and see what is going on.
I have (more) work to do....after the day job ...after the kids go to bed. Sleep? Meh.
...unless you want to customize the source code of a compiler...
Hey, there's an idea...what could possibly go wrong?