Remove generated code from repo

[angularsen]

Created from comment by @JKSnd.

Also how do you feel about removing the generated files from the repository and adding a pre-build step to the projects to run the generator?

When I started contributing to this project I assumed the generation was to make the initial creation of units easy and nothing more, since the g.cs files were checked in. I feel like I would have been more likely to "fall into the pit of success" if each build re-generated those files because I would have had that test fail locally before pushing.

[angularsen]

I absolutely see how this can be confusing, but here is how I see it:
Pros:

• Users can browse/search GitHub and find the actual code. Maybe while debugging the nuget and want to look up the source, or looking for source via GitHub search or search engines.
• It is easier and less confusing to clone the repo and try it out locally. Adding a pre-build step would mitigate this.

Cons:

• Repo becomes larger to clone
• Not intuitive for everyone that .g.cs are generated code and should not be touched. We could modify the file header to mitigate this?

With this perspective, I lean towards keeping the code checked in, but let me know if you see it differently.

[JKSnd]

I see the value in having the code be browsable and buildable immediately, but I'll play devil's advocate because I was personally tripped up by the generated files being included.

Users can browse/search GitHub and find the actual code.

Let's say the .g.cs files are removed. We could keep one or two mature, stable files around as an example. Then it should be apparent how the project is generated between the examples, the json files and some short documentation in the readme.

It is easier and less confusing to clone the repo and try it out locally. Adding a pre-build step would mitigate this.

I think a pre-build generation step is a good way to make sure it builds immediately after cloning.
It may have been just me, but I found that seeing .g.cs files immediately was confusing. I'm used to seeing generated files formatted this way, but because they were checked in I assumed that implied that their current state was meant to persist and were therefore editable. I'd definitely like to hear other contributor's experiences around this.

Repo becomes larger to clone.

True, but storage is very cheap these days and git handles unchanged files efficiently.

Not intuitive for everyone that .g.cs are generated code and should not be touched. We could modify the file header to mitigate this?

My personal relationship with file headers is this: "Hey look there's a copyright notice. It's licensed under [MIT/BSD/GPL/etc]? Cool!" So I'm a lazy reader and wouldn't be likely to check a header file for these kinds of details. I do, however, read README.md and wiki pages thoroughly when I'm confused or have questions. Again, the opinions of more contributors would be awesome.

Thanks for taking my comment seriously, @anjdreas. This project is a real pleasure to work on.

[angularsen]

I was personally tripped up by the generated files being included

Would it help if we added a pre-build step to regenerate? That would give you compile errors immediately if you tried modifying g.cs files. It does take a few seconds to regenerate, but maybe not too much to be bothersome. And one can disable it locally if one wants to.

We could keep one or two mature, stable files around as an example.

To make the code searchable/discoverable by github and search engines, we would need to have a copy of all generated code in the repo/docs. I am not keen on doing that manually.

Repo size

Agree, not a big concern, it's quite a small clone and git does a good job of handling diffs.

Headers

I don't study headers either, but I actually do think it would help. MS has a dedicated section in the header of their winforms/wpf generated files, so you immediately understand this is generated stuff. It looks very different from the typical copyright notice. I found that helpful in those cases, and it will probably help here too.

[angularsen]

Please review my PR on adding notice in generated files: #201

[780Farva]

Please review my PR on adding notice in generated files: #201

Now that I'm looking at a header that has an auto-generated warning in it, I quite like it.

Would it help if we added a pre-build step to regenerate? That would give you compile errors immediately if you tried modifying g.cs files. It does take a few seconds to regenerate, but maybe not too much to be bothersome. And one can disable it locally if one wants to.

I think so. I feel like the value of having compile time errors notify the contributor that they're doing something wrong is worth the added regeneration time.

To make the code searchable/discoverable by github and search engines, we would need to have a copy of all generated code in the repo/docs

What would we lose in searchability? The json files contain the names of the unit classes and unit enumerations, which would be my personal searching preference.

In my mind, though, adding a pre-build step that refreshes the generated files would be the most valuable. If that were in place then it wouldn't really matter if the generated files were checked in or not as the contributor would be forced to leave them alone anyway.

[JKSnd]

Oops, I replied to that on my hobbyist account! I won't bother to re-approve the PR as JKSnd, but please know that 780Farva is also me. Sorry!

[angularsen]

PR #201 merged.

[angularsen]

Oops, wrong PR.