GitVersionTask v4 with an MSBuild-only project - msbuild

This use case might be a bit off-label, but I'm hoping someone can help me...
For a number of years I've maintained a "library" of MSBuild commands -- in a file we'll call CommonTasks.targets, distributed through our internal NuGet server -- that handles various tasks needed by my company's projects. For the last few years I've utilized GitVersion v3 with it, both for generating the library's own NuGet package version numbers as well as utilizing GitVersion's GetVersion MSBuild target directly (e.g., when generating a corresponding git tag), to avoid needing to extract the GitVersion-generated version from the dependent project's assembly, post-build.
Previously (with GitVersion v3), all that was required was for my CommonTasks.targets file to import the GitVersionTask.targets file located in GitVersion's NuGet package at \build\dotnet\GitVersionTasks.targets. This targets file in turn executed the necessary UsingTask commands (particularly GitVersionTask.GetVersion) which then let me call <GetVersion ...> in my own .targets file after the import.
With v4, GitVersionTask has introduced a dependency on UtilPack.NuGet.MSBuild (which I gather helps with various NuGet commands). To start with, that meant that I needed to import its UtilPack.NuGet.MSBuild.props file, or GitVersionTask wouldn't load at all. However, having done that, I now get unexpected errors attempting to call GetVersion from within an MSBuild file. Seemingly, the GetVersion target now attempts to query all my defined NuGet repositories (nuget.org, local caches, our company server, etc.) for the packaged version of my library, and at the end I'm greeted with this error:
MSBUILD : NuGetTaskRunnerFactory error NR0001: [NuGet Error]: Unable to find package CommonTasks with version
(>= 1.37.0-gitversiontask4-0001) [C:\redacted\CommonTasks\Build.proj]
MSBUILD : NuGetTaskRunnerFactory error NR0001: - Found 108 version(s) in Source1 [ Nearest version: 1.36.3 ] [C:\redacted\CommonTasks\Build.proj]
MSBUILD : NuGetTaskRunnerFactory error NR0001: - Found 42 version(s) in Source2 [ Nearest version: 1.36.3 ] [C:\redacted\CommonTasks\Build.proj]
MSBUILD : NuGetTaskRunnerFactory error NR0001: - Found 0 version(s) in Microsoft Visual Studio Offline Packages [C:\redacted\CommonTasks\Build.proj]
MSBUILD : NuGetTaskRunnerFactory error NR0001: - Found 0 version(s) in nuget.org [C:\redacted\CommonTasks\Build.proj]
MSBUILD : Task factory error NMSBT003: Failed to find main package CommonTasks#. [C:\redacted\CommonTasks\Build.proj(47,9): error MSB4175: The task factory "Ut
ilPack.NuGet.MSBuild.NuGetTaskRunnerFactory" could not be loaded from the assembly "C:\redacted\CommonTasks\packages\UtilPack.NuGet.MSBuild.2.7.0\build\\net46\UtilPack.NuGet.MSBuild.dll". Object ref
erence not set to an instance of an object.
What I don't get is why it's attempting NuGet retrievals at all, and, even if that's the new default behavior, I don't know a way to disable that, or barring that, I don't know why it's not working. I assume the error must have something to do with this not being a normal .NET project (i.e., with no source code aside from a .targets file, no .csproj file, etc.). But my library is used by many normal .NET projects, which themselves use GitVersionTask to auto-version their assemblies.
For now I've pinned my library to GitVersionTask v3, but would very much like to figure out how to allow it to use v4 as I'd been using v3 previously. I could likely switch to using the GitVersion.CommandLine package instead, and parsing its output, but I ultimately do need these GitVersion-generated versions as MSBuild properties in order to use them as intended. And with dependent projects also using GitVersionTask (not the CLI), it's convenient to be able to use a single package for both.
Is there a way to fix what I'm doing with GitVersionTask v4, or some completely different (perhaps more elegant) way to achieve what I'm trying to do?

Related

Visual Studio Extension build failing with Error VSSDK1077: Unable to locate the extensions directory. "Value cannot be null

I have configured a TFS(2017) build pipeline to compile a VS extension with debug mode for a specific requirement which require .pdb files.
The build solution task fails for "debug" configuration with below error, however same pipeline works for the release configuration.
I have tried the approach mentioned in the following discussion as well, howewer it doesn't resolve my issue.
https://social.msdn.microsoft.com/Forums/vstudio/en-US/fd220999-5761-475a-bf86-98dff6b35218/unable-to-compile-vsix-project-that-is-a-part-of-my-solution-using-amd64-msbuild-from-vs2015?forum=msbuild
Appreciate if someone can help me to resolve this issue.
Following is the build configuration used for the Build Solution task:
Following build variables are used to configure build parameters.
Build Error message:
packages\Microsoft.VSSDK.BuildTools.15.1.192\tools\VSSDK\Microsoft.VsSDK.targets
(633, 5)
packages\Microsoft.VSSDK.BuildTools.15.1.192\tools\VSSDK\Microsoft.VsSDK.targets(633,5):
Error VSSDK1077: Unable to locate the extensions directory. "Value
cannot be null. Parameter name: path1". Process 'msbuild.exe' exited
with code '1'.
Update your Microsoft.VSSDK.BuildTools NuGet package to latest version 15.9.3032, just in case it is a problem already solved.
Release configurations can also generate PDB files (Project properties, Build tab, Advanced...button, Output > Debugging information). So, if the Release configuration works for you, you can keep using it while also generating a pdb file with full debug information.
The error is happening when, once compiled correctly, the generated VSIX output file is going to be deployed to the folder for extensions of the experimental VS instance, which is a required step to debug the VSIX file. A possible explanation of the different behavior for Debug/Release configurations is that maybe your .csproj specifies <DeployExtension>False</DeployExtension> for the Release configuration. By default, if not set, that property is set to true in the Microsoft.VsSDK.targets file:
<DeployExtension Condition="'$(DeployExtension)' == ''">true</DeployExtension>
Since likely you don't need to deploy the VSIX to the VS experimental instance when building on a build server (because you are not going to debug it), you can set that property to False to skip the deployment. This can be done with a 3rd build configuration (ex: "DebugBuildServer"), for which you specify DeployExtension to False in the .csproj file, or sticking to two build configurations but passing the /p:DeployExtension=false in the MSBuild arguments of the Visual Studio Build task of your build pipeline.

JetBrains Rider - The task factory "CodeTaskFactory" could not be loaded from the assembly

I am trying to build a former Windows project in JetBrains Rider on a Mac. I am getting the following build error:
NuGet.targets(100, 9): [MSB4175] The task factory "CodeTaskFactory"
could not be loaded from the assembly
"/Library/Frameworks/Mono.framework/Versions/5.2.0/lib/mono/msbuild/15.0/bin/Microsoft.Build.Tasks.v4.0.dll".
Method 'Microsoft.Build.Utilities.TaskLoggingHelper..ctor' not found.
Can anyone help?
This happens because custom msbuild code or NuGet packages you use are using a pre-MSBuild 15 way of referencing MSBuild's CodeTaskFactory.
Check all of your project / build files for occurrences of UsingTask elements referencing Microsoft.Build.Tasks.v$(MSBuildToolsVersion).dll or Microsoft.Build.Tasks.v4.0.dll (or similar dll reference) and change the dll to Microsoft.Build.Tasks.Core.dll.
If the problematic code comes from a NuGet package, see if an update to the package is available or contact its authors.

Reference a csproj from same solution as xproj

I have a solution with the following projects:
MySolution.sln
- MySolution.Client.csproj
- MySolution.Service.csproj
- MySolution.Models.csproj
- MySolution.Server.xproj
MySolution.Models is a simple class library which contains shared code that is referenced by MySolution.Client and MySolution.Service - and I would like to reference it in MySolution.Server.
The GUI in VS 2015 RC1 lets me add the reference by right clicking References -> Add Reference. I then see all my projects under Projects -> Solution.
I select MySolution.Models and click Ok, after which I receive the following error in the output log:
Errors in ...PathToSolution\MySolution.Server\project.json
Unable to locate MySolution.Models >= 1.0.0-*
It really feels like this should work, since the GUI allows me to add the reference without any hiccups.
So the first thing to understand is DNX projects have no understanding of traditional .net projects. They don't read or parse csproj files. This is done to keep them cross platform and cross IDE compatible (csproj is a distinctly windows and VS specific thing).
When you add a reference to a "legacy" (I use legacy to mean a .net 4.x csproj based project) behind the scenes the IDE will run dnu wrap but it looks like in your case something broke.
The following should be done automatically.
In solution root global.json a folder "wrap" should be added to the
projects property.
A folder off the root named "wrap" will be created if it doesn't exist.
A /wrap/project.json will be created/updated with a path to the assembly (dll).
Add a reference to the assembly and version to the referencing project's project.json file.
So first thing to check is make sure you have a "wrap" folder and wrap reference in projects property of solution.json. If you don't then likely something "broke". Try removing the reference rebuilding and adding the reference back. Check the build output window for any errors (VS is still RC so there are something error which probably should be halting that are not).
Look for a project.json in the wrap folder. It should look something like this:
{
"version": "1.0.0-*",
"frameworks": {
"net452": {
"wrappedProject": "../../LegacyClassLibrary/LegacyClassLibrary.csproj",
"bin": {
"assembly": "../../LegacyClassLibrary/obj/{configuration}/LegacyClassLibrary.dll",
"pdb": "../../LegacyClassLibrary/obj/{configuration}/LegacyClassLibrary.pdb"
}
}
}
}
Note the framework version. If there is a mismatch then it will fail resolving the dependencies. For example if your MySolution.Models targets .Net 4.6 and thus when wrapped has a dnx46 framework reference but your MySolution.Server project has a reference to dnx452 (in the project.json for MySolution.Server) then it will fail when resolving the dependency to MySolution.Models.
The you quoted could probably be improved. It means that it could not resolve the dependency due to one of the following reasons
It could not find a MySolution.Models assembly (either source code or compiled dll) based on the paths it uses (starting from projects parameter in global.json).
It found a MySolution.Models assembly (either source code or compiled) BUT it was an invalid version. Check version in Models project vs the reference in Server project.json.
It found a MySolution.Models assembly but it can't resolve framework dependencies (i.e. Models requires dnx46 but Server only targets dnx452).
In my experience the third one if the most common. For the DNX templates in VS 2015 RC the default full framework being targeted is dnx452 (or is it dnx451?). New csproj projects will be 4.6 (dnx46) by default and existing projects could be just about anything.
An alternative solution:
I have found the following alternative to result in easier dependency management. If MySolution.Models will only be used by DNX projects then just convert it to a DNX project move it into the source folder and reference it directly. It will be part of the source compilation and you gain the benefits of dynamic compilation.
If MySolution.Models will be referenced by both DNX and legacy (csproj) projects then you can create a side-by-side xproj and project.json files for Models. They will be ignored by the legacy project. In essence you have both a legacy and DNX project using the same source files. You can then just like above reference it directly. Keep in mind the folder structure if the models folder is not under /src (and it probably isn't if this was an existing project) then you will either need to move it or add a reference to the folder in global.json. That sounded more confusing that it really is. Just keep in mind for a DNX project the global.json defines the relative paths to where DNX can find source code. The DNX also can resolve dependencies by nuget or searching the GAC but that is beyond what you are trying to do.

Derived types must either match the security accessibility of the base type or be less accessible

I upgraded my MVC 4 app to MVC 5 a couple of days ago following these instructions and now I'm getting the following error. I updated DotNetOpenAuth to the latest bits using Nuget (v4.3.3.13295) but it still throws this error.
How do I fix this?
Inheritance security rules violated by type:
'DotNetOpenAuth.Messaging.OutgoingWebResponseActionResult'. Derived
types must either match the security accessibility of the base type or
be less accessible.
Solved this finally. Turned out that I needed to make some changes to the source code of DotNetOpenAuth and re-compile it. This wasn’t easy at all since the source code won’t compile after downloading from github. I had to spend ~3 days trying various things and learning the build system meshed into DotNetOpenAuth’s project files until I finally got it to compile. Seems the author of this project has abandoned it. See more about this issue here.
Download the 4.3 code base using this command line: git clone -b v4.3 https://github.com/DotNetOpenAuth/DotNetOpenAuth.git
Edit the /src/version.txt and change it to 4.4.0. This makes this version higher than the official Nuget release so that installing Nuget packages don’t attempt to install old versions of DotNetOpenAuth assemblies from its repository.
Remove all instances of the following string from all AssemblyInfo.cs files under the /src/ directory.
[assembly: AllowPartiallyTrustedCallers]
I had to mess around with the Microsoft.Contracts reference in two projects and point it to /tools/Contracts/PublicAssemblies/v3.5/Microsoft.Contracts.dll and then use a using alias to get classes from this assembly to resolve properly. A few Requires.NotNull() lines refused to compile so I just commented them out… c'est la vie..
Run the following command to skip verification of these assemblies: sn.exe -Vr *,2780ccd10d57b246
Once the assemblies were built I referenced those, re-added Microsoft.AspNet.WebPages.OAuth 3.0 from Nuget, rebuilt my solution, and finally my app is up and running on MVC 5.

How to set version and build number from build server and also update an assembly with this version?

I would like to create a setup project based on WiX which does the following (as well as creating the installation package):
callable from msbuild running on a CI build server (Hudson)
take a version number from some asset in either the setup project or the main assembly
take the current build number from the CI system
create a full product version number [version].[build] such as 1.3.432
store this value in an asset (e.g. the main assembly) is such a way that it can be read out at run time and displayed on the splash window
I have tried a number of approaches and googled a lot but have not found a workable solution. Can anyone help?
The WiX toolset does this by creating a version.cs, a version.h and a version.wxi during the MSBuild then including those files in all the projects. That way our executable can print out their version when you run something like candle.exe -? and all of the bundles and .msi packages have their versions set correctly.
You can see how we do this in tools\WixBuild.Version.targets (here). It would straight forward to override the properties in WixBuild.Version.targets with properties passed via the command-line to MSBuild via Hudson if you wanted.