Closed akbertram closed 7 months ago
It doesn't seem very clean to have this dependency even if the files/projects are unrelated, no ? What about not adding the dependency if mono is unavailable ? or disabling msbuild task in that case, and not adding any dependency to disabled msbuil taks ?
Thx !
It's tricky because if the msbuild task is requested and mono is absent, then the build should fail. But if the task was disabled by the absence of mono, then the overall build would actually succeed.
Is mono really necessary for parsing the project file? The XML looks straightforward; would you accept a PR to replace the .dot net parser with a groovy implementation?
Unfortunately, MSBuild XML can't be evaluated correctly without a CLR impl, because some C# code is written in the XML (string manipulation, registry access...) and needs to be evaluated to properly load the various elements. I used a primitive evaluation engine before (you can find it in the history), but it was so broken I had to implement a C# parser instead.
I'm still trying to get the plugin to complete the configuration phase without requiring mono, and found another case where mono gets invoked during the configuration phase: when AssemblyInfoVersionPatcher is enabled, it will check at configuration time which MSBuild projects include the files and then add a dependency.
This change makes all
MSbuild
tasks depend onAssemblyInfoVersionPatcher
tasks. This should actually be fine, because it shouldn't trigger the msbuild unless one of the msbuild projects is actually changed by the assembly info patcher task.