lbv
commented
10 years ago Thanks, this is great.
I plan to merge this, but there's a few extra steps I have in mind for afterwards, so I'll mention them here in case someone wants to give some feedback.
The idea is that I want to simplify releases as much as possible. One issue is, for example, that when the version string changes (e.g. from "0.7.0" to "0.9.0"), there's potentially a lot of places where that string needs to be updated. Currently, the most notable place is in AssemblyInfo.cs, which is the reason why I currently have a AssemblyInfo.cs.in file, and a clunky method to update it via make and the file build/version.
As this commit illustrates, there may be many other places where such a string would need to be updated. My plan is to keep then two copies in the repository for each of those files. One manually-updated version with a .in suffix, and one automatically-generated version without the suffix. So, for example, we could end up with:
/build/infiles/AssemblyInfo.cs.in
/build/infiles/LitJson.csproj.in
/build/infiles/LitJson.sln.in
...From which the following would be generated
/src/LitJson/AssemyInfo.cs
/build/MonoDevelop/LitJson.csproj
/build/MonoDevelop/LitJson.sln
...The files in this last group would have a visible notice at the top explaining that these are auto-generated (so people don't change them, but their .in counterparts instead), but they would still live in the repository for convenience.
So, that's the idea for now, but maybe there's a cleaner solution. If you have any comments/suggestions, I'd be glad to hear them. Otherwise I'll merge this pull request as-is and do the changes described above afterwards. Hopefully in a few days.
Added:MonoDevelop Solution/Project files
Note:This is a cleaned,feature only pull request based on the pull request in the link below: https://github.com/lbv/litjson/pull/4