[BUG]: .NET 8.0 - MSB4062 The "WriteVersionInfoToBuildLog" task could not be loaded - reloaded #4116
Comments
|
I'm guessing you're using VS due to the Apparently the GitVersion team dropped support for Visual Studio entirely, regardless of the target framework being used. 😕 Or at least that's the way I understand the replies... |
|
@Szaamaan , you're seeing that header because that's the CLI I've used to output local versions of msbuild, sdk, ecc.. But yes, I'm using VS2022., but I'm not trying to use GitVersion with anything .NET Framework related, I'm all on .NET 8. |
Yes, I know. But despite this, apparently, something doesn't work quite the same way with Visual Studio's On that note - do you get the same results if you run |
|
I've just tried building with
Reverting to Maybe it's me, but I'm staying on |
|
I have the same issue. MSBuild task won't generate static GitVersionInformation class. I can't compile any of my projects after upgrading from |
|
Same issue here. 6.0.0 and 6.0.1 are both faulty. |
|
@ashleyjlive any chance you could retry it with 6.0.2, just to keep this issue relevant? |
|
@sanghel-orbyta I've got the same issue with VS 2022 and .NET 8.0 and version 6.0.2 didn't resolve this for me. |
If an issue is closed and there is a comment similar to #4157 (comment), only in that case the issue is considered fixed, or if we explicitly mention. At this moment VS is not supported because of the reasons mentioned #4130. Hopefully we will have the time to find a solution, but at this point if you need to use the MsBuild package together with Visual Studio I would recommend to stick to version 5.12.0 for now |
Tested with 6.0.2 -> Still an issue. I have the same error but for My error is: GitVersion.MsBuild.targets(105,9): error MSB4062: The "GenerateGitVersionInformation" task could not be loaded from the assembly
C:\Users\REDACTED\.nuget\packages\gitversion.msbuild\6.0.2\tools\net8.0\GitVersion.MsBuild.dll.
Could not load file or assembly 'System.Runtime, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies.
The system cannot find the file specified. Confirm that the <UsingTask> declaration is correct,
that the assembly and all its dependencies are available,
and that the task contains a public class that implements Microsoft.Build.Framework.ITask.Many things inside |
|
@ashleyjlive - I was able to work around that by adding to the csproj: I have it (I think) working a project but not another. See also: #4130 |
|
Wow ... I misunderstood the "not supported" as "we do not have the time". But alas it has actually explicitly been removed (my bad). This is from the props file:
I now see it in the breaking changes (good). Missed it before. :-( @arturcic - Perhaps the GitVersion site (https://gitversion.net/docs/usage/msbuild) should mention GitVersion.MSBuild's Visual Studio retirement . Could save a lot of time. I think there is a big difference between a bug that may take a while to fix and a retirement of support for Visual Studio. Is there any point looking into it if the team does not plan to support VS? |
|
BTW - .NET Framework support is not actually required to work in VS. As a minimum it needs to support .NET Standard 2.0 and that was removed in 6.0.0. |
|
@arturcic - had a bit more of a look and I think the .NET Standard 2.0 support, and hence Visual Studio support, was dropped in a commit Jan 9, 2023 (merged Feb 18, 2023). There is another possibly related commit Nov 6, 2023. I think, these are your commits. Can you tell me if loss of VS support was a side affect here or intentional? It looks like it may be a clean-up moving stuff to the root folder. Commits: Thanks |
|
@RobSmyth the idea was we wanted to start using the new APIs in the newer versions of .NET and targeting netstandard put too much maintenance on us. Same for the .net framework. Then we saw it was broken in VS and we had to decide to either spend time on building new features, take advantage of new APIs, or be stuck on netstandard. At this point netstandard was needed mainly for GitVersion.MsBuild package which is not the most used package we publish, it's like 5% of the usage and was like 60% or so of the effort. That still does not mean we will not get back to this issue at some point, but that will take time, and it will require a different approach |
|
Thanks @arturcic - Shame but I understand. Blocker for me as I've always seen the dotnet tool approach as a workaround and would rather see MSBuild do it. Also kills a project I was about to release GitVersion.Afterburner!! :-) That clarifies it so i'll do something else. But ... I do think it would be good to update both the breaking changes and also the site. Not supporting .NET 4.8 does not read as "Dropped VS support". It will save a lot of angst making it clear. Thanks :-) |
|
Hi everyone, I have just come across GitVersion as we are planning to use this with our company projects. obj\Debug\Debug\net8.0\GitVersionInformation.g.cs(28,1): error CS1022: Type or namespace definition, or end-of-file expected The file GitVersionInformation.g.cs seems to only get generated if you set UseProjectNamespaceForGitVersionInformation to true. Inside GitVersionInformation.g.cs , I think GitVersion is trying to inject the "RootNameSpace" or if not, it will inject the project name. The compile/build error I traced back to a potential bug in the class: internal sealed class GitVersionInfoGenerator(IFileSystem fileSystem) : IGitVersionInfoGenerator in Modules.GitVersion.Output.GitVersionInfo The line of code that seems to be causing the issue is commented below: string getTargetNamespace(string extension) => extension switch there seems to be an extra semi colon here: ....... namespace {context.TargetNamespace};" : "" This I think caused the GitVersionInformation.g.cs to be created like : namespace MyChosenRootNS; If that extra semcolon is removed from that class, it should result in the namespace to be injected without ";". And donet build works fine in creating the GitVersionInformation.g.cs file I am not really sure, but just a hunch, and hope this helped out. Regards, |
|
@tammha if you want please submit a PR with the fix |
|
I'm keen on this functionality being returned. It's great to output the |
Unrelated note:I stumbled on this issue while debugging issues with my own custom build task that worked with Rider but not with Visual Studio. The cause of the issue was that I followed the official instructions to create a nuget package but targeted When using |
|
@sanghel-orbyta with Rider no issues!!! |
|
FYI, I created https://www.nuget.org/packages/Dorssel.GitVersion.MsBuild, which does support Visual Studio even with version 6 GitVersion tool. |
Very nice. That ought to help a lot of people who want to stay with GitVersion. I went a different path with the version 6 release and created a different versioning framework entirely. |
May I curiously ask what you went with? |
Why the fork instead of contributing a PR ? |
I don't mind having a fork, as long as the idea works and when it covers most of the current functionality we can re-integrate as long as the license permits. At least the ideas are welcomed |
It's not really a fork, just a lightweight re-implementation. From the closed "won't fix" issues reported here my guess is that GitTools chose not to support anything except .NET CLI build; i.e., they are aware that VS no longer loads their MsBuild tasks and are fine with that. |
I actually mentioned the reasons already before and also mentioned
Which might be similar in approach with solution provided by @dorssel |
I'm now using my own: Git2SemVer.MSBuild. It uses a dotnet tool for setup and, in beta, to generate versioning info too: Git2SemVer.Tool. Working well for me but it is early days. Under active development. These do not try to replicate GitVersion but take a different approach. No commit depths (counts) :-) |
You have tried to explain the reason and I'm sure they are self evident to the team. But, at least to me, the reasons given a vague. What I remember hearing are:
If we take those reasons as given then:
However, if you could give details on the perceived problems like:
Then others may be able to provide solutions, or start discussions, for resurrecting the very important VS support. I'm sure people want to help but just do not know how to. I started to look to help but got stuck on "it was removed for a reason, how can I restore it without knowing the need and problem?" |
A simpler way to understand which API/features we want to use, just add this line
As for the possible solution for the GitVersion.MsBuild package. In the current implementation At this moment
The last 2 tasks: The remaining 2 tasks should be kept in GitVersion.MsBuild as these are the only features it adds on top of Hope these answer the questions and the vision for the |
|
Thanks for taking the time to try and give more info, but it does not answer my questions. Sorry, probably I'm just thick. Hope it works out for you as you have put a lot into it over a long period you have helped a LOT of people. The fundamental for me is that I do not need to install any other tools, no external scripts ... the project compiles and versions in VS and dotnet CLI the same. I hold it important that devs get versioning and devs compile the same as the build system does. I think I'm just getting in your way. Thanks again for taking the time. |
|
@arturcic Ideally , MSBuild should be "standalone", written in netstandard2.0. Then is fine to have the "Core API" and the CLI tool using .NET 8+. It is up to you if you want to "embed" the pre-compiled CLI tool in the MSBuild package, or require the tool to be installed separately (like I did). I also agree that the WriteVersionInfoToBuildLog task (which I made a no-op) and UpdateAssemblyInfo (which I omitted) are no longer required as tasks. All that remains is a simple task to run the CLI tool, and one that generates the GitVersionInformation class (for multiple languages, of course, not just for C# like I did). If my attempt could somehow be merged back into GitTools/GitVersion I would be very happy. |
Well actually I checked you repo and that helped with the response and the plan I mentioned above. So we need to deprecate those 2 tasks as they are duplicating what the dotnet tool does, which I guess for now we can embed (as we are testing the msbuild in docker images and the tools should be already available). And then we can just have the other 2 tasks consuming the json file and do the stuff. I think it's better to have a different package like GitVersion.MsBuildv2 so that people can give it a try and see it works, that will eventually replace the current GitVersion.MsBuild |
Prerequisites
GitVersion package
GitVersion.MsBuild
GitVersion version
6.0.0
Operating system
Windows
What are you seeing?
I'm seeing the error:
#3787 and #3704 suggest that after the betas, version
6.0.0should work with .NET 8.After the above error is triggered, even reverting to
5.12.0yields:which weirdly tries to use
net48, even though I'm not on the .NET Framework anywhere in my solution.When the error is triggered, the only way to recover (remaining on
5.12.0) is to close and re-open solution (I'm not sure but it seems the error leaves a dotnet.exe process.. )What is expected?
Task works as with version 5.12.0
Steps to Reproduce
With:
My csproj has:
RepositoryFixture Test
No response
Output log or link to your CI build (if appropriate).
No response
The text was updated successfully, but these errors were encountered: