Roslyn: Expose `/refonly` option via MSBuild Tasks

Created on 4 Jul 2018  路  7Comments  路  Source: dotnet/roslyn

Currently, the /refonly option can only be triggered from the command-line, whereas the /refout option is available via MSBuild.
@onovotny pointed out that the /refonly would be useful too.

Area-Compilers

Most helpful comment

In general, I think it would be valuable if all command line options were available via MSBuild. At the very least, how about an "escape hatch" where the user can supply extra command line args to a property that gets passed down to csc?

All 7 comments

In general, I think it would be valuable if all command line options were available via MSBuild. At the very least, how about an "escape hatch" where the user can supply extra command line args to a property that gets passed down to csc?

@onovotny For the /refonly scenario, it looks like the CSC task already supports this, so I can just make a new property that will be passed through. Would that be sufficient for you use case?

For the "escape hatch" idea, I think we'll need some more plumbing, but i'll take a look.

With my proposed change, enabling both properties would lead to a compiler error at build time that looks like
CSC : error CS8308: Do not use refout when using refonly.

@rainersigwald it looks like we already have some logic in Microsoft.Common.CurrentVersion.targets:160 to handle <ProduceReferenceAssembly>. Would we want to add additional logic to detect if both options were being used, and issue a more appropriate error message to the user?

I wouldn't want that logic in common targets. The line you pointed to is there to support reference resolution pointing to the reference assembly, which is a generic concept, but I think this error could live entirely at the Roslyn level.

I think it'd be a good idea for the Csc task to implement a more-relevant-to-MSBuild error than the compiler's error. It looks like there are already some errors like that, like

https://github.com/dotnet/roslyn/blob/91a2a7bac052307d647c02c84163521eb654159d/src/Compilers/Core/MSBuildTask/ErrorString.resx#L124-L127

which is logged from

https://github.com/dotnet/roslyn/blob/9f102c707fc540fc6e805bb6e772fd4ae38d3ebc/src/Compilers/Core/MSBuildTask/Csc.cs#L334-L340

The justification there is about "screwing up command-line parsing" which isn't a danger with the compiler server, but I think "provide an error that is directly relevant to the way the user is calling the compiler" is a good reason, too.

/refonly will be exposed via the msbuild property $(ProduceOnlyReferenceAssembly)

To enable it add the following to your projects csproj file: <ProduceOnlyReferenceAssembly>true</ProduceOnlyReferenceAssembly>

For the 'escape hatch' proposal, the compiler already provides a mechanism to pass in raw parameters via a response file supplied in the $(CompilerResponseFile) property. See Common MSBuild Project Properties

The response file can itself include other response files in order to chain multiple hierarchies of parameters if needed.

@chsienki

For the 'escape hatch' proposal, the compiler already provides a mechanism to pass in raw parameters via a response file supplied in the $(CompilerResponseFile) property.

I think a property that would let you set the parameters directly would be much more convenient than that.

Was this page helpful?
0 / 5 - 0 ratings