You should not generate a class when there is no code but using. about codegeneration.roslyn

[amis92]

Would need fixing the condition here:

CodeGeneration.Roslyn/src/CodeGeneration.Roslyn/CompilationGenerator.cs

Line 122 in b889381

if (anyTypesGenerated)

and actually using that emptyFiles collection somewhere.

[pcwiese]

@AArnott Re: the Generator metadata item...has this been tried recently? Perhaps I have a goofy setup but from I can tell I can remove this default item metadata setting entirely and it will still generate code for all source files if the CodeGeneration.Roslyn.BuildTime package is referenced. The GenerateCodeFromAttributes Target which just passes through to the GenerateCodeFromAttributes Task passes @(Compile). It never looks or filters this list out to just those Compile items with the Generator metadata set.

[mwpowellhtx]

Question is, is this fix in the pipeline? It's been known, it seems , for well on to a full YEAR now.

[AArnott]

It's a low priority. It doesn't hurt anything, and the last time I looked into this, generating these files made it easier to do up-to-date checks so that we don't generate anything if we don't need to. See, if I don't generate an 'empty' file, then next time we build, how do I know whether the file is missing and must be regenerated, or simply doesn't need to be generated? I can't know. But if I generate empty (harmless) files, there are two files (source and generated) for me to compare timestamps for.

Now that I've said it out loud, it seems pretty clear that this is by design. Unless someone can propose a way to keep incremental builds efficient without these files (and perhaps is willing to submit the PR), I think this is as good as it gets.

[AArnott]

I suppose what we might do is not add the empty generated files to the Compile item list in msbuild, although the files would still exist on disk. I'm not sure what that buys anyone though. Why not send a few more empty files to the compiler?

(tip: if you're going to say "faster builds", I'd ask for data to back up the assertion that the build would be significantly faster).

[mwpowellhtx]

I suppose it shouldn't be of concern? That said, those harmless files do seem benign to me. Using statements are fine, aren't adding any logic that I know of, and may simply echo already-held dependencies, that sort of thing. No big deal, as long as that's all it is.

I haven't considered what it might mean for 2+ generators to coexist? Probably a separate concern.

[AArnott]

Also: we only generate "empty" files for source files that claim to be inputs to the generator. If you don't submit the source files for consideration to generate another code file, we won't generate the empty file.

So you might say the real issue is the build authoring that submits too many files. That would be here:

CodeGeneration.Roslyn/src/CodeGeneration.Roslyn.Tasks/build/CodeGeneration.Roslyn.BuildTime.props

Lines 9 to 13 in 8113bbd

	<ItemDefinitionGroup>
	<Compile>
	<Generator>MSBuild:GenerateCodeFromAttributes</Generator>
	</Compile>
	</ItemDefinitionGroup>

For convenience, we by default just submit all compile sources for code generation. But you could override this ItemDefinition in your own project to reset it, then opt in individual files for code generation.

[AArnott]

I haven't considered what it might mean for 2+ generators to coexist? Probably a separate concern.

That's an interesting question that if I ever considered, I don't remember what the fallout would be. If it turns out to be a problem, please file an issue.

I suppose it shouldn't be of concern?

No concern. Using directives have absolutely no impact on the compiled assembly. Types, attributes, delegates, and other "real things" do. Using directives only make it more convenient to code up these real things. So your empty source files' only effect (if any) would be that your PDB might mention the paths to these files as inputs.

[mwpowellhtx]

👍 Thanks, I'll have a look at doing that; opting in for only the files of concern would be preferable, I think.

[bhugot]

Another problem is when you have conditional #if in the using somewhere you need to change your code to keep them else you have compilation error

#29 #32

[AArnott]

Ah, that's a bummer. I'm glad we have issues tracking those. Once I get the whole system working again with the latest tools, I'll try to address some of those.

[mwpowellhtx]

@AArnott This is the illustration of the props file, but would you mind showing an example opting an individual file in for code generation, say, Test.cs? Do the <Compile/> options, for instance, apply only to thoseItem(s) declared in that section?

[AArnott]

Sure. First you need to opt out of selecting all:

 <ItemDefinitionGroup> 
   <Compile> 
     <Generator />
   </Compile> 
 </ItemDefinitionGroup> 

Then you can set individual files to opt-in. You would typically do this within Visual Studio's Custom Tool property for the file by filling it in with MSBuild:GenerateCodeFromAttributes

This will effectively do this (which you could do yourself too):

 <ItemGroup> 
   <Compile Include="Startup.cs"> 
     <Generator>MSBuild:GenerateCodeFromAttributes</Generator> 
   </Compile> 
 </ItemGroup> 

[mwpowellhtx]

@AArnott 👍 Perfect, thank you for the illustration. I just wasn't certain of the protocol, involved tags, etc.