We Keep Coding

msbuild ignores passed ReferencePath

Summary:
I'm passing /p:ReferencePath to msbuild, when building a Xamarin.Android project. This does work with Visual Studio 2017, but not with Visual Studio 2019.
In detail:
I have two projects:
Xamarin.Forms (with main class library, iOS and Android project underneath)
Class library
The Xamarin.Forms project is referencing the class library via HintPath directly in Debug build. On the build server (Jenkins) things work differently (release build) and the library is build separately. Therefore I use ReferencePath to overwrite the stored HintPath and reference the class library (dll) on the Jenkins server, which was previously build.
The failing build command looks like this
"C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Current\Bin\MSBuild"
TestJenkins/TestJenkins/TestJenkins.Android/TestJenkins.Android.csproj
/p:Configuration=Release /p:ReferencePath=C:\Jenkins\workspace\TestMSBuild\MPL1.0
/t:PackageForAndroid /t:Build /v:diag
I left out the other parts, because they do work. When reading the output log I noticed the following, when building with Visual Studio 2019:
the ResolveAssemblyReference task doesn't list the passed ReferencePath under SearchPaths= for the Android build, but it is listed for the class library build (the main library for the Xamarin.Forms project and not the separate class library)
one warning MSB3245
multiple error CS0246
On another Jenkins machine there is Visual Studio 2017 installed and the same code, the same scripts does work without an error. So the question is, what's the difference. Lately, I upgraded to .NET Standard. Perhaps I forgot something?
What I've tried:
set up a similar test project, but here it fails with error CS0103
use hard coded link to the dll with BeforeResolveReferences and this does work, but that is only a hack (continous integration should not work that way)
adding ReferencePath in csproj in Android project, but still the same errors
changed Copy local in the Android project
Visual Studio 2019 does build the project on the Jenkins server, if I update the references and use hard-coded links
read the diagnostic log (140k lines)
read the manual, but the use of RerencePath is not really explained
many more ...
Question:
As you can see I'm using the build tools of Visual Studio 2019, but I don't know what has changed to Visual Studio 2017 Build Tools. Am I calling msbuild wrong? Does /p:ReferencePath works different than I expect? Can someone give me a hint to find the cause for this?
Edit (1):
Now I found the following out: The CS0246 error point to lines in my Android project, where a using statement is made: e.g. using MyClassLibrary.Component.Feature;.
The MSB3245 warning seams to occur if the HintPath in the Android project can't be resolved.
Back to the using statement: I have an interface defined my external class library. A class in the Android project implements this. E.g.
Code in external class library:
public interface ITextService
{
string GetText();
}
Code in Android project:
using SomeLibrary; // error CS0246
using Xamarin.Forms;
[assembly: Dependency(typeof(TestJenkins.Droid.TextService))]
namespace TestJenkins.Droid
{
public class TextService : ITextService // error CS0246
{
public string GetText()
{
return SomeLibrary.ServiceClass.NativeKey;
}
}
}
The question still is, why can't the reference from the Android project be resolved?
Edit (2):
For me that must be a bug in msbuild with VS2019 or a behavior change. So I thought I can combine this with this:
<Project DefaultTargets="Build" InitialTargets="ValidateToolsDllExists" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="ValidateToolsDllExists">
<Error
Text=" The ToolsDllPath property must be set on the command line."
Condition="'$(ToolsDllPath)' == ''" />
<Error
Text=" The ToolsDllPath property must be set to the full path to tools.dll."
Condition="!Exists('$(ToolsDllPath)')" />
</Target>
<Target Name="BeforeResolveReferences">
<CreateProperty
Value="$(ToolsDllPath);$(AssemblySearchPaths)">
<Output TaskParameter="Value"
PropertyName="AssemblySearchPaths" />
</CreateProperty>
</Target>
<!-- ... -->
</Project>
But passing /p:ToolsDllPath=C:\path\to\my\dll to msbuild still throws the CS0246 error.

MSBuild Exec - All commands exit with MSB3073, exit code 0xC0000005

Windows 10 64-bit - Visual Studio Community 2017
Brand new Hello World C# project.
I added the following to my build tasks:
<Target Name="AfterBuild">
<Message Text="Testing" Importance="high"></Message>
<Exec Command="echo Test" />
</Target>
I see the "Testing" Message executed by the build, so I know the Target is running, at least.
The next task, Exec, always shows the following no matter what commands I give it.
1>$(ProjectPath)(60,5): error MSB3073: The command "echo Test" exited with code -1073741819.
-1073741819 is of course 0xC0000005, Access Violation.
Note: The exact same thing happens if I don't use a Target but instead use post-build commands from the Project Properties GUI (It uses Exec to run those internally, anyway).
Note: I've had similar issues with VS Code somehow misusing my ComSpec variable, which for reference is defined as ComSpec : %SystemRoot%\system32\cmd.exe

How to run MSBuild pack target in Visual Studio 2017

My question is similar to this and this.
I want to package a .Net Framework library in Visual Studio 2017 RC. In VS 2015 with project.json build system, I was able to accomplish this by importing a custom targets file into the .xproj file. This custom targets file took care of creating the nuspec file if it didn't exist, then running nuget pack, copying the resulting packages to local feed location, etc.
Do I need to do something similar in 2017 (haven't made a serious effort yet) or can I somehow enable the pack target in my .csproj file?
The docs here only show to run the pack target from the command line.
EDIT:
I'm trying the below custom target referencing a Nuget 4.0 exe from the nightly builds...
<Target Name="PackNugets" AfterTargets="Build">
<PropertyGroup>
<NugetV4Path>$([System.IO.Path]::GetFullPath('path to nuget.exe'))</NugetV4Path>
</PropertyGroup>
<Exec Command=""$(NugetV4Path)\nuget.exe" pack "$(MSBuildProjectDirectory)\$(PackageId).csproj" -Symbols -OutputDirectory bin -Properties Configuration=Release"/>
</Target>
But I get the following error
System.InvalidCastException: Unable to cast object of type 'System.String' to type 'NuGet.Frameworks.NuGetFramework'.
at NuGet.ProjectManagement.NuGetProject.GetMetadata[T](String key)
at NuGet.ProjectManagement.PackagesConfigNuGetProject..ctor(String folderPath, Dictionary`2 metadata)
at CallSite.Target(Closure , CallSite , Type , Object , Dictionary`2 )
at System.Dynamic.UpdateDelegates.UpdateAndExecute3[T0,T1,T2,TRet](CallSite site, T0 arg0, T1 arg1, T2 arg2)
at NuGet.CommandLine.ProjectFactory.AddDependencies(Dictionary`2 packagesAndDependencies)
at NuGet.CommandLine.ProjectFactory.ProcessDependencies(PackageBuilder builder)
at NuGet.CommandLine.ProjectFactory.CreateBuilder(String basePath, NuGetVersion version, String suffix, Boolean buildIfNeeded, PackageBuilder builder)
at NuGet.Commands.PackCommandRunner.BuildFromProjectFile(String path)
at NuGet.CommandLine.PackCommand.ExecuteCommand()
at NuGet.CommandLine.Command.ExecuteCommandAsync()
at NuGet.CommandLine.Command.Execute()
at NuGet.CommandLine.Program.MainCore(String workingDirectory, String[] args)
Something to do with one of the properties in the csproj? Does NugetFramework refer to the TargetFramework?
I am targeting net452 in my csproj, in case that helps.
EDIT:
That exception is indeed about nuget attempting to parse the TargetFramework, but it is not clear whether it is failing at my csproj or at a dependency...

EDIT: The latest updates to VS2017 have added the Pack action to the project context menu, so the below action can be changed as follows:
AfterTargets=Pack
Remove the Exec element
If you are targeting multiple frameworks, you may have to insert a \$(Configuration) after the \bin in the NugetPackages Include.
Ok, this issue solved it for me. For now, we have to use dotnet instead of msbuild or nuget.
So, my custom target in the imported .targets file becomes
<Project ToolsVersion="15.0">
<Target Name="PackNugets" AfterTargets="AfterBuild">
<!-- Swap out nuget for dotnet and update the cli args -->
<!-- Might actually be able to leave out the csproj path, since
this target should run in the project directory. Test it first. -->
<Exec Command="dotnet pack "$(MSBuildProjectDirectory)\$(PackageId).csproj" --no-build --include-symbols -o bin -c Release"/>
<!-- If you want to copy to a local feed -->
<ItemGroup>
<NugetPackages Include="$(MSBuildProjectDirectory)\bin\$(PackageId).$(PackageVersion)*.nupkg"/>
</ItemGroup>
<Copy SourceFiles="#(NugetPackages)" DestinationFolder="path to local feed" />
</Target>
</Project>

I was wanting to know the same thing, so I went spelunking in the MSBuild files, namely: C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Sdks\NuGet.Build.Tasks.Pack\build and look for the "Pack" target.
Beyond that, I would refer to general MSBuild command line syntax here, but a few examples:
msbuild.exe -t:Pack -p:IncludeSymbols=true
msbuild.exe -t:Pack -p:Configuration=Release -p:VersionSuffix="alpha" # or "-alpha" - not sure
EDIT: A little more research and work on my scenario and I found this documentation of the important properties.

Please note that dotnet pack or msbuild /t:Pack currently doesn't support .NET Framework projects. They only work NETCore projects.

You can even improve Ken G answer if you want to push the nuget using this:
<Target Name="PushNugetPackage" AfterTargets="Pack" Condition="'$(Configuration)' == 'Release'">
<Exec Command="nuget.exe push -Source "mysource" -ApiKey VSTS $(OutputPath)..\$(PackageId).$(PackageVersion).nupkg" />
</Target>
It will only run after you choose pack from context menu and configuration is Release, so you don't push debug packages, remove that condition if you really don't need it
Source

ItemGroup Item scope, alternatively "Why does MSBuild hate me?"

I have a solution I'm trying to get to build on TFS. I want to update the versions of all appropriate files, and I've been stuck trying to get this done. There are plenty of links on how to do it, but none of them work for me, due to one little issue... Scope.
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="DesktopBuild" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="3.5">
<Target Name="DesktopBuild">
<CallTarget Targets="GetFiles" />
<Message Text="CSFiles: '#(CSFiles)'" />
</Target>
<Target Name="GetFiles">
<ItemGroup>
<CSFiles Include="**\AssemblyInfo.cs" />
</ItemGroup>
<Message Text="CSFiles: '#(CSFiles)'" />
</Target>
</Project>
My tree looks like this:
test.proj
application.sln
application (Folder)
main.cs
Properties (Folder)
AssemblyInfo.cs
When I run "c:\Windows\Microsoft.NET\Framework\v3.5\MSBuild.exe test.proj" from the solution folder... I get the following output:
Microsoft (R) Build Engine Version 3.5.30729.1
[Microsoft .NET Framework, Version 2.0.50727.3074]
Copyright (C) Microsoft Corporation 2007. All rights reserved.
Build started 7/6/2009 3:54:10 PM.
Project "D:\src\test.proj" on node 0 (default targets).
CSFiles: 'application\Properties\AssemblyInfo.cs'
DesktopBuild:
CSFiles: ''
Done Building Project "D:\src\test.proj" (default targets).
Build succeeded.
0 Warning(s)
0 Error(s)
Time Elapsed 00:00:00.04
So, how can I make my ItemGroup have global scope? All the Targets files used by the compiler and TeamBuild do this same thing, and theirs all seem to be global... I don't understand why this isn't working for me.
Any help?

Have you tried using DependsOnTarget rather than CallTarget? It could be that CallTarget is causing the scope issue.

The previous commenter was correct, you should change this to use DependsOnTargets instead of using the CallTarget task. What you are seeing is a bug not a scoping inssue. The way to avoid this bug is to use DependsOnTargets (which is a much better approach anywayz).
Sayed Ibrahim Hashimi
My Book: Inside the Microsoft Build Engine : Using MSBuild and Team Foundation Build

As said, you should use DependsOnTargets. I've done some research on MSBuild scope, you can find my results on my blog : http://blog.qetza.net/2009/10/23/scope-of-properties-and-item-in-an-msbuild-script/
The thing is there seems to be a global scope for the project and a local scope for the target . When entering the target, the global scope is copied and when exiting the target, the local scope is merged back. So a CallTarget will not get the modified local scope values but the DependsOnTargets will since the first target is exited before the entering the second target.

We do something similar in our build. We pass the version as a command line parameter.
In our TFSBuild.proj we set the version to 0.0.0.0 if no version was supplied:
<!--Our assembly version. Pass it in from the command prompt like this: /property:Version=1.0.0.0-->
<PropertyGroup>
<Version>0.0.0.0</Version>
</PropertyGroup>
<PropertyGroup>
<!--Used to ensure there is a newline before our text to not break the .cs files if there is no newline at the end of the file.-->
<newLine>%0D%0A</newLine>
Then we do this:
<Target Name="BeforeCompile">
<!--Update our assembly version. Pass it in from the command prompt like this: /property:Version=1.0.0.0-->
<!--attrib needs to be run first to remove the read only attribute since files from tfs are read only by default.-->
<Exec Command='attrib -R $(SolutionRoot)\Source\Project\GlobalAssemblyInfo.cs' />
<WriteLinesToFile File="$(SolutionRoot)\Source\Project\GlobalAssemblyInfo.cs"
Lines='$(newLine)[assembly: AssemblyVersion("$(Version)")]'/>
</Target>

sgen.exe x64 .net c# fails with "assembly with an incorrect format"

I have ws2008 x64 with vs2008.
When I set my vs to x64 (because I have 64bit dlls) and run compilation sgen says that
An attempt was made to load an assembly with an incorrect format
VS takse sgen from
C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\
and I think that it should take it from
C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\x64\
when i take 64bit version of sgen and put it into C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\ (replace 32bit version). I was able to compile.
What should I do to point to the correct version of sgen under vs.
Can I somehow configure solutinon platforms for one project to point to the correct sgens (for x86 to 32 bit and for x64 to 64 bit sgen version)?

Does this help you out? Take a look at the section where he uses sgen as a post build:
As a consequence you need to add the SGen command as a custom post-build event on the Build Events tab of your VS project properties:
"C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\sgen.exe" /force /assembly:"$(TargetPath)" /compiler:/keycontainer:VS_KEY_5EFB7881D71082EDCF85DBBFCD748B9A /compiler:/delaysign-

This is the best answer I could find: Conditional Post-Build Event Command for x64 sgen, a blog post by Michael Hanes.
Use a post build event, that conditionally checks if the 64 bit SGEN is installed, and use it when needed:
REM Use the 64-bit sgen from the Win 2008 and
REM .NET 3.5 SDK in a 64-bit dev environment
REM ProgramFiles variable is set to
REM 'Program Files (x86)' in a x64 environment
REM Processor_Architecture variable returns x86
REM in both an x86 and x64 environment within VS.
if /I "%ProgramFiles%" == "C:\Program Files" (
set SgenToolPath="C:\Program Files\Microsoft
SDKs\Windows\v6.0A\Bin\sgen.exe"
) else (
set SgenToolPath="C:\Program Files\Microsoft
SDKs\Windows\v6.1\Bin\x64\sgen.exe"
)
%SgenToolPath% /compiler:"\"/keyfile:$(ProjectDir)
MyKeyFile.snk"\" /force "$(TargetPath)"
This is intended to be a replacement for the "Generate Serialization Assemblies" dropdown setting for "On" for a given Visual Studio project.

Add a little pre-build action just to dump out env vars that are in effect at build time.
Check vcvarsall.bat and follow it as it loads other bat-s for different host/build platform combos.
Check actual bitness of devenv process (say with process explorer).

There's a different solution posted on this blog post about specifying __SdkSgenTool conditionally:
The only missing thing is that I do need to set SGenToolPath to my build output directory. This was harder as expected since as a normal property it was overwritten by other MsBuild tasks. The solution that finally did work was to create the already existing property and set the value to its final value when no other tasks could interfere.
Below is the “code” to make Sgen work in 64 bit. You need to define the __SdkSgenTool variable in all build modes since the post build steps like copy are executed regardless of the build mode.
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release|x64'">
....
<GenerateSerializationAssemblies>On</GenerateSerializationAssemblies>
<SGenUseProxyTypes>false</SGenUseProxyTypes>
<__SdkSgenTool Condition="exists('C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\NETFX 4.0 Tools\x64\sgen.exe')">C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\NETFX 4.0 Tools\x64\sgen.exe</__SdkSgenTool>
<__SdkSgenTool Condition="exists('C:\Program Files\Microsoft SDKs\Windows\v7.0A\Bin\NETFX 4.0 Tools\x64\sgen.exe')">C:\Program Files\Microsoft SDKs\Windows\v7.0A\Bin\NETFX 4.0 Tools\x64\sgen.exe</__SdkSgenTool>
</PropertyGroup>
...
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
<Target Name="BeforeBuild">
<Copy SourceFiles="$(__SdkSgenTool)" DestinationFiles="$(TargetDir)\sgen.exe" SkipUnchangedFiles="true" />
<CreateProperty Value="$(TargetDir)">
<Output TaskParameter="Value" PropertyName="SGenToolPath" />
</CreateProperty>
I have heard that this issue will be fixed with VS2012 which is a good
thing.
This doesn't appear to be fixed in VS2012. I would use this with caution, because __SdkSgenTool appears to be an internal property, and therefore not something you can rely on.