-
Notifications
You must be signed in to change notification settings - Fork 59
Use McMaster.NETCore.Plugins for assembly loading #156
Conversation
Cool. The only bad thing about that is that I probably changing my job so I won't need a codegen soon. Waited for too long 😄 Awesome work guys, anyway. Gonna update my library if it fits. I will check this when it gets into the nuget. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks awesome. I definitely need to learn more about this McMaster.NETCore.Plugins too, since I will soon be building a .NET Core app that is extensible.
Please do update the README as you say though. |
Great work guys, this should fix the issue I'm facing right now! |
And it still open. Guys, that issue blocks a lot of good stuff. Consider revisiting it soon? CC @amis92 |
I wonder if this is going to merge before 2020 |
* Tasks deprecate `GeneratorAssemblySearchPaths` usage * Tasks use `CodeGenerationRoslynPlugin` Item instead, which contains concrete assembly paths * Engine targets `netcoreapp2.0` to reference McMaster package * Tests use Amadevus.RecordGenerator NuGet generator for back-compat checks * Tests.Generators use Bogus NuGet for NuGet dependency resolution check
c1aed63
to
e888db1
Compare
I'd like to announce I'm back, working on it. I have to admit, the "your code from 3 months ago could be written by someone else" saying is so true. If someone wants to help, don't hesitate. I'll probably run some tests, try to touch up documentation to the best of my abilities, and push a beta release since I really need some external input and testing. |
I'd like to help but I won't be able to if there won't be a nuget package with it. My primary OS is windows so I only can build in docker. And the only sane way of running it in docker is pull items from nuget. Packing nuget locally and copying it via Dockerfile doesn't seem to be an easy task. |
📝 I'm using |
Now the list of plugin assemblies is always read from response file (plugin list), the last modified time is calculated using those assemblies, and the .AssemblyList.txt file is not created. Also separated reading the results into another target, and set Inputs and Outputs so that the MSBuild can fully skip executing the target that invokes CLI tool.
initial idea in #113
_CodeGenToolVersionExitCode was compared to zero via != instead of ==
this will allow different plugins to have conflicting dependencies
@amis92 Thanks again for putting this together. I'm not sure when I'll have time to play with it. Maybe next week. If I don't get back to you early next week feel free to complete anyway. |
McMaster.NETCore.Plugins
package to resolve assemblies and dependencies, enabling generators to reference additional dependencies! 🎉GeneratorAssemblySearchPaths
usageCodeGenerationRoslynPlugin
ItemGroup instead, which containsconcrete assembly paths (instead of containing folder paths, as was previously)
netcoreapp2.0
to reference McMaster packageback-compat checks
CodeGeneration.Roslyn.Plugin.Sdk
MSBuild project Sdk created, to help build and package plugins correctly.Added https://github.com/AArnott/CodeGeneration.Roslyn/wiki/Migrations#v07 to help with migrations.
closes #114
CC @Pzixel
TODO: