What do you do for deployment concerns? about recordgenerator

[mwpowellhtx]

I should also ask, how is it you utilize CodeGeneration.Roslyn.Tasks? i.e. CodeGeneration.Roslyn.BuildTime

[amis92]

• Analyzer VSIX is mainly for debugging purposes - it's not really possible to debug the analyzer on its own. Debugging VSIX launches new "clean" Visual Studio instance with that VSIX installed. Of course, you could distribute analyzer by VSIX, but it's very different. Analyzers installed via NuGet are per project, and VSIX install makes given Analyzers global for that VS instance.
• Yes, main NuGet package is actually just a bundle of all the other packages, and also yes, it's declared as development dependency.
• If you decide to distribute VSIX, I can't help, I haven't explored that area.
• I'm not sure with what project/package do you want to target both 1.6 and 2.0 of netstandard.
• I'm also not sure what is it you ask about CodeGeneration.Roslyn.BuildTime. It's a package required in the project that has the code generated. It's a package that adds appropriate MSBuild Targets which actually run the CodeGeneration.Roslyn.Tool (ala dotnet-codegen) during build. So when you consume a generator by NuGet, you need to reference both (BuildTime + dotnet-codegen).

For an example of using my RecordGenerator, please take a look here: https://github.com/WarHub/wham/blob/b22182b7ee1fbe09b848454be80e44c0bfad9f3d/src/WarHub.ArmouryModel.ProjectModel/WarHub.ArmouryModel.ProjectModel.csproj

[mwpowellhtx]

Analyzer VSIX is mainly for debugging purposes... If you decide to distribute VSIX, I can't help, I haven't explored that area.

I wasn't considering it, outside of sorting out the bits as a frame of reference. Re: debugging, makes perfect sense, fair enough. But for that matter if it can be distributed via NuGet package reference, then I should think in theory that a project reference would be sufficient?

Re: dotnet-codegen, would that make sense as a bundle dependency then? Or is that not really related, per se? i.e. not that strong of a dependency...

Thanks again for the clarification! 👍

[amis92]

[…] But for that matter if it can be distributed via NuGet package reference, then I should think in theory that a project reference would be sufficient?

Yeah, no. Analyzers are loaded in a special way from NuGet packages, and Project-to-Project references don't work.

dotnet-codegen is a DotNetCliTool and so must be directly referenced from consuming project. Making it a dependency of your generator won't import it into generator-consuming project.

[mwpowellhtx]

@amis92 Stupid question on my part perhaps, but once you get a debug VS session running, what do you do to actually conduct testing? I do not see, for instance, what I expect for analyzer light bulbs, etc, showing up, never mind opportunity for code fixes.

My Analyzers project is targeting .NET Standard 1.6, I think. It must target 1.3?

[mwpowellhtx]

@amis92 I came across this EF LINQ analyzer project, which seems to have some unit testing comprehension that does not include working through a VSIX session. From the looks of things, they embed source code as a file in an assembly resource, then have Roslyn attempt to compile that file, the diagnostic output from which may or may not include the expected analyzer bits. Thoughts?

[amis92]

I can't answer most of your questions, too little context.

• I don't know what doesn't work for you with VSIX debugging. Works for me.
• I don't know exact requirements for Analyzers (netstandard 1.3/1.6).
• [EFLINQ tests] That's cool. Testing is not debugging though. I've got my tests, too. I also do similar things, except I embed the code insinde test files, which may probably be a worse idea.

From the sounds of it, you might be confusing unit tests (which are xUnit-based in case of this repo, and also fire up roslyn and check it's results), with debugging the analyzer, which involves debugging VSIX extension. This is done by Visual Studio by launching a new instance of "temp" clear VS install with that VSIX installed (which means that it has your Analyzer globally installed). Then you can create or open some project, write some code and set breakpoints within the code of your analyzer that get hit when the debug-instance-VS runs background/foreground Build, which in most cases means immediately after you write Analyzer-activating code.

[mwpowellhtx]

No, I'm pretty clear, I think. My point there is, if the code is active in any way via an in-memory Roslyn instance, let's say, as in the unit tests, then I should think it would be possible to also debug the same code Roslyn leverages in order to achieve the diagnostic response. At least that's my understanding; I'm working through it at the moment.

As for the VSIX devenv instance; yes, I understand all that, such as it is. However, I half expected to see a couple of those breakpoints, and I could even see my extension among the listed extensions, but for whatever reason, I was not finding my analyzer breakpoints. I'll double check I am rolling up the analyzer properly in the VSIX, but I thought I was.

That's when I drudged up the EF tests, and figured, if I can invoke Roslyn directly like that, and embed an analyzer, then I don't need to muck around with VSIX at all.

[amis92]

Well, the unit tests here are template-generated (everything except RecordMustBePartialTests.cs).

And I can definitely debug my analyzer when debugging unit tests. Roslyn is just an API. Here is the call to make compilation with analyzers:

RecordGenerator/test/Amadevus.RecordGenerator.Analyzers.Test/Helpers/DiagnosticVerifier.Helper.cs

Line 60 in 20720be

var compilationWithAnalyzers = project.GetCompilationAsync().Result.WithAnalyzers(ImmutableArray.Create(analyzer));

[mwpowellhtx]

Ah, 👍 yes, indeed.

[mwpowellhtx]

👍 I like the idea of keeping all theorized inputs and outputs neatly bundled together; as contrasted with exposure of source inputs via resource inclusion.

[mwpowellhtx]

@amis92 I need a little help, couple of clues, which project template? I'm catching wind that perhaps it originated in the .NET Compiler Platform SDK (?), i.e. Roslyn?

[amis92]

Yes, that's the one.

[amis92]

The SDK you mentioned installs the templates shown above.

[mwpowellhtx]

Oh okay, yes. I just realized this today.

[mwpowellhtx]

Perhaps I am missing something... There are a handful of metadata references appended to the ad-hoc workspace Solution Project, but I do not see any of the Record Generator stuff added. Are those carried along with the project itself?

[amis92]

The generated stuff is visible from VS class tree view within Solution Explorer:

Here, when you double click on one of the generated members, it'll open read-only generated file from /obj folder. These files are generated on every build, and so do not persist in VCSs (git/tfs).

[mwpowellhtx]

Thanks for all the feedback. I think I got it more or less sorted. It seems like order matters, so I added the references from the base class first, followed by those that are application specific, then the Roslyn compilation verification worked.