Closed petarpetrovt closed 3 years ago
I am not sure this is needed? DefaultDocumentation doesn't need to be compiled in the same framework as the one of the project you are using it on. The reason for including both .net framework 4.7.2 and net core 3.1 was because I wanted a solution that work for windows without the need to install anything (.net framework 4.7.2) and an other one for other os (.net core 3.1) but honestly most people will probably have the latest .net installed so I was thinking of only using .net5.
As you said you should be able to generate framework specific documentation if your project use multiple targets by including $(TargetFramework)
in DefaultDocumentationFolder
, and even by default it will use the parent folder of DocumentationFile
which should be framework specific.
I don't feel like installing .net5.0 SDK on my project CI env just because DefaultDocumentation needs it. But feel free to close this PR i will use local build then.
you wouldn't need the sdk, just the runtime. I am just trying to understand what purpose adding all those target to DefaultDocumentation serve? Ensuring that you have the sdk (and thus the runtime) installed to make the tool run?
Yeah if the tool targets multiple frameworks there will be no need for specific runtime to be installed. The best case will be if the tool is self contained but i don't think thats possible.
looking at some package I use for inspiration (coverlet), it should be possible to compile DefaultDocumentation in netstandard and expose it as a msbuild task, thus not relying on any hard runtime installed (well, you would still need something that can run netstandard2.0 so net461 or netcore2.0 at least). I think that would be a good enough compromise? I will try to look into it.
edit:
The best case will be if the tool is self contained but i don't think thats possible.
Just to comment on this, yeah netframework is self contained (because the framework is included with windows) but only work on windows, doing the same for netcore targets would greatly increase the package size since runtimes for all os would need to be included so it's not really a viable solution.
Sounds good to me
Hello,
This PR adds support for more target frameworks not only (framework4.7.2 or netcoreapp3.0):
DefaultDocumentationFallbackToolTargetFramework
);For libraries that target
netstandard
the tool fallbacks to the specified fallback target framework (by default is set to .net5.0);One possible improvement could be made inorder to support multiple target frameworks by default is to set the default
DefaultDocumentationFolder
inbuild/DefaultDocumentation.targets
to include$(TargetFramework)
. That way when for example my library X targetsnetstandard2.0
andnet5.0
multiple documentation versions will be generated in different directories. (but this is not required because user can specify it manually)I have local build for my needs, but i will love to seе these changes in the official package.