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.
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
which is logged from
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.
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?