GitVersion throws errors MSBUILD : Task factory warning NMSBT010: There is a mismatch between SDK NuGet version (4.8.0) and the NuGet version the task factory was compiled against (4.6.0). There might occur some exotic errors.

[ngeegoh]

I have installed GitVersionTask (4.0.0-beta0014) in VS17. I have many projects (different packages) inside the VS solution. When I ran dotnet build, I got this error:
MSBUILD : Task factory warning NMSBT010: There is a mismatch between SDK NuGet version (4.8.0) and the NuGet version the task factory was compiled against (4.6.0). There might occur some exotic errors.
I have googled but still could not find the solution for this. Just wondering if this the issue with GitVersion when running in VS?? To be more specific, I added a gitversion step in my cake script (set the updateAssemblyinfo to TRUE), then when it moved to the dotnet build step, it threw the above error. When I checked the assemblyinfo.cs in VS, I can see GitVersion added the version in that file but it was complaining because it did not have System.Reflection imported. I tried to import that namespace and re-ran it, it also threw an error "duplicated System.Reflection" ? It did not add that namespace before and when I added it, it complained.

Another question is what would be the best practice if I want to version different packages (increment based on their changes, so I assume every package inside that repository will have different version number) and get them built in VSTS? At the moment, I can add GitVersion step in VSTS to get the SemVer version and then pass that value in the packing step. However, the process will pack ALL packages with the same version number not version them individually.

For example, let's say I got 3 projects (MyComponetA, MyComponentB and MyComponentC) under one repository called Apple. I made some changes in MyComponentB and want to increment the MINOR, and keep the version of others the same as no changes made. When I build Apple repository in VSTS, after packing and pushing, I expect to see MyComponentB's minor version incremented and others' versions could be either remain the same version or version with metadata(build number).

[dazinator]

The build warning you mentioned should be fixed soon, hopefully with https://github.com/GitTools/GitVersion/pull/1470
re: multiple projects in the same repo and versioning them independently - usually I version everything in a repo together, if I need to version things individually I usually move them out into their own repo's. That's just how I do it - perhaps their are other ways. I have also used git submodules in the past - i.e you have main repo, and you bring sub-components in via submodules. Submodules are just other git repo's that pulled in to your main git repo like they are seperate "child" git repo's. This means they have their own git history, and you can run gitversion on them individually - perhaps that might help you. I try to avoid this complexity wherever possible however.

[dazinator]

Please can you try this version of the package and let us know if this resolves your build warning issue?

<PackageReference Include="GitVersionTask" Version="4.0.0-pullrequest1470-1617">
      <PrivateAssets>all</PrivateAssets>
    </PackageReference>

Thanks.

[bobted]

@dazinator, I've not had a chance to get back to the discussion in #1445 so I'm glad to see this thread. I just updated to VS 2017 v15.8.3 this morning. The release notes state that v15.8.2 included an incompatible pre-release of netcore2.1, which made me think about the issue here and a comment you made about the building to 2.1.

After the updated, I've tried to build with both beta0015 and your PR 1470 packages inside and out of VS. Using dotnet build CLI, neither package produces the build warning. As a reference, I went back to beta0014 and the CLI gave me the build warnings.

Also, is it possible to get beta0015 or the next beta package published to nuget.org so we don't have to propagate your feed to our CI?

[dazinator]

@bobted
currently, when merging a PR, the master build is keeps producing beta0015 packages. Therefore the beta0015 package you tried out, may have been the one after my PR was merged with this build warning fixed, or it could have been the one before (i.e if it was in your package cache from before). This is something we need to sort out in #1445 still - i.e when accepting PR's the version should increment :-)

Sounds good though, sounds like this issue is now fixed, so I'll close this for now.

@bobted I think the plan is to have nuget packages publishing to nuget.org again with the completion of #1445 - please comment there for anything further regarding that :-)

[ngeegoh]

Hi @dazinator,

Thanks for your reply, but I still could not install that version of GitVersion to VS since it has not been published to nuget.org. However, if I implement GitVersion, build and pack all the packages (under one repository) inside the _cake script_? Would it be possible that GitVersion will pick up different versions of different projects and increment them individually based on the changes in those projects?
As the workaround, you mentioned above (creating submodules inside a git repository) seems to make it more complicated and difficult to manage.

[dazinator]

@ngeegoh

Thanks for your reply, but I still could not install that version of GitVersion to VS since it has not been published to nuget.org

Yup hopefully once #1445 that will be remedied.

However, if I implement GitVersion, build and pack all the packages (under one repository) inside the cake script? Would it be possible that GitVersion will pick up different versions of different projects and increment them individually based on the changes in those projects?

I am not sure if it's possible to get GitVersion to do this - AFAIK GiVersion operates at a repo level - i.e it inspects your git history to work out commit count, branch structure and other things, and produces an appropriate version number. Because you don't have seperate git histories for each project then I am not sure how it could compute seperate version numbers. Perhaps @asbjornu @JakeGinnivan @GeertvanHorrik or @gep13 could confirm that for you.

As the workaround, you mentioned above (creating submodules inside a git repository) seems to make it more complicated and difficult to manage.

Yup - I would avoid the complexity of submodules if you can live without them.

[asbjornu]

Yes, @dazinator is correct. GitVersion operates at a Git repository level and will not support minting version numbers for individual paths within a repository.

[ngeegoh]

Thanks for your responses @dazinator and @asbjornu , so is it how most companies out there managing their projects (1 repo only got 1 single-project solution) or if not what are the benefits of versioning all projects (in the same repo) with the same number although they got different changes for each projects (which for me, the version does not reflect what we have changed in the projects, some untouched projects will just keep incrementing the version without any changes in there)? I have not found any other tools that help me resolve this case. Just wondering if you guys have any recommendations on this case? Thanks.

[asbjornu]

@ngeegoh: As a long-time Git user coming from a VSS, TFS and Subversion background, I've got experience with both monorepos and repository per project. In my experience, the latter is highly favorable and the former is just an artifact of having a bad VCS. Separating deployable and independantly versionable parts into their own repository makes everything much more manageable and less prone to accidental references across projects. I'd consider it a best practice and it's the only thing GitVersion supports.