stazz / utilpack Goto Github PK

Dear @stazz,

In first, I wish you a Happy New Year!

Can you change here: https://github.com/stazz/UtilPack/blob/develop/Source/UtilPack.Cryptography.SASL.SCRAM/README.md

1/ "This is library implementing SCRAM-(SHA128|256|512) protocol without dynamically allocating any strings. The SCRAM protocol handlers are accessible via extension methods for BlockDigestAlgorithm interface of UtilPack.Cryptography.Digest project."
by
"This is library implementing SCRAM-(SHA-1|SHA-256|SHA-512) protocol without dynamically allocating any strings. The SCRAM protocol handlers are accessible via extension methods for BlockDigestAlgorithm interface of UtilPack.Cryptography.Digest project."

2/ "// Example of using SCRAM-SHA256"
by
"// Example of using SCRAM-SHA-256"

Here too:

• https://www.nuget.org/packages/UtilPack.Cryptography.SASL.SCRAM/

And in current nuget topics:
"utility cryptography sasl scram sha-128 sha-256 sha-512 digest hash"
by
"utility cryptography sasl scram scram-sha-1 scram-sha-256 scram-sha-512 sha-1 sha-256 sha-512 digest hash"

Thanks in advance.

Dear @stazz,

In first, I wish you a Happy New Year!

Can you add in this repository, topics?

• scram
• scram-sha-1
• scram-sha-256
• scram-sha-512

Thanks in advance.

Linked to:

• scram-sasl/info#1

Hi again!
In the README - this bit:

The UsingTask element should have its Condition, TaskFactory and AssemblyFile attributes always the same. By default, the only customizable attribute should be TaskName, which should be the full type name of the task to execute.

Would you mind clarifying the "full type name" bit for me?

Is this:

1. The assembly qualified, type name? i.e Foo.Bar.DoStuffTask, Foo
2. The namespace qualified type name, without assembly qualification? i.e Foo.Bar.DoStuff
3. The type name, without namespace or assembly: DoStuff

The .NET Core Global Tools are out there for a while, and their idea looks good. It should be investigated whether the UtilPack.NuGet.MSBuild project (and probably few others) could be published as a global tool.

I created a legacy csharp project that has packages.config file for managing nuget packages.

After adding a nuget package that has a util pack task factory task in and building:

Severity	Code	Description	Project	File	Line	Suppression State
Error		The "self" package ID is not supported when the caller file of this task factory is not in local repositories: C:\Users\Darrell\.nuget\packages\.	ClassLibrary5		

I think this is because the nuget packages in this instance are located in a local packages directory..

Currently, there is no standardized way of distribute tasks relying on UtilPack.NuGet.MSBuild task factory.
So far, UtilPack.NuGet.MSBuild task factory has been used by very small group of people (me and couple others), and the way of using UtilPack.NuGet.MSBuild task factory has been to manually add PackageReference to UtilPack.NuGet.MSBuild (directly to .csproj or to proxy .build/.targets file, if one would like to eliminate Pack task to automatically create dependency to UtilPack.NuGet.MSBuild package), and then, also manually, add the UsingTask directives.
However, this is obviously not a very long-term solution, since one can not assume that every user of the task has required knowledge and time to manually edit project files.

Ideally, to achieve best end-user experience, it would be enough to simply add NuGet reference to package containing the custom task.
The rest is, for the consumer point of view, technical implementation details - as long as no extra "polluting" references are added to the build artifacts.

Therefore, there are two requirements:

• One NuGet package reference to the custom task package should be enough, and
• that reference should not add any new references to consumer project.

The @dazinator pointed out in #6 that situation fulfilling both of these requirements would be achieved by having two NuGet packages: one to be added by consumer project, and other that would be restored and executed by UtilPack.NuGet.MSBuild task factory.

However, while easy for consumer, this adds quite a lot of overhead and plumbing code for developers of the tasks.
There is another way, which is not entirely free of overhad and plumbing code, but requires only one NuGet package.

Consider the following structure of example NuGet package, let's call it MyExamplePackage:

• build folder, with
  • MyExamplePackage.targets file,
  • functionality folder, with
    • Functionality.targets file
• lib folder, with
  • netstandard1.3 folder, with
    • MyExamplePackage.dll assembly, containing our custom task

The contents of build/MyExamplePackage.targets file would be:

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <!-- Hook into build process of consumer package. The exact logic for this varies depending on what kind of functionality this package provides, but let's use this as an example. -->
  <PropertyGroup>
    <BuildDependsOn>
      MyExamplePackageBuild;
      $(BuildDependsOn);
    </BuildDependsOn>
  </PropertyGroup>
  
  <!-- Properties containing paths to functionality files and directories. -->
  <PropertyGroup>
    <MyExamplePackage_FunctionalityDir>$(MSBuildThisFileDirectory)/functionality</MyExamplePackage_FunctionalityDir>
    <MyExamplePackage_FunctionalityFile>$(MyExamplePackage_FunctionalityDir)/Functionality.targets</MyExamplePackage_FunctionalityFile>
    <MyExamplePackage_FunctionalityObjFolder>$(MyExamplePackage_FunctionalityDir)/obj</MyExamplePackage_FunctionalityObjFolder>
  </PropertyGroup>

  
  <!-- This target gets called when consumer project is built. -->
  <Target Name="MyExamplePackageBuild">
    <!-- Restore infrastructure stuff, if not done already. -->
    <CallTarget
      Condition="!Exists('$(MyExamplePackage_FunctionalityObjFolder)')"
      Targets="MyExamplePackageBuild_RestoreInfrastructure"
      />
      
    <!-- Now do actual stuff. -->
    <CallTarget
      Targets="MyExamplePackageBuild_CallFunctionality"
      />
  </Target>
  
  <!-- This target gets called by MyExamplePackageBuild, if necessary -->
  <Target Name="MyExamplePackageBuild_RestoreInfrastructure">
    <!-- We are going to call MSBuild via Exec (because doing this directly via MSBuild task does not (yet?) work properly) -->
    <PropertyGroup Condition=" '$(MSBuildExecCMD)' == '' ">
      <MSBuildExecCMD Condition=" '$(MSBuildRuntimeType)' == 'Core' ">dotnet msbuild</MSBuildExecCMD>
      <MSBuildExecCMD Condition=" '$(MSBuildRuntimeType)' != 'Core' ">"$(MSBuildBinPath)\MSBuild.exe"</MSBuildExecCMD>
    </PropertyGroup>
    
    <!-- Restore Functionality.targets file -->
    <Exec
      Command="$(MSBuildExecCMD) /t:Restore &quot;$(MyExamplePackage_FunctionalityFile)&quot;"
      />
  </Target>
  
  <!-- This target gets called by MyExamplePackageBuild, always. -->
  <Target Name="MyExamplePackageBuild_CallFunctionality">
    <!-- The functionality/Functionality.targets file is now restored, so we can call MSBuild directly on it. -->
    <MSBuild
      Projects="$(MyExamplePackage_FunctionalityFile)"
      Targets="PerformFunctionality"
      UnloadProjectsOnCompletion="true"
      />
  </Target>
</Project>

The contents of build/functionality/Functionality.targets file could be something like this:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <!-- This is required, otherwise MSBuild will end up in error. -->
    <TargetFramework>netstandard1.0</TargetFramework>
  </PropertyGroup>
  
  <!-- A reference to UtilPack.NuGet.MSBuild task factory. -->
  <ItemGroup>
    <PackageReference Include="UtilPack.NuGet.MSBuild" Version="1.1.3" />
  </ItemGroup>
  
  <!-- UsingTask directive. -->
  <UsingTask
    Condition=" '$(UtilPackNuGetMSBuildAssemblyPath)' != '' "
    TaskFactory="UtilPack.NuGet.MSBuild.NuGetTaskRunnerFactory"
    AssemblyFile="$(UtilPackNuGetMSBuildAssemblyPath)"
    TaskName="MyExamplePackage.Tasks.MyExamplePackageTask"
  >
    <Task>
      <NuGetTaskInfo>
        <PackageID>MyExamplePackage</PackageID>
        <PackageVersion>1.0.0</PackageVersion>
      </NuGetTaskInfo>
    </Task>
  </UsingTask>
  
  <Target Name="PerformFunctionality">
    <!-- This target will get called by build/MyExamplePackage.targets file. -->
    <!-- Execute our custom task. -->
    <MyExamplePackage.Tasks.MyExamplePackageTask
      Prefix="Hello"
      />
  </Target>
</Project>

The build flow would be something like this:

1. The build/MyExamplePackage.targets file would hook itself into build process, and cause execution of MyExamplePackageBuild target.
2. On initial build, the MyExamplePackageBuild target detects the non-existance of build/functionality/obj folder, causing build/functionality/Functionality.targets file to be restored.
   • Restoring that file causes creation of build/functionality/obj folder, holding all required info related to e.g. UtilPack.NuGet.MSBuild task factory (as it was referenced in build/functionality/Functionality.targets file via PackageReference).
3. On next builds, the restore would be skipped, as everything should be ready anyway.
4. Then, the PerformFunctionality target in build/functionality/Functionality.targets file would get executed. This target causes UtilPack.NuGet.MSBuild to execute MyExamplePackage.Tasks.MyExamplePackageTask task in MyExamplePackage (this package).
5. The UtilPack.NuGet.MSBuild will load the lib/netstandard1.3/MyExamplePackage.dll file, search for MyExamplePackage.Tasks.MyExamplePackageTask type there, and execute it as MSBuild task.

As a result, both requirements mentioned above would be satisfied: consumer needs to just add reference to custom task NuGet package, and as a result, no extra references are added to consumer project.

I'll add some kind of template project, for testing and demonstrating purposes, once I get it done.

Some builds invoke the UtilPack.NuGet.MSBuild task factory several times for one build, or even just for one framework. If the amount of NuGet restores resulting because of this could be reduced, there would be significant speed improvement for such builds.

Things to consider:

• Most likely this should be done via methods in IBuildEngine4 interface. One could cache the BoundRestoreCommandUser instance which knows about all previously restored packages.
• The dynamic loading callbacks to tasks should probably use some kind of "child" instances of BoundRestoreCommandUser instead.

Build the consumer project here for netstandard1.6 using a global.json file to lock the sdk to version 1.1.0.
This outputs build error:

C:\Users\darre\.nuget\packages\utilpack.nuget.msbuild.sample\1.0.2\build\functionality\Functionality.targets(31,6): error MSB4175: The task factory "UtilPack.NuGet.MSBuild.NuGetTaskRunnerFactory" could not be loaded from the assembly "C:\Users\darre\.nuget\packages\utilpack.nuget.msbuild\1.1.4\build\\netcoreapp1.1\UtilPack.NuGet.MSBuild.dll". Could not load file or assembly 'System.ValueTuple, Version=4.0.1.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. Could not find or load a specific file. (Exception from HRESULT: 0x80131621)

When attempting to build the following project using .NET Core SDK 2.0 it fails due to what appears to be missing function implementations in an updated interface:

Project:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <VersionPrefix>1.0.0</VersionPrefix>
    <TargetFramework>netstandard1.6</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="UtilPack.NuGet.MSBuild" Version="1.0.1"/>
  </ItemGroup>

  <UsingTask
    Condition=" '$(UtilPackNuGetMSBuildAssemblyPath)' != '' "
    TaskFactory="UtilPack.NuGet.MSBuild.NuGetTaskRunnerFactory"
    AssemblyFile="$(UtilPackNuGetMSBuildAssemblyPath)"
    TaskName="UtilPack.NuGet.Push.MSBuild.PushTask">
    <Task>
      <NuGetTaskInfo>
        <PackageID>UtilPack.NuGet.Push.MSBuild</PackageID>
        <PackageVersion>1.0.0</PackageVersion>
      </NuGetTaskInfo>
    </Task>
  </UsingTask>

  <Target Name="PushTest" AfterTargets="Pack">
    <UtilPack.NuGet.Push.MSBuild.PushTask
      PackageFilePath="$(PackageOutputPath)/$(AssemblyName).$(VersionPrefix).nupkg"
    />
  </Target>

</Project>

$ dotnet --version
2.0.0

$ dotnet msbuild
Microsoft (R) Build Engine version 15.3.409.57025 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

$ dotnet msbuild /target:Pack
Microsoft (R) Build Engine version 15.3.409.57025 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  Test -> bin\Debug\netstandard1.6\Test.dll
  Successfully created package 'bin\Debug\Test.1.0.0.nupkg'.
Test.csproj(26,5): error MSB4175: The task factory
"UtilPack.NuGet.MSBuild.NuGetTaskRunnerFactory" could not be loaded from the assembly
"~\.nuget\packages\utilpack.nuget.msbuild\1.0.1\build\\netcoreapp1.1\UtilPack.NuGet.MSBuild.dll".
Method 'Log' in type 'UtilPack.NuGet.Common.MSBuild.NuGetMSBuildLogger' from assembly
'UtilPack.NuGet.MSBuild, Version=1.0.0.0, Culture=neutral, PublicKeyToken=6b85dda6d85690de'
does not have an implementation.

It appears that ILogger was changed to include some new methods:

https://github.com/NuGet/NuGet.Client/blame/dev/src/NuGet.Core/NuGet.Common/Logging/ILogger.cs

Hi.

Applied the VS 15.6.1 update. This has bumped dotnet sdk to:

dotnet --version
2.1.100

It appears there have been some nuget changes which has broken the task factory :-)

Repro here: https://github.com/dazinator/gitversion_pr1269

1. Build within VS works fine.
2. Build with dotnet build using 2.1.100 (latest) version of the sdk gives:

PS E:\Repos\gitversion_pr1269\src> git status
On branch master
Your branch is up to date with 'origin/master'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   repro/repro.csproj

no changes added to commit (use "git add" and/or "git commit -a")
PS E:\Repos\gitversion_pr1269\src> dotnet build
Microsoft (R) Build Engine version 15.6.82.30579 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  Restore completed in 57.11 ms for E:\Repos\gitversion_pr1269\src\repro\repro.csproj.
MSBUILD : Task factory warning NMSBT010: There is a mismatch between SDK NuGet version (4.6.0) and the NuGet version the task factory was compiled against (4.5.0). There might occur some exotic errors. [E:\Repos\gitversion_pr1269\src\repro\repro.csproj]
MSBUILD : Task factory error NMSBT001: Exception in initialization: System.TypeLoadException: Could not load type 'NuGet.Protocol.LocalNuspecCache' from assembly 'NuGet.Protocol, Version=4.6.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. [E:\Repos\gitversion_pr1269\src\repro\repro.csproj]
MSBUILD : Task factory error NMSBT001:    at UtilPack.NuGet.BoundRestoreCommandUser..ctor [E:\Repos\gitversion_pr1269\src\repro\repro.csproj]
MSBUILD : Task factory error NMSBT001:    at UtilPack.NuGet.MSBuild.NuGetTaskRunnerFactory.Initialize(String taskName, IDictionary`2 parameterGroup, String taskBody, IBuildEngine taskFactoryLoggingHost) [E:\Repos\gitversion_pr1269\src\repro\repro.csproj]
C:\Users\Daz\.nuget\packages\gitversiontask\4.0.0-pullrequest1269-1526\build\functionality\GitVersionBuild.targets(7,5): error MSB4175: The task factory "UtilPack.NuGet.MSBuild.NuGetTaskRunnerFactory" could not be loaded from the assembly "C:\Users\Daz\.nuget\packages\utilpack.nuget.msbuild\2.3.0\build\\netcoreapp1.1\UtilPack.NuGet.MSBuild.dll". Object reference not set to an instance of an object. [E:\Repos\gitversion_pr1269\src\repro\repro.csproj]

Build FAILED.

MSBUILD : Task factory warning NMSBT010: There is a mismatch between SDK NuGet version (4.6.0) and the NuGet version the task factory was compiled against (4.5.0). There might occur some exotic errors. [E:\Repos\gitversion_pr1269\src\repro\repro.csproj]
MSBUILD : Task factory error NMSBT001: Exception in initialization: System.TypeLoadException: Could not load type 'NuGet.Protocol.LocalNuspecCache' from assembly 'NuGet.Protocol, Version=4.6.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. [E:\Repos\gitversion_pr1269\src\repro\repro.csproj]
MSBUILD : Task factory error NMSBT001:    at UtilPack.NuGet.BoundRestoreCommandUser..ctor [E:\Repos\gitversion_pr1269\src\repro\repro.csproj]
MSBUILD : Task factory error NMSBT001:    at UtilPack.NuGet.MSBuild.NuGetTaskRunnerFactory.Initialize(String taskName, IDictionary`2 parameterGroup, String taskBody, IBuildEngine taskFactoryLoggingHost) [E:\Repos\gitversion_pr1269\src\repro\repro.csproj]
C:\Users\Daz\.nuget\packages\gitversiontask\4.0.0-pullrequest1269-1526\build\functionality\GitVersionBuild.targets(7,5): error MSB4175: The task factory "UtilPack.NuGet.MSBuild.NuGetTaskRunnerFactory" could not be loaded from the assembly "C:\Users\Daz\.nuget\packages\utilpack.nuget.msbuild\2.3.0\build\\netcoreapp1.1\UtilPack.NuGet.MSBuild.dll". Object reference not set to an instance of an object. [E:\Repos\gitversion_pr1269\src\repro\repro.csproj]
    1 Warning(s)
    2 Error(s)

Time Elapsed 00:00:01.68
PS E:\Repos\gitversion_pr1269\src>

What title says. The .NET Core 2.1 was recently released, and one needs to add auto-detection code for it in relevant UtilPack NuGet project.

Currently, UtilPack.NuGet.MSBuild is caching the restore results using in-process static dictionary. This kind of caching doesn't work efficiently for parallel builds, and doesn't work at all completely different build runs.

In order to more efficiently cache the restore results, a disk cache must be implemented. That would involve most likely just writing the .lock file (as .deps.json format) somewhere. The path must include package id, package version, and target framework.

Hello!

I am not sure if this is a utilpack issue or a VS issue.

Here is a repro csproj file, you may need to add the appveyor nuget feed: https://ci.appveyor.com/nuget/gitversion-8nigugxjftrw to restore.

<Project Sdk="Microsoft.NET.Sdk">

   <PropertyGroup>
      <TargetFramework>net46</TargetFramework>
  </PropertyGroup> 
  
  <ItemGroup>
       
    <PackageReference Include="GitVersionTask" Version="4.0.0-beta0015">
      <PrivateAssets>all</PrivateAssets>
    </PackageReference>
  </ItemGroup> 


</Project>

And a global.json:

{
  "sdk": {
    "version": "2.0.0"
  }
}

dotnet build seems to succeed, and I see the restore happening as well, and the task runs ok.

However building from VS 2017 Community (15.8.2) fails:

Target "GetVersion" in file "C:\Users\darre.nuget\packages\gitversiontask\4.0.0-beta0015\build\functionality\GitVersionBuild.targets":
1> Initializing task factory "UtilPack.NuGet.MSBuild.NuGetTaskRunnerFactory" from assembly "C:\Users\darre.nuget\packages\utilpack.nuget.msbuild\2.6.0\build\net45\UtilPack.NuGet.MSBuild.dll".
1> Detected current NuGet framework to be ".NETFramework,Version=v4.6.1", with RID "win10-x86", and local repositories: C:\Users\darre.nuget\packages.
1> [NuGet Minimal]: Restoring packages for C:\Users\darre\AppData\Local\Temp\rrucvajc.g0q\dummy...
1> [NuGet Verbose]: Restoring packages for .NETFramework,Version=v4.6.1...
1> [NuGet Verbose]: Resolving conflicts for .NETFramework,Version=v4.6.1...
1> [NuGet Verbose]: Checking compatibility of packages on .NETFramework,Version=v4.6.1.
1> [NuGet Debug]: Checking compatibility for Restoring: (GitVersionTask, [4.0.0-beta0015, )) 1.0.0 with .NETFramework,Version=v4.6.1.
1> [NuGet Debug]: Checking compatibility for GitVersionTask 4.0.0-beta0015 with .NETFramework,Version=v4.6.1.
1> [NuGet Debug]: Checking compatibility for UtilPack.NuGet.MSBuild 2.6.0 with .NETFramework,Version=v4.6.1.
1> [NuGet Verbose]: All packages and projects are compatible with .NETFramework,Version=v4.6.1.
1> Using "WriteVersionInfoToBuildLog" task from the task factory "NuGetTaskRunnerFactory".
1> Task "WriteVersionInfoToBuildLog"
1> Task Parameter:SolutionDirectory=C:\Users\darre\Documents\Visual Studio 2017\Projects\ClassLibrary7
1> Task Parameter:NoFetch=false
1> Resolved GitVersionTask, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null located in C:\Users\darre.nuget\packages\gitversiontask\4.0.0-beta0015\build\net461\GitVersionTask.dll and loaded from same path.
1> Resolved Microsoft.Build, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a located in C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.Build.dll and loaded from same path.
1> Resolved Microsoft.Build, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a located in C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.Build.dll and loaded from same path.
1> MSBUILD : error MSB4166: Child node "2" exited prematurely. Shutting down. Diagnostic information may be found in files in "C:\Users\darre\AppData\Local\Temp" and will be named MSBuild_*.failure.txt. This location can be changed by setting the MSBUILDDEBUGPATH environment variable to a different directory.
1> Using "GetVersion" task from the task factory "NuGetTaskRunnerFactory".
1> Task "GetVersion"
1> Task Parameter:SolutionDirectory=C:\Users\darre\Documents\Visual Studio 2017\Projects\ClassLibrary7
1> Task Parameter:NoFetch=false
1> Done executing task "GetVersion" -- FAILED.
1> Done building target "GetVersion" in project "ClassLibrary7.csproj" -- FAILED.

As per the above, I found the MSBuild_*.failure.txt file, and this is its contents:

UNHANDLED EXCEPTIONS FROM PROCESS 20896:
=====================
29/08/2018 00:21:44
System.ArgumentNullException: Value cannot be null.
Parameter name: value
at System.IO.BinaryWriter.Write(String value)
at Microsoft.Build.Framework.LazyFormattedBuildEventArgs.WriteToStream(BinaryWriter writer)
at Microsoft.Build.Framework.BuildMessageEventArgs.WriteToStream(BinaryWriter writer)
at Microsoft.Build.Shared.LogMessagePacketBase.WriteToStream(INodePacketTranslator translator)
at Microsoft.Build.Shared.LogMessagePacketBase.Translate(INodePacketTranslator translator)
at Microsoft.Build.BackEnd.NodeEndpointOutOfProcBase.RunReadLoop(Stream localReadPipe, Stream localWritePipe, ConcurrentQueue`1 localPacketQueue, AutoResetEvent localPacketAvailable, AutoResetEvent localTerminatePacketPump)
===================

UtilPack Variables:

UtilPackNuGetMSBuildAssemblyPath = C:\Users\darre.nuget\packages\utilpack.nuget.msbuild\2.6.0\build\net45\UtilPack.NuGet.MSBuild.dll
1>UtilPackNuGetMSBuildPropsAbsolutePath = C:\Users\darre.nuget\packages\utilpack.nuget.msbuild\2.6.0\build\UtilPack.NuGet.MSBuild.props
1>UtilPackNuGetMSBuildPropsPath = C:\Users\darre.nuget\packages\gitversiontask\4.0.0-beta0015\build../../../utilpack.nuget.msbuild/2.6.0/build/UtilPack.NuGet.MSBuild.props
1>UtilPackNuGetMSBuildToolsRootPath = C:\Users\darre.nuget\packages\utilpack.nuget.msbuild\2.6.0\build\
1>UtilPackNuGetMSBuildToolsSubPath = net45
1>UtilPackTaskFactoryParametersXML =
1>

  <NuGetFramework xmlns="http://schemas.microsoft.com/developer/msbuild/2003">.NETFramework</NuGetFramework><NuGetFrameworkVersion xmlns="http://schemas.microsoft.com/developer/msbuild/2003">4.6.1</NuGetFrameworkVersion>
1>      <PackageIDIsSelf xmlns="http://schemas.microsoft.com/developer/msbuild/2003">true</PackageIDIsSelf><AssemblyPath xmlns="http://schemas.microsoft.com/developer/msbuild/2003">GitVersionTask.dll</AssemblyPath>

1>UtilPackVersion = 2.6.0

MSVS 15.5 is out and so is NuGet 4.5 in .NET Core SDK. One should update the UtilPack.NuGet.MSBuild project to NuGet 4.5.

As per: #19
It looks like MsBuild have incremented their NuGet dependency and it has a breaking change this time:

If I'm more specific then microsoft/dotnet:2.1.403-sdk works (with warning) but microsoft/dotnet:2.1.500-sdk fails with the error.

Error is:

MSBUILD : Task factory warning NMSBT010: There is a mismatch between SDK NuGet version (4.9.0) and the NuGet version the task factory was compiled against (4.8.0). There might occur some exotic errors. [/app/example.serialisation/example.serialisation.fsproj] MSBUILD : Task factory error NMSBT001: Exception in initialization: System.MissingMethodException: Method not found: 'Void NuGet.Commands.RestoreRequest..ctor(NuGet.ProjectModel.PackageSpec, NuGet.Commands.RestoreCommandProviders, NuGet.Protocol.Core.Types.SourceCacheContext, NuGet.Common.ILogger)'. [/app/example.serialisation/example.serialisation.fsproj]

Currently, if there exists e.g. UtilPack.NuGet.MSBuild.NuGet.4.4.0.dll assembly in .NET Core folder, the UtilPack.NuGet.MSBuild.dll assembly won't use it when loaded in NuGet 4.5.0 environment. This should be fixed (and a warning emitted when there is no exact match).

I have been testing a little more and have just found an issue that is puzzling me a little..

The task factory breaks if I use multi-targeting with more than one target framework specified.

For example - building with either of these and the task factory works:

• <TargetFrameworks>netcoreapp2.0</TargetFrameworks>
• <TargetFrameworks>netstandard1.3</TargetFrameworks>

However when I do this:

<TargetFrameworks>netstandard1.3;netcoreapp2.0</TargetFrameworks>

I get the following build errors:

Severity Code Description Project File Line Suppression State
Error NMSBT001 Exception in initialization: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.IO.FileNotFoundException: Could not load file or assembly 'GitVersionCore, Version=4.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
at GitVersionTask.WriteVersionInfoToBuildLog..ctor()
--- End of inner exception stack trace ---
at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at UtilPack.NuGet.MSBuild.TaskReferenceCreator.CreateTaskReferenceHolder(String taskTypeName, NuGetAssemblyResolver resolver, String packageID, String packageVersion, String assemblyPath, String msbuildFrameworkAssemblyName, ResolverLogger logger)
at UtilPack.NuGet.MSBuild.TaskReferenceCreator.CreateTaskReferenceHolder(String taskTypeName, NuGetAssemblyResolver resolver, String packageID, String packageVersion, String assemblyPath, String msbuildFrameworkAssemblyName, ResolverLogger logger)
at UtilPack.NuGet.MSBuild.NuGetTaskRunnerFactory.CreateExecutionHelper(String taskName, XElement taskBodyElement, String taskPackageID, String taskPackageVersion, String taskAssemblyFullPath, String taskAssemblyPathHint, BoundRestoreCommandUser restorer, ResolverLogger resolverLogger, GetFileItemsDelegate getFiles, String assemblyCopyTargetFolder, AppDomainSetup& appDomainSetup)
at UtilPack.NuGet.MSBuild.NuGetTaskRunnerFactory.<>c__DisplayClass30_3.b__3()
at System.Lazy1.CreateValue() at System.Lazy1.LazyInitValue()
at System.Lazy1.get_Value() at UtilPack.ReadOnlyResettableLazy1.get_Value()
at UtilPack.NuGet.MSBuild.NuGetTaskRunnerFactory.Initialize(String taskName, IDictionary`2 parameterGroup, String taskBody, IBuildEngine taskFactoryLoggingHost) repro 1
Error MSB4175 The task factory "UtilPack.NuGet.MSBuild.NuGetTaskRunnerFactory" could not be loaded from the assembly "C:\Users\Daz.nuget\packages\utilpack.nuget.msbuild\2.4.0\build\net45\UtilPack.NuGet.MSBuild.dll". Exception has been thrown by the target of an invocation. repro C:\Users\Daz.nuget\packages\gitversiontask\4.0.0-pullrequest1269-1530\build\functionality\GitVersionBuild.targets 6

There is a branch here for repro: https://github.com/dazinator/gitversion_pr1269/tree/issue

It's me again! With a question!

I am trying to use UtilPack in the open source project GitVersionTask: GitTools/GitVersion#1269
It has some targets defined like this:

<Target Name="GenerateGitVersionInformation" BeforeTargets="CoreCompile" Condition="$(GenerateGitVersionInformation) == 'true'">
    <GenerateGitVersionInformation
    SolutionDirectory="$(GitVersionPath)"
    NoFetch="$(GitVersion_NoFetchEnabled)"
    ProjectFile="$(MSBuildProjectFullPath)"
    IntermediateOutputPath="$(IntermediateOutputPath)"
    Language="$(Language)">
      <Output
        TaskParameter="GitVersionInformationFilePath"
        PropertyName="GitVersionInformationFilePath" />
    </GenerateGitVersionInformation>

    <ItemGroup>
      <Compile Include="$(GitVersionInformationFilePath)" />
      <FileWrites Include="$(GitVersionInformationFilePath)" />
    </ItemGroup>
  </Target>

Two things about these targets:

1. The target uses a BeforeTargets attribute to run at the appropriate point in a build.
2. The target uses a Condition attribute so that it doesn't run in certain circumstances.

I think the way to proxy them from an infrastructure.targets would be something like the following - would you agree?

<Target Name="Proxy_GenerateGitVersionInformation" BeforeTargets="CoreCompile" Condition="$(GenerateGitVersionInformation) == 'true'">

 <CallTarget
      Condition=" '$(GitVersionTaskBuildTools_CanCallDirectly)' == 'true' "
      Targets="Proxy_GenerateGitVersionInformation"
      />

  </Target>

So I basically:

1. Copied the target definition into infrastructure.targets, keeping the same BeforeTargets and Condition
2. Because the condition uses an msbuild property, I have had to move the definition of that property accross from the original targets into the infrastructure.targets file.
3. The target in infrastructure.targets was renamed, and its body replaced to CallTarget on the original target.

Does this sound like a sensible approach?

The RestoreRequest and PackageSpec classes used by UtilPack's BoundRestoreCommandUser expect a path into their RestoreOutputPath and FilePath properties, respectively. If the path is not provided, then the restore will fail with an exception. Currently BoundRestoreCommandUser provides a path which is simply Path.Combine( Path.GetTempPath(), Path.GetRandomFileName() ).

However, for users not aware of this small detail related to behaviour of NuGet framework, the resulting logging output ( Restoring packages for C:\Users\<user>\AppData\Local\Temp\cq1j4wka.ihq\dummy) can be a bit misleading.

The path for given to RestoreOutputPath and FilePath properties by BoundRestoreCommandUser should be customizable. Then, the UtilPack.NuGet.MSBuild task factory could pass something more appropriate there (e.g. ProjectDir + "not_in_use" or something like that).

Hi,
How can I import and use your custom task? Could you provide a working example?
I'm getting an error
"The task factory "UtilPack.NuGet.MSBuild.NuGetTaskRunnerFactory" could not be loaded from the assembly "$(SolutionDir)packages\UtilPack.NuGet.MSBuild.2.3.0\build\net45\UtilPack.NuGet.MSBuild.dll"
win10, vs2017

So I have noticed the following issue!

I have a very simple repro project, that consumes GitVersionTask
I have created multiple branches, in each branch I have amended the project to target a particular target framework/s. The name of the branch is named after the target frameworks that the project is targeting.
These branches all build on appveyor.

I have found that in some scenarios, the task does not run.

You can see all the relevant builds here: https://ci.appveyor.com/project/dazinator/gitversion-pr1269/history

So what is interesting is that the task doesn't seem to run until the consumer project is targeting atleast netstandard1.5 or a platform that is compatible with netstandard1.5 (i.e netcoreapp20).

I think this is down to the fact that the GitVersionTask nuget package has the following in its nuspec:

<dependencies>
      <group targetFramework=".NETStandard1.5">
         <dependency id="UtilPack.NuGet.MSBuild" version="$utilpackversion$" exclude="Build,Analyzers" />
         <dependency id="GitTools.Core" version="$gittoolscoreversion$" exclude="Build,Analyzers" />
         <dependency id="YamlDotNet" version="$yamldotnetversion$" exclude="Build,Analyzers" />        
      </group>
      <group targetFramework=".NETFramework4.6.1">
         <dependency id="UtilPack.NuGet.MSBuild" version="$utilpackversion$" exclude="Build,Analyzers" />      
      </group>
    </dependencies>

The sole reason this is there is because we rely on UtilPack to use this information to know how to restore / and resolve dependencies for us prior to executing the task.
However this is a problem. By listing dependencies in the nuspec we are effectively telling MsBuild to ingore the package if te consumer is targeting an incompatible framework. This is not what we want as the tool is a build tool, it's dependency chain is fixed based on the build environment, and not the target framework that a consumer is targeting.

The good news is that this is an open source project, so you should be able to checkout and replicate this issue if you need to.

It's here: https://github.com/dazinator/GitVersion/tree/feature/netstandard which is part of an active PR.
(PR is here: GitTools/GitVersion#1269)

The solution has a project called GitVersionTask which is the msbuild task. I have updated it to use UtilPack's wonderful msbuild task factory. The issue seems to be that one of the dependencies - called libgit2sharp, has some native libraries. When I build a project with the task I get this:

Using "GetVersion" task from the task factory "NuGetTaskRunnerFactory".
1>  Task "GetVersion"
1>    Resolved GitVersionTask, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null located in C:\Users\Darrell\.nuget\packages\gitversiontask\4.0.0-alpha0001\build\net461\GitVersionTask.dll and loaded from C:\Users\Darrell\.nuget\packages\gitversiontask\4.0.0-alpha0001\build\net461\GitVersionTask.dll.
1>    Resolved Microsoft.Build.Utilities.Core, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a located in C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.Build.Utilities.Core.dll and loaded from C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.Build.Utilities.Core.dll.
1>    Resolved Microsoft.Build.Framework, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a located in C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.Build.Framework.dll and loaded from C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.Build.Framework.dll.
1>    Resolved GitVersionCore, Version=4.0.0.0, Culture=neutral, PublicKeyToken=null located in C:\Users\Darrell\.nuget\packages\gitversioncore\1.0.0\lib\net40\GitVersionCore.dll and loaded from C:\Users\Darrell\.nuget\packages\gitversioncore\1.0.0\lib\net40\GitVersionCore.dll.
1>    Resolved Microsoft.Build, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a located in C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.Build.dll and loaded from C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.Build.dll.
1>    Resolved Microsoft.Build, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a located in C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.Build.dll and loaded from C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.Build.dll.
1>    Resolved Microsoft.Build.Framework, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a located in C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.Build.Framework.dll and loaded from C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.Build.Framework.dll.
1>    Resolved GitTools.Core, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null located in C:\Users\Darrell\.nuget\packages\gittools.core\1.3.1\lib\net45\GitTools.Core.dll and loaded from C:\Users\Darrell\.nuget\packages\gittools.core\1.3.1\lib\net45\GitTools.Core.dll.
1>    Resolved LibGit2Sharp, Version=0.25.0.0, Culture=neutral, PublicKeyToken=7cbde695407f0333 located in C:\Users\Darrell\.nuget\packages\libgit2sharp\0.25.0-preview-0033\lib\net40\LibGit2Sharp.dll and loaded from C:\Users\Darrell\.nuget\packages\libgit2sharp\0.25.0-preview-0033\lib\net40\LibGit2Sharp.dll.
1>    MSBUILD : warning : WARN [10/24/17 19:11:27:28] Could not determine assembly version: System.TypeInitializationException: The type initializer for 'LibGit2Sharp.Core.NativeMethods' threw an exception. ---> System.DllNotFoundException: Unable to load DLL 'git2-15e1193': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
1>    MSBUILD : warning :    at LibGit2Sharp.Core.NativeMethods.git_libgit2_init()
1>    MSBUILD : warning :    at LibGit2Sharp.Core.NativeMethods.LoadNativeLibrary()
1>    MSBUILD : warning :    at LibGit2Sharp.Core.NativeMethods..cctor()
1>    MSBUILD : warning :    --- End of inner exception stack trace ---
1>    MSBUILD : warning :    at LibGit2Sharp.Core.NativeMethods.git_buf_free(GitBuf buf)
1>    MSBUILD : warning :    at LibGit2Sharp.Core.Handles.GitBuf.Dispose()
1>    MSBUILD : warning :    at LibGit2Sharp.Core.Proxy.ConvertPath(Func`2 pathRetriever)
1>    MSBUILD : warning :    at LibGit2Sharp.Core.Proxy.git_repository_discover(FilePath start_path)
1>    MSBUILD : warning :    at LibGit2Sharp.Repository.Discover(String startingPath)
1>    MSBUILD : warning :    at GitVersion.GitPreparer.GetDotGitDirectory()
1>    MSBUILD : warning :    at GitVersion.ExecuteCore.ExecuteGitVersion(String targetUrl, String dynamicRepositoryLocation, Authentication authentication, String targetBranch, Boolean noFetch, String workingDirectory, String commitId, Config overrideConfig, Boolean noCache)
1>    MSBUILD : warning :    at GitVersion.ExecuteCore.TryGetVersion(String directory, VersionVariables& versionVariables, Boolean noFetch, Authentication authentication)
1>  Done executing task "GetVersion".
1>Done building target "GetVersion" in project "ClassLibrary6.csproj".

I can see it ends up resolving LibGit2Sharp. This nuget package depends on LibGit2Sharp.NativeBinaries package - which looks like this:

Note, this package has the native binaries in it, under a "runtimes" folder and it also includes build files so that when you build your project, those native assemblies end up in lib folder in your output folder.

So I tried copying the lib folder containing the native directories into my nuget package containing my task - but I still get the same problem that they cannot be located.

I am not quite sure how to resolve this one. Any ideas?

What title says. Will fix for 2.2.1.

I found your msbuild task factory via: dotnet/msbuild#1756 as I was struggling to have my msbuild task loaded from a nuget package when building under netcoreapp2.0.

I notice netcoreapp2.0 isn't explicitly handled anywhere yet - does support for netcoreapp2.0 need to be added?

I'm hitting this problem when trying to build a project using the util pack task factory:

MSBUILD : Task factory error error NMSBT003: Failed to find suitable assembly in [email protected].

Same error happens for both desktop msbuild and dotnet build (2.0.0).

My nuget package folder structure looks like this:

I am placing the assemblies inside the build folder i.e build/net461 and build/netcoreapp2.0

My using task declaration is in the targets file within my nuget package (the targets file is shown in the image above) and it looks like this:

  <UsingTask
    Condition=" '$(UtilPackNuGetMSBuildAssemblyPath)' != '' "
    TaskFactory="UtilPack.NuGet.MSBuild.NuGetTaskRunnerFactory"
    AssemblyFile="$(UtilPackNuGetMSBuildAssemblyPath)"
    TaskName="DnnVsProjectSystem.BuildTools.Tasks.FindDnnManifestFile">
    <Task>
      <NuGetTaskInfo>
        <!-- This element is mandatory, and should be the package ID of the package containing MSBuild task to be executed. -->
        <PackageID>DnnVsProjectSystem.BuildTools</PackageID>

        <!-- Optionally specify the version. By default, newest will be used. Note that leaving this out will cause NuGet restore to always scan all sources. -->

        <PackageVersion>0.0.2-alpha0004</PackageVersion>

     </NuGetTaskInfo>
    </Task>
  </UsingTask>

What could I be doing wrong?

Hello!
Seen an issue when running on mono, here are the details here:

https://gist.github.com/ermshiperete/18bd905ca9155f3052dca0864a85d0da

dotnet build works fine on the same environment.

Original issue logged: GitTools/GitVersion#1460 (comment)

I think this might be a problem with the task factory not supporting mono msbuild environments, im not sure if this relates to particular versions of mono or mono in general. The linked issue describes the op's environment including mono version.

Currently, the UtilPack is not buildable in .NET Core environment. Two things needs to be fixed before this is possible:

• The IL code generation in UtilPack project needs to be done in some way supported by .NET Core (global tools? or custom msbuild task).
• The UtilPack.Cryptography project generates some source files using T4 templating language. This needs to be changed into Jinja2 or some other language, tools for which are available across platforms.

The second task is no longer relevant, as UtilPack.Cryptography now resides in FluentCryptography repository.

The first task is now done, by having a build script which uses myget.org packages (Microsoft.NETCore.ILDAsm and Microsoft.NETCore.ILAsm). The UtilPack in its current form is now completely buildable with dotnet build command.

Over the years, UtilPack project has grown a lot. Currently, there are 30 C# projects within this one repository.

It is time to start separating these projects into their own repositories, to make things more maintaineable, to speed up builds, and to better focus efforts on different areas of UtilPack. The following decomposition would be initial idea:

• UtilPack - this repository remains with
  • UtilPack,
  • UtilPack.Configuration,
  • UtilPack.Documentation,
  • UtilPack.JSON,
  • UtilPack.Logging,
  • UtilPack.MSBuild.AsyncExec,
  • UtilPack.TabularData projects.
• FluentCryptography - the repository contains
  • UtilPack.Cryptography,
  • UtilPack.Cryptography.Digest,
  • UtilPack.Cryptography.SASL, and
  • UtilPack.Cryptography.SASL.SCRAM projects.
• AsyncEnumeration - the repository contains
  • UtilPack.AsyncEnumeration project, which would be further decomposed into projects:
    • AsyncEnumeration.Abstractions
    • AsyncEnumeration.Implementation.Enumerable,
    • AsyncEnumeration.Implementation.Provider,
    • AsyncEnumeration.Observability, and
    • AsyncEnumeration.Observability.Implementation
• ResourcePooling - the repository contains
  • UtilPack.ResourePooling,
  • UtilPack.ResourePooling.ConfigurationLoading, and
  • UtilPack.ResourePooling.MSBuild projects, restructured as
    • ResourcePooling.Async.Abstractions
    • ResourcePooling.Async.ConfigurationLoading
    • ResourcePooling.Async.Implementation
    • ResourcePooling.Async.MSBuild
• NetworkUtils - the repository contains
  • UtilPack.Configuration.NetworkStream and
  • UtilPack.ResourcePooling.NetworkStream projects.
• NuGetUtils - the repository contains all of the UtilPack.NuGet.* projects, with the following structure:
  • NuGetUtils.Lib.AssemblyResolving
  • NuGetUtils.Lib.Common
  • NuGetUtils.Lib.Deployment
  • NuGetUtils.Lib.EntryPoint
  • NuGetUtils.Lib.Exec
  • NuGetUtils.Lib.MSBuild
  • NuGetUtils.Lib.Restore
  • NuGetUtils.Lib.Tool
  • NuGetUtils.MSBuild.Deployment
  • NuGetUtils.MSBuild.Exec
  • NuGetUtils.MSBuild.Exec.Release
  • NuGetUtils.MSBuild.Push
  • NuGetUtils.Tool.Deploy
  • NuGetUtils.Tool.Exec
  • NuGetUtils.Tool.Restore
• The projects UtilPack.ProcessMonitoring and UtilPack.NuGet.ProcessMonitoring are removed, as they are obsolete in a containerized world.

Originally reported here: GitTools/GitVersion#1503

Using gitversion 4.0.1-beta1.50 (I believe which uses 2.9.1?) a command line build works fine on SDK 2.1.500... BUT when using vscode and omnisharp 1.32.8 I'm getting failures - meaning that intellisense etc isn't working for me. On windows btw.

Exception is:

[info]: OmniSharp.MSBuild.ProjectManager
        Loading project: c:\Source\xxxxxxxx\xxxxxx.csproj
Exception when creating task: System.IO.FileNotFoundException: Could not load file or assembly 'System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
File name: 'System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
   at UtilPack.NuGet.AssemblyLoading.NuGetRestorerWrapper.ResolveNuGetPackageAssemblies(String[] packageID, String[] packageVersion, MarshaledResultSetter`1 setter)
   at UtilPack.NuGet.AssemblyLoading.NuGetAssemblyResolverImpl.UseResolver(String[] packageIDs, String[] packageVersions)
   at UtilPack.NuGet.AssemblyLoading.NuGetAssemblyResolverImpl.<LoadNuGetAssemblies>d__11.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at E_UtilPack.<LoadNuGetAssembly>d__7.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at UtilPack.NuGet.MSBuild.NuGetTaskRunnerFactory.LoadTaskType(String taskTypeName, NuGetAssemblyResolver resolver, String packageID, String packageVersion, String assemblyPath, ConstructorInfo& taskConstructor, Object[]& constructorArguments, Boolean& usesDynamicLoading)
   at UtilPack.NuGet.MSBuild.TaskReferenceCreator.CreateTaskReferenceHolder(String taskTypeName, NuGetAssemblyResolver resolver, String packageID, String packageVersion, String assemblyPath, String msbuildFrameworkAssemblyName, ResolverLogger logger)
   at UtilPack.NuGet.MSBuild.TaskReferenceCreator.CreateTaskReferenceHolder(String taskTypeName, NuGetAssemblyResolver resolver, String packageID, String packageVersion, String assemblyPath, String msbuildFrameworkAssemblyName, ResolverLogger logger)
   at UtilPack.NuGet.MSBuild.NuGetTaskRunnerFactory.CreateExecutionHelper(String taskName, XElement taskBodyElement, String taskPackageID, String taskPackageVersion, String taskAssemblyFullPath, String taskAssemblyPathHint, BoundRestoreCommandUser restorer, ResolverLogger resolverLogger, GetFileItemsDelegate getFiles, String assemblyCopyTargetFolder, AppDomainSetup& appDomainSetup)
   at UtilPack.NuGet.MSBuild.NuGetTaskRunnerFactory.<>c__DisplayClass36_5.<Initialize>b__7()

WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].

[fail]: OmniSharp.MSBuild.ProjectLoader
        Exception in initialization: System.IO.FileNotFoundException: Could not load file or assembly 'System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
File name: 'System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
   at UtilPack.NuGet.AssemblyLoading.NuGetRestorerWrapper.ResolveNuGetPackageAssemblies(String[] packageID, String[] packageVersion, MarshaledResultSetter`1 setter)
   at UtilPack.NuGet.AssemblyLoading.NuGetAssemblyResolverImpl.UseResolver(String[] packageIDs, String[] packageVersions)
   at UtilPack.NuGet.AssemblyLoading.NuGetAssemblyResolverImpl.<LoadNuGetAssemblies>d__11.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at E_UtilPack.<LoadNuGetAssembly>d__7.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at UtilPack.NuGet.MSBuild.NuGetTaskRunnerFactory.LoadTaskType(String taskTypeName, NuGetAssemblyResolver resolver, String packageID, String packageVersion, String assemblyPath, ConstructorInfo& taskConstructor, Object[]& constructorArguments, Boolean& usesDynamicLoading)
   at UtilPack.NuGet.MSBuild.TaskReferenceCreator.CreateTaskReferenceHolder(String taskTypeName, NuGetAssemblyResolver resolver, String packageID, String packageVersion, String assemblyPath, String msbuildFrameworkAssemblyName, ResolverLogger logger)
   at UtilPack.NuGet.MSBuild.TaskReferenceCreator.CreateTaskReferenceHolder(String taskTypeName, NuGetAssemblyResolver resolver, String packageID, String packageVersion, String assemblyPath, String msbuildFrameworkAssemblyName, ResolverLogger logger)
   at UtilPack.NuGet.MSBuild.NuGetTaskRunnerFactory.CreateExecutionHelper(String taskName, XElement taskBodyElement, String taskPackageID, String taskPackageVersion, String taskAssemblyFullPath, String taskAssemblyPathHint, BoundRestoreCommandUser restorer, ResolverLogger resolverLogger, GetFileItemsDelegate getFiles, String assemblyCopyTargetFolder, AppDomainSetup& appDomainSetup)
   at UtilPack.NuGet.MSBuild.NuGetTaskRunnerFactory.<>c__DisplayClass36_5.<Initialize>b__7()
   at System.Lazy`1.CreateValue()
   at System.Lazy`1.LazyInitValue()
   at UtilPack.NuGet.MSBuild.NuGetTaskRunnerFactory.Initialize(String taskName, IDictionary`2 parameterGroup, String taskBody, IBuildEngine taskFactoryLoggingHost)

WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].

[fail]: OmniSharp.MSBuild.ProjectLoader
        The task factory "UtilPack.NuGet.MSBuild.NuGetTaskRunnerFactory" could not be loaded from the assembly "C:\Users\kiera\.nuget\packages\utilpack.nuget.msbuild\2.9.1\build\\net46\UtilPack.NuGet.MSBuild.dll". Could not load file or assembly 'System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.

Any more details just let me know?

The Fall Creator's Update is out, and .NET Core updated to version 2.0.2. This resulted in a change in NuGet assemblies (4.3.0 -> 4.4.0) under .NET Core MSBuild command, and that change apparently introduced binary incompatible change in restore method (System.MissingMethodException: Method not found: 'NuGet.Commands.RestoreCommandProviders NuGet.Commands.RestoreCommandProviders.Create).

There needs to be some kind of facade functionality for UtilPack.NuGet.MSBuild .NET Core version:

• Introduce new assembly UtilPack.NuGet.MSBuild.Facade, which will examine the assembly version of the type loaded by Type.GetType("NuGet.Common.ILogger, NuGet.Common") command.
• It will then load the actual task factory from assembly "UtilPack.NuGet.MSBuild.NuGetPackageVersion.dll", located in the same directory.

Here is an interesting one for you.

For the hell of it I just opend my project in VSCode!
I have the latest VSCore (version 1.21.0)
I have the following extensions installed:

When I open the project I get this in the OUTPUT window - here is the full output:

Starting OmniSharp server at 2018-3-11 19:46:52
Target: e:\Repos\DotNet.Glob

OmniSharp server started
Path: C:\Users\Daz.vscode\extensions\ms-vscode.csharp-1.14.0.omnisharp\OmniSharp.exe
PID: 23732

Starting OmniSharp on Windows 6.2.9200.0 (x64)
info: OmniSharp.MSBuild.Discovery.MSBuildLocator
Located 2 MSBuild instance(s)
1: Visual Studio Community 2017 15.6.27428.2002 - "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin"
2: StandAlone 15.0 - "C:\Users\Daz.vscode\extensions\ms-vscode.csharp-1.14.0.omnisharp\msbuild\15.0\Bin"
info: OmniSharp.MSBuild.Discovery.MSBuildLocator
Registered MSBuild instance: Visual Studio Community 2017 15.6.27428.2002 - "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin"
info: OmniSharp.Cake.CakeProjectSystem
Detecting Cake files in 'e:\Repos\DotNet.Glob'.
info: OmniSharp.Cake.CakeProjectSystem
Found 1 Cake files.
[warn]: OmniSharp.Cake.CakeProjectSystem
Could not initialize Cake script service. Aborting.
info: OmniSharp.DotNet.DotNetProjectSystem
Initializing in e:\Repos\DotNet.Glob
info: OmniSharp.DotNet.DotNetProjectSystem
Auto package restore: False
info: OmniSharp.DotNet.DotNetProjectSystem
Update workspace context
info: OmniSharp.DotNet.DotNetProjectSystem
Resolving projects references
info: OmniSharp.MSBuild.ProjectSystem
No solution files found in 'e:\Repos\DotNet.Glob'
info: OmniSharp.MSBuild.ProjectManager
Queue project update for 'e:\Repos\DotNet.Glob\src\DotNet.Glob\DotNet.Glob.csproj'
info: OmniSharp.MSBuild.ProjectManager
Queue project update for 'e:\Repos\DotNet.Glob\src\DotNet.Glob.Benchmarks\DotNet.Glob.Benchmarks.csproj'
info: OmniSharp.MSBuild.ProjectManager
Queue project update for 'e:\Repos\DotNet.Glob\src\DotNet.Glob.Tests\DotNet.Glob.Tests.csproj'
info: OmniSharp.Script.ScriptProjectSystem
Detecting CSX files in 'e:\Repos\DotNet.Glob'.
info: OmniSharp.MSBuild.ProjectManager
Loading project: e:\Repos\DotNet.Glob\src\DotNet.Glob\DotNet.Glob.csproj
info: OmniSharp.Script.ScriptProjectSystem
Could not find any CSX files
info: OmniSharp.Stdio.Host
Invoking Workspace Options Provider: OmniSharp.Roslyn.CSharp.Services.CSharpWorkspaceOptionsProvider
info: OmniSharp.Stdio.Host
Configuration finished.
info: OmniSharp.Stdio.Host
Omnisharp server running using Stdio at location 'e:\Repos\DotNet.Glob' on host 15780.
Exception when creating task: System.IO.FileNotFoundException: Could not load file or assembly 'System.ValueTuple, Version=4.0.1.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified.
File name: 'System.ValueTuple, Version=4.0.1.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'
at UtilPack.NuGet.AssemblyLoading.NuGetRestorerWrapper.ResolveNuGetPackageAssemblies(String[] packageID, String[] packageVersion, MarshaledResultSetter`1 setter)
at UtilPack.NuGet.AssemblyLoading.NuGetAssemblyResolverImpl.UseResolver(String[] packageIDs, String[] packageVersions)
at UtilPack.NuGet.AssemblyLoading.NuGetAssemblyResolverImpl.d__11.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at E_UtilPack.d__5.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at UtilPack.NuGet.MSBuild.NuGetTaskRunnerFactory.LoadTaskType(String taskTypeName, NuGetAssemblyResolver resolver, String packageID, String packageVersion, String assemblyPath, ConstructorInfo& taskConstructor, Object[]& constructorArguments, Boolean& usesDynamicLoading)
at UtilPack.NuGet.MSBuild.TaskReferenceCreator.CreateTaskReferenceHolder(String taskTypeName, NuGetAssemblyResolver resolver, String packageID, String packageVersion, String assemblyPath, String msbuildFrameworkAssemblyName, ResolverLogger logger)
at UtilPack.NuGet.MSBuild.TaskReferenceCreator.CreateTaskReferenceHolder(String taskTypeName, NuGetAssemblyResolver resolver, String packageID, String packageVersion, String assemblyPath, String msbuildFrameworkAssemblyName, ResolverLogger logger)
at UtilPack.NuGet.MSBuild.NuGetTaskRunnerFactory.CreateExecutionHelper(String taskName, XElement taskBodyElement, String taskPackageID, String taskPackageVersion, String taskAssemblyFullPath, String taskAssemblyPathHint, BoundRestoreCommandUser restorer, ResolverLogger resolverLogger, GetFileItemsDelegate getFiles, String assemblyCopyTargetFolder, AppDomainSetup& appDomainSetup)
at UtilPack.NuGet.MSBuild.NuGetTaskRunnerFactory.<>c__DisplayClass30_3.b__3()

WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].

Exception in initialization: System.IO.FileNotFoundException: Could not load file or assembly 'System.ValueTuple, Version=4.0.1.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified.
File name: 'System.ValueTuple, Version=4.0.1.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'
at UtilPack.NuGet.AssemblyLoading.NuGetRestorerWrapper.ResolveNuGetPackageAssemblies(String[] packageID, String[] packageVersion, MarshaledResultSetter1 setter) at UtilPack.NuGet.AssemblyLoading.NuGetAssemblyResolverImpl.UseResolver(String[] packageIDs, String[] packageVersions) at UtilPack.NuGet.AssemblyLoading.NuGetAssemblyResolverImpl.<LoadNuGetAssemblies>d__11.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at E_UtilPack.<LoadNuGetAssembly>d__5.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at UtilPack.NuGet.MSBuild.NuGetTaskRunnerFactory.LoadTaskType(String taskTypeName, NuGetAssemblyResolver resolver, String packageID, String packageVersion, String assemblyPath, ConstructorInfo& taskConstructor, Object[]& constructorArguments, Boolean& usesDynamicLoading) at UtilPack.NuGet.MSBuild.TaskReferenceCreator.CreateTaskReferenceHolder(String taskTypeName, NuGetAssemblyResolver resolver, String packageID, String packageVersion, String assemblyPath, String msbuildFrameworkAssemblyName, ResolverLogger logger) at UtilPack.NuGet.MSBuild.TaskReferenceCreator.CreateTaskReferenceHolder(String taskTypeName, NuGetAssemblyResolver resolver, String packageID, String packageVersion, String assemblyPath, String msbuildFrameworkAssemblyName, ResolverLogger logger) at UtilPack.NuGet.MSBuild.NuGetTaskRunnerFactory.CreateExecutionHelper(String taskName, XElement taskBodyElement, String taskPackageID, String taskPackageVersion, String taskAssemblyFullPath, String taskAssemblyPathHint, BoundRestoreCommandUser restorer, ResolverLogger resolverLogger, GetFileItemsDelegate getFiles, String assemblyCopyTargetFolder, AppDomainSetup& appDomainSetup) at UtilPack.NuGet.MSBuild.NuGetTaskRunnerFactory.<>c__DisplayClass30_3.<Initialize>b__3() at System.Lazy1.CreateValue()
at System.Lazy1.LazyInitValue() at UtilPack.NuGet.MSBuild.NuGetTaskRunnerFactory.Initialize(String taskName, IDictionary2 parameterGroup, String taskBody, IBuildEngine taskFactoryLoggingHost)

WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].

The task factory "UtilPack.NuGet.MSBuild.NuGetTaskRunnerFactory" could not be loaded from the assembly "C:\Users\Daz.nuget\packages\utilpack.nuget.msbuild\2.4.0\build\net45\UtilPack.NuGet.MSBuild.dll". Could not load file or assembly 'System.ValueTuple, Version=4.0.1.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified.
[warn]: OmniSharp.MSBuild.ProjectManager
Failed to load project file 'e:\Repos\DotNet.Glob\src\DotNet.Glob\DotNet.Glob.csproj'.
e:\Repos\DotNet.Glob\src\DotNet.Glob\DotNet.Glob.csproj

I'm using a package that uses UtilPack.NuGet (GitVersionTask). It's extremely slow because every project that uses GitVersionTask in turn has UtilPack.NuGet try to resolve all dependencies with NuGet every time. So for every single project being built in a solution, I see:

[NuGet Minimal]: Restoring packages for C:\Users\user\AppData\Local\Temp\yr2nqvrh.qcc\dummy...

is there a way to have UtilPack not try to do a restore every time?

UtilPack as a whole has grown quite a bit since its earlier days. It is now at a point where a proper separation of projects is required. Current separation idea is the following:

• Cryptography projects into their own repository
• NuGet projects into their own repository
• Network (and resource pooling) projects into their own repository

This will obviously affect the names of the NuGet packages as well. Because of this, it is better be done sooner than later.

build task with an output property like so:

        [Output]
        public ITaskItem DefaultManifestFileItemForPackage { get; set; }

Causes the utilpack msbuild task factory to raise an invalid cast exception.

Changing it to an array is the workaround.

I'd like to do the following:

1. In my nugget package, I am including a targets file in the build folder.
2. In that targets file I am including the PackageReference for the UtilPack.NuGet.MSBuild package.
3. In that same nuget package, I am including my msbuild task that I want to run.
4. In the targets file I am also adding the util pack task factory markup in order to run my task.

So here is the flow I am going for:

1. User adds a package reference to my nuget package
2. My nuget package adds the package reference for utilpack.
3. My nuget package also has my msbuild tasks, and adds the appropriate util pack using task elements for them.

Here is my problem..

1. I am not sure if adding a package reference, during a restore is workable..

PackageVersion: This element should contain the version string of the package which contains the task to be executed. If not present, the newest version will be used. Should be version range.

I need this PackageVersion to be the version of the package that the current targets are in.

For example if a user adds my nuget package version 1.0.1 - I need this value to be 1.0.1. If they add 1.0.2 - I need this to be 1.0.2.

I could hardcode this value in the targets file each time I release I would have to remember to update it so I want to avoid this.. So i'm trying to look for a way to tell the task factory to look in the version of the package reference containing this targets file!

It seems that currently loading tasks compiled against MSBuild 14.x, when run in .NET Desktop, will cause the MSBuild 14.0 assembly to be loaded from GAC, instead of being redirected to MSBuild assembly loaded by current runtime. Need to investigate why that happens, and whether it can be fixed.