-
-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use a custom MSBuild task #112
Comments
I've been thinking about the pros and cons of introducing this in 1.0.0, but still delegating to an executable for now. In order to do proper logging, the executable can write to stderr with prefixes that indicate the log level, so that the task can parse them and propagate them back to the MSBuild logger. Pros
Cons
|
There is a ToolTask type that would be worth looking at to see if it helps with these.
It seems like it could be possible to use the minver-cli output instead of needing a separate project. |
One thing to bear in mind is that there is no such thing as a "current log level" in the context of an MSBuild task, since the host process can have many different loggers attached to it, each configured to a different level. That means that every message, including all debug and trace messages, will have to be output to stderr, and parsed, on every run. Also, I'm not entirely sure that we can just use Putting aside the stdout noise (one line) and the slightly uglier error messages, I believe the only significant functional difference here is the removal of |
The fact that there is no way to know the configured log level is rather annoying. I agree with your assessment that it doesn't make sense to go ahead and try for a task now just to get rid of I'd say this can wait until it's feasible to actually use LibGit2Sharp directly from an MSBuild task. |
Another thing to consider is that currently, MinVer is completely platform agnostic. I.e. it will work for any target framework supported by SDK-style projects. If we introduce a task assembly, then target frameworks start to become something to worry about as detailed in https://natemcmaster.com/blog/2017/07/05/msbuild-task-in-nuget/ |
To cover everything currently supported, |
I tested MinVer in a |
@adamralph While that's cool, I'm not sure how that is relevant? |
@bording it shows that we will lose platform support by doing this. Of course, |
The target platforms of the projects using MinVer aren't relevant for this. What matters is the version of .NET that VS and the SDK are using. Since we only support SDK-style projects, that means VS 2017, so for VS and its MSBuild, we need Building two task assemblies, |
@ursenzler is it correct that you discovered that the target platform of the project does matter? |
@adamralph yes. You cannot use a build task with target netstandard2.0 (the target the MinVerTask would have due to LibGit2) in a project targeting netstandard1.0 for example. |
@ursenzler If you're using the GitVersion package has an example, then I think you might be misunderstanding what's going on because of some choices made by the GitVersion maintainers. The latest version of that package actually has dependencies, and that's going to be what't blocking the package installation on a If done properly, a versioning package like this should have no dependencies, so it will work in any project regardless of the target framework. |
@bording true, but MinVer has a dependency to LibGit2, doesn't it? |
It does, but that's not relevant here because the package will never have a LibGit2Sharp dependency. It will always be bundled inside the package, and will never creep into your projects as a dependency. |
This would probably allow #244. |
No longer blocked by LibGit2Sharp, but unsure if I want to do it anyway. |
@bording I'm leaning towards closing this as a The only benefit I can think of is the removal of There are several costs I can think of:
|
Now that you're no longer using LibGit2Sharp, I agree that there's less of a reason to do this. Even with a custom task, you're still calling a separate process and having to parse output. |
withdrawn in favour of #1021 |
This will replace the use of the
Exec
task to runMinVer.dll
as an executable, with the use of a custom task within that assembly. This is dependent on either #256, or changes inLibGit2Sharp
which @bording is aware of.One functional effect of this change is that the MSBuild verbosity level will be respected, which means that
MinVerVerbosity
will be ignored (probably deprecated initially, with a warning message). This could be considered a breaking change. It will also mean that the calculated version will not be outputted to the console (when the MSBuild verbosity level isdetailed
) as a side effect of using theExec
task.The text was updated successfully, but these errors were encountered: