Target Cake.Tool

[RLittlesII]

So that Cake.Recipe can load all addins from Cake CoreCLR runner.

[AdmiringWorm]

@RLittlesII I don't think that would be possible right now.
From what I gather, not every addin that Cake.Recipe uses supports .NET Core yet, and some of them (if I remember correctly), is somewhat of a core feature of the Recipe.

[RLittlesII]

@AdmiringWorm It isn't possible right now. I have been working on an initiative to port all the dependencies to netstandard1.6. This issue is part of that project. I am close now, I just need to kick the tires on a few addins to make sure the conversion didn't break anything.

[gep13]

@RLittlesII @AdmiringWorm if we go ahead with this, guidance would likely be to use Cake.Tool, rather than CoreCLR, but I think we should still try to be able to do this.

[RLittlesII]

@gep13 Correct me if I am wrong. The difference between CoreCLR and Cake.Tool is just the mechanism by which is packaged and delivered? It's still technically the dotnet version of Cake not the .NET Framework version. Correct?

So we are saying that we would only be able to access this through dotnet cake ?

[devlead]

@RLittlesII Essentially yes, also Cake.CoreCLR is .NET Core 2, Cake.Tool is NET Core 2.1 (soon also 3.0).

If it works with Cake.Tool then it should work with Cake and Cake.CoreCLR too.
But recommendation would be Cake.Tool.

[gep13]

Before we are going to be able to do this, we need to figure out how to fix this:

cake-contrib/Cake.Issues.Reporting.Generic#3

[AdmiringWorm]

@gep13
Before we are going to be able to do this, we need to figure out how to fix this:

or conditionally disable the reporting functionality (of course this means not loading Cake.Issues recipe as well).

[gep13]

Yes, that would be an option if we could conditionally load adding into the running process, but as it stands, that still isn’t possible. We could try to do something “clever” by making the addin directive itself conditional, but I really don’t like that approach. The contributor who was working on getting RazorLight working has at least responded, so it isn’t a complete dead end, so hopefully that addin will be updated soon.

[AdmiringWorm]

Yeah, did some experiments with conditionally loading Cake.Issues.Recipe by trying to use pre-processor if/else statements that I assumed would have been available with Cake 0.35.0.

Unfortunately, this was not honored, and it would still load Cake.Issues.Recipe.
EDIT: Or at least, I couldn't figure out how.

[gep13]

I believe I am right in saying that those if/else statements are outside of the pre-processor logic within Cake, but @patriksvensson @devlead @mholo65 might be able to confirm this. So although a good idea, I don't think that is a route that we can go down 😢

[devlead]

If else statements are processed in Roslyn after preprocessor statements are processed. They work on a C# level.

Something you could utilize is environment variables which are expanded before directive is processed. So you could switch which version is loaded, even which addin is executed, etc.

https://github.com/cake-build/cake/blob/daa3c4f26a5d54cbb8c0b65301eca098d2703f01/tests/integration/Cake.Core/Scripting/LoadDirective.cake#L2

[bjorkstromm]

Yes, that's correct. Preprocessor logic is not aware of defines. See issue cake-build/cake#1860

[gep13]

@devlead @mholo65 thank you both for the confirmation, this is what I thought.

[pascalberger]

@gep13
Before we are going to be able to do this, we need to figure out how to fix this:

or conditionally disable the reporting functionality (of course this means not loading Cake.Issues recipe as well).

If someone get conditional loading to work, we should not implement it here, but upstream in Cake.Issues.Recipe.

Beside having the option to toggle individual features, it would also make sense to only load build server integration if running under the specific build server or only loading issue providers which actually are an input file passed.

This is cake-contrib/Cake.Issues.Recipe#17.

[gep13]

@pascalberger thats a fair point!

[gep13]

I am going to go ahead and close this issue out, as I believe we have got most of this figured out. There might be some additional points that come up related to this, but the guts of the work has been completed, and tested and known to work.