Skip to content

Latest commit

 

History

History
34 lines (24 loc) · 4.15 KB

CONTRIBUTION.md

File metadata and controls

34 lines (24 loc) · 4.15 KB

Contribution Guidelines

Recasting Code.Generation.Roslyn

We have taken the opportunity to recast the original CodeGeneration.Roslyn [[1]] in several primary ways.

  1. Re-focus Code Generation on just that: FACILITATING CODE GENERATION, specifically in the form of a series of CompilationUnitSyntax [[2]].
  2. To be ultra clear about this, Code.Generation.Roslyn [[3]] (note the difference in punctuation), is not in the business of second guessing anything about your code generators. This includes such things as whether there were namespaces involved, classes, structs, or whatever.
  3. Registries of required Assembly references are maintained during the Code Generation process. The Assembly references is nothing new, but the manner in which we keep track of the Registry is refined.
  4. More critically, we try to prohibit code from generating when triggering assets, the Assembly references, but more importantly the source files themselves in which your Code Generation Attributes appeared as annotations.
  5. We also aggressively purge previously generated code when triggering source files were renamed, moved, or removed.
  6. A big difference between our offering and the original work is in what it is how code generators respond. We want a descriptor in response, which includes a collection of CompilationUnitSyntax items, not MemberDeclarationSyntax. Yes, we want you to produce unit level code.
  7. Another difference is that we also allow you to furnish your own boilerplate preamble comments. If you decline to do this, we will default to canned preamble comments. However, if you do choose to do this, the responsibility rests on your authorship to ensure the comments are correctly formatted as such.
  8. Last, but certainly not least, the responsibility for generating appropriate code rests entirely on your ICodeGenerator [[4]] authorship. We have included a couple of generator examples, which we use throughout the unit tests, as examples for you, along these very lines.

Changes in the unit testing strategy

We were able to improve upon the unit testing strategy in big, big ways. Short of actually invoking the Code Generation Tooling on the command line, let along via Microsoft Build Targets, we were very successfully at invoking the Tooling code programmaticcally.

Therefore, unlike with its predecessor, there is no need to unload any projects as you verify or consider enhancing the unit tests. We have made an effort to capture a handful of likely, even a handful of compelling, certainly more interesting than academic, Code Generation scenarios based on a canned set of project assets.

Requirements

As far as we know, Windows 10 requirements still hold. We have not addressed anything along these lines, so we do not expect the issue here to be any different.

  • If you are running on Windows 10, you need to install the .NET 3.5 optional feature [[5]] in order to compile the project. However, after reading the blogs, this may be easier said than done [[6, 7]].

[[1]] CodeGeneration.Roslyn Github Repository [[2]] Microsoft.CodeAnalysis.CSharp.Syntax.CompilationUnitSyntax [[3]] Code.Generation.Roslyn Github Repository [[4]] Code.Generation.Roslyn.ICodeGenerator [[5]] Install the .NET Framework 3.5 on Windows 10, Windows 8.1, and Windows 8 [[6]] Windows 10 Will not install .Net 3.5 Framework [[7]] Adding features (including .NET 3.5) to Windows 10