in its setter it refers to itself instead of backing field _outputEntryPoint.

Probably the intended implementation was:

    public object this[object key]
    {
        get { return ((IDictionary<TKey, TValue>)this)[(TKey)key]; }
        set { ((IDictionary<TKey, TValue>)this)[(TKey)key] = (TValue)value; }
    }

CI build on xplat branch should:

1. Run unit tests.
2. Run on Linux.

Right now it's the same as on master which builds (using retail msbuild) and then rebuilds (using OSS msbuild).

Hi.
I think current MSBuild project xml lack some flexibility when storing assembly references. This may be the result of toolchain evolution, not the design flaw, but its what it is now:

When project referencing assembly - it stores corresponding data in Reference ItemGroup like this

<Reference Include="Newtonsoft.Json, Version=6.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed, processorArchitecture=MSIL">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>..\packages\Newtonsoft.Json.6.0.8\lib\net45\Newtonsoft.Json.dll</HintPath>
</Reference>

And it has single HintPath node which uses absolute or relative path. The problem with relative path that it's being calculated once when reference is added and can't cater for later structure changes.

E.g. if we are using nuget - default packages path is defined as $(SolutionDir)\Packages. And if project is located just one folder below say First.sln file - final reference path is expanded like ..\packages\<path to nuget dll> which is ok.

Unless you want to include same project into to another, Second.sln, file which is located above or below First.sln folder. In this case project reference becomes incorrect - default packages folder for Second.sln doesn't match with expanded ..\packages\ anymore.
Thus we have a dependency on the $(SolutionDir) value which is not re-evaluated during build.

I can see few potential fixes for this:

1. Allow and process multiple HintPath nodes so different solutions can add it's own relative HintPath instead of overwriting other solution's records. This may require changes in VS-Msbuild-Nuget integration.
2. Make HintPath value 'nuget-aware' for nuget references using predefined property, e.g. $(NugetPackagesPath)\Newtonsoft.Json.6.0.8\lib\net45\Newtonsoft.Json.dll - this will be re-evaluated on each build and can enable certain scenarios for build servers either.
3. Enable some kind of 'packages discovery' scenario - like node.js's npm with node_modules (see detailed description here [https://docs.npmjs.com/files/folders#cycles-conflicts-and-folder-parsimony] - so msbuild can walk up by the folder tree to the disk root trying to locate corresponding reference

Happy to hear your opinion on the described issue

The method has access to _activeNodes collection which is accessed under lock in other methods of the class.

MSBuild does not currently offer any way to pass-through properties to the projects within a .sln file.

Despite the documentation, properties provided at the command line with a solution file are ignored.

This makes it very difficult to disable XML warnings on a CI server in order to reduce output noise. Many developers feel that 30% of their lines of code should not be /// <summary>, and that code noise (like output noise) must be justified .

If any of the Visual Studio 2010 products are installed, three tests fail.

The failed tests are listed here:
#61 (comment)

Detailed troubleshooting of the issue is here:
ctaggart#1

This change request came from an external connect bug. Note the change is only when the Private tag ('Copy Local' in Visual Studio) is not present, which is the default. If this flag is given by the user it will still be honored in all cases.

Current Resolve Assembly Reference (RAR) behavior

1. If the assembly is resolved and not found in the GAC, copy it.
2. If the assembly is resolved from the GAC, don't copy the DLL.
3. If the assembly is resolved locally and also happens to be present in the GAC, don't copy the DLL.

This behavior was intended to somewhat mimic run-time behavior. If an assembly is in the GAC on the build machine, it's assumed to be in the GAC on the target machine.

Proposed change in behavior

1. If the assembly is resolved locally (not in the GAC) copy it. Regardless of if it's in the GAC or not.
2. If the assembly is resolved through the GAC (wasn't found locally), then do not copy it.

Repro Steps

1. Project1 references Project2 (Project Reference type)
2. Project2 not in the GAC.
3. Build

This yields the desired behavior, Project2.dll appears in the output folder.

However, if this test is repeated with Project2 in the GAC, Project2.dll will not be copied. The proposed fix would change this behavior and copy Project2.dll (since it was resolved locally first). This should also help when NuGet packages are referenced but also in the GAC on the build machine.

This was originally reported in Connect as MSBuild - TargetOutputs does not include projects with explicit project dependencies listed as well as on Stack Overflow as MSBuild TargetOutputs missing assemblies.

I also encountered the issue and was able to track down its cause:

When the solution contains a ProjectDependencies section for a project, a .metaproj MSBuild file is generated, containing something like the following (obtained from the files attached to the Connect report by setting the MSBuildEmitSolution environment variable to 1 as per Debugging MSBuild script with Visual Studio (3)):

  <Target Name="Build">
    <MSBuild Projects="@(ProjectReference)" BuildInParallel="True" Properties="BuildingSolutionFile=true; CurrentSolutionConfigurationContents=$(CurrentSolutionConfigurationContents); SolutionDir=$(SolutionDir); SolutionExt=$(SolutionExt); SolutionFileName=$(SolutionFileName); SolutionName=$(SolutionName); SolutionPath=$(SolutionPath)" SkipNonexistentProjects="%(ProjectReference.SkipNonexistentProjects)">
      <Output TaskParameter="TargetOutputs" ItemName="MSBuildIssueBuildOutput" />
    </MSBuild>
    <MSBuild Projects="C:\Users\odagenais\oss\MSBuildIssue\Repro\MSBuildIssue\MSBuildIssue.csproj" BuildInParallel="True" ToolsVersion="$(ProjectToolsVersion)" Properties="Configuration=Debug; Platform=AnyCPU;BuildingSolutionFile=true; CurrentSolutionConfigurationContents=$(CurrentSolutionConfigurationContents); SolutionDir=$(SolutionDir); SolutionExt=$(SolutionExt); SolutionFileName=$(SolutionFileName); SolutionName=$(SolutionName); SolutionPath=$(SolutionPath)">
      <Output TaskParameter="TargetOutputs" ItemName="MSBuildIssueBuildOutput" />
    </MSBuild>
  </Target>

It turns out that the second call to MSBuild will NOT append its TargetOutputs to the baseProjectName + "BuildOutput" item (showing up as MSBuildIssueBuildOutput here), which is the source of the "missing assembly" issue we are seeing.

What probably needs to happen, instead, is both invocations of the MSBuild task must write to different items and then merge their values, as follows:

  <Target Name="Build">
    <MSBuild Projects="@(ProjectReference)" BuildInParallel="True" Properties="BuildingSolutionFile=true; CurrentSolutionConfigurationContents=$(CurrentSolutionConfigurationContents); SolutionDir=$(SolutionDir); SolutionExt=$(SolutionExt); SolutionFileName=$(SolutionFileName); SolutionName=$(SolutionName); SolutionPath=$(SolutionPath)" SkipNonexistentProjects="%(ProjectReference.SkipNonexistentProjects)">
      <Output TaskParameter="TargetOutputs" ItemName="MSBuildIssueReferenceBuildOutput" />
    </MSBuild>

    <MSBuild Projects="C:\Users\odagenais\oss\MSBuildIssue\Repro\MSBuildIssue\MSBuildIssue.csproj" BuildInParallel="True" ToolsVersion="$(ProjectToolsVersion)" Properties="Configuration=Debug; Platform=AnyCPU;BuildingSolutionFile=true; CurrentSolutionConfigurationContents=$(CurrentSolutionConfigurationContents); SolutionDir=$(SolutionDir); SolutionExt=$(SolutionExt); SolutionFileName=$(SolutionFileName); SolutionName=$(SolutionName); SolutionPath=$(SolutionPath)">
      <Output TaskParameter="TargetOutputs" ItemName="MSBuildIssueProjectBuildOutput" />
    </MSBuild>
    <ItemGroup>
        <MSBuildIssueBuildOutput Include="@(MSBuildIssueReferenceBuildOutput);@(MSBuildIssueProjectBuildOutput)" />
    </ItemGroup>
  </Target>

Thanks to Microsoft making MSBuild open-source, I was able to track down the code responsible as the AddMetaprojectTargetForManagedProject() method in SolutionProjectGenerator (among others - it appears there are other methods in this class that could emit consecutive invocations of the MSBuild task while assuming the items in the TargetOutputs will get merged/appended).

I can make the necessary changes in a branch of my fork and then submit a pull request; the Contributing Code wiki page suggested I open an issue to first discuss this. I can see why, because I could see some MSBuild scripts depending on the current behaviour (such that my fix would come as a surprise and break existing builds because an assembly that was supposed to have been collected for unit testing, code analysis, etc. all of a sudden is collected and fails said unit testing, etc.) and so we should probably structure the population of the baseProjectName + "BuildOutput" item conditional upon a property/flag of some sort, as in the following:

    <ItemGroup>
        <MSBuildIssueBuildOutput Include="@(MSBuildIssueReferenceBuildOutput)" />
        <MSBuildIssueBuildOutput Include="@(MSBuildIssueProjectBuildOutput)" Condition=" '$(IncludeDependencyProject)' != '' " />
    </ItemGroup>

Other suggestions sought and welcome, especially from the MSBuild team!

For example, if I were to change the binding redirects in Visual Studio 2013's devenv.exe.config to use version 14.0.0 do you know what kinds of problems this might cause?

I've tested out some basic WPF, Console, ASP .Net projects and haven't had any issues yet, but I was just wondering if there was anyone here who might know better.

FWIW I'd be modifying them to match VS 2015's redirects:

<dependentAssembly>
    <assemblyIdentity name="Microsoft.Build.Framework" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
    <bindingRedirect oldVersion="2.0.0.0-12.0.0.0" newVersion="14.0.0.0"/>
</dependentAssembly>
<dependentAssembly>
    <assemblyIdentity name="Microsoft.Build" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
    <bindingRedirect oldVersion="2.0.0.0-12.0.0.0" newVersion="14.0.0.0"/>
</dependentAssembly>
<dependentAssembly>
    <assemblyIdentity name="Microsoft.Build.Engine" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
    <bindingRedirect oldVersion="2.0.0.0-12.0.0.0" newVersion="14.0.0.0"/>
</dependentAssembly>

We've done work internally to experiment with MSBuild on Linux/mono, we need to get this out in the open as soon as possible. Creating an issue so everyone is aware this is coming soon (within a week!).

I found this issue through Roslyn's MSBuildWorkspace, but it happens in MSBuild's code. Let me know if I should post this issue in Roslyn's github.

MSBuildWorkspace.OpenSolutionAsync throws an exception Error parsing the project configuration section in solution file. The entry "" is invalid.. when the .sln file has an empty line, for example:

... (trimmed)
    GlobalSection(ProjectConfigurationPlatforms) = postSolution
... (trimmed)
        {086C7B02-4CE6-4FE4-BB77-D9474D312038}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
        {086C7B02-4CE6-4FE4-BB77-D9474D312038}.Debug|Any CPU.Build.0 = Debug|Any CPU
        {086C7B02-4CE6-4FE4-BB77-D9474D312038}.Release|Any CPU.ActiveCfg = Release|Any CPU
        {086C7B02-4CE6-4FE4-BB77-D9474D312038}.Release|Any CPU.Build.0 = Release|Any CPU

    EndGlobalSection
    GlobalSection(SolutionProperties) = preSolution
        HideSolutionNode = FALSE
    EndGlobalSection
EndGlobal

Note the empty line above "EndGlobalSection".
When this line is removed, MSBuildWorkspace.OpenSolutionAsync succeeds. Visual studio opens and builds the solution without problems despite the empty line.

Following the exception message, we're brought to ParseProjectConfigurations():

        internal Hashtable ParseProjectConfigurations()
        {
            Hashtable rawProjectConfigurationsEntries = new Hashtable(StringComparer.OrdinalIgnoreCase);
            string str;

            do
            {
                str = ReadLine();

                if ((str == null) || (str == "EndGlobalSection"))
                {
                    break;
                }

                string[] nameValue = str.Split(new char[] { '=' });

                // There should be exactly one '=' character, separating the name and value. 
                ProjectFileErrorUtilities.VerifyThrowInvalidProjectFile(nameValue.Length == 2, "SubCategoryForSolutionParsingErrors",
                    new BuildEventFileInfo(FullPath, _currentLineNumber, 0), "SolutionParseInvalidProjectSolutionConfigurationEntry", str);

                rawProjectConfigurationsEntries[nameValue[0].Trim()] = nameValue[1].Trim();
            } while (true);

            return rawProjectConfigurationsEntries;
        }

Perhaps this could be fixed by adding the following code to this and similar methods

                if (String.IsNullOrWhiteSpace(str))
                {
                    continue;
                }

I can take this issue if you think that this is the right way to go.

When msbuild is built in one of the Mono configurations, all command line switches are configured to require a - prefix rather than a / prefix. However, the contents of the -help command line switch have not been updated to reflect this.

I'm pulling my hair out trying to get Visual Studio and MSBuild to agree on where build output should be stored, using any combination of OutputPath and OutDir that I could come up with.

Edit: turns out that there is a third property that controls the build output: WebProjectOutputDir.

I realize that this is not a help forum. I briefly considered asking a question about it on StackOverflow, but 72 others have done so before me, leaving empty-handed most of the time.

There is a huge number of scenarios that require relocating the build output, but there is no reliable way to do that. For example: IIS Express stops working when you change the OutputPath of a web application project (could you believe it?).

Someone even got mad enough over OutputPath and OutDir to write a blog post about it: I hate you, OutDir parameter

Please explain how OutputPath and OutDir were intended to be used, in the context of continuous integration builds.

I have tasks compiled against Mono's version of Ms.Build.Utilities etc. Currently MSBuild fails to load these as the Task base class is not the same between XBuild and MSBuild. Will there be a way to have portable task assemblies under Mono?

I would like an option to be able to treat all warnings as errors, when running from the command line.

Please consider adding support for $(SolutionConfiguration) and $(SolutionPlatform) macros.

We already have $(Configuration) and $(Platform) however these only represent the project configuration and platform respectively.

Having solution level macros would be super useful, as this would allow solutions with many projects to configure themselves depending on the overall solution configuration rather than having to define separate configurations for every solution/project combination.

Although I'm suggesting this be added to msbuild, just as a side note, there is a VS extension that attempts to add this missing functionality by injecting the solution macros during the build:
https://visualstudiogallery.msdn.microsoft.com/dc5d3209-d6a5-4675-a258-984577b5e979

However it would be much more convenient if these basic macros could be baked directly into msbuild, especially when it comes to headless build servers where installing plugins may not be an option.

Thanks,
Daniel

Specifically, the unit testing framework. It would be really nice to keep this in line with the other dotnet OSS projects.

Currently using the mono C# compiler. Tasks/Targets need to be updated to use Roslyn.

Opening this issue to get the discussion going -- xml is very verbose. Many project nowadays opt for configuring using YAML or json.
It would be great to have support for those in msbuild.

* [Issue Guide](https://github.com/Microsoft/msbuild/wiki/Issue-Guide)

See https://github.com/Microsoft/msbuild/blob/master/README.md

After Linux support, we need to add support for building on Mac (under mono).

After #95 closing #45, It should be great to:

• publish the package on https://nuget.org/.

• update the package frequently

• make "strict" use of semver http://semver.org/, incrementing semver based on breaking change (=major), incrementing feature (=minor) bug fixes (=patch). For example, node.js haven't received any breaking change till date (current stable version is v0.12.3)!

• publish the release on GitHub: https://github.com/Microsoft/msbuild/releases highlighting the changes since previous version and to let user install the package from source like so:

  Install-Package MSBuild -Source https://github.com/microsoft/msbuild/archive/v0.1.0.zip

  (assuming MSBuild does not have its own versioning, now would be an excellent time to start fresh with semver)

Additional notes:
The releases by GitHub get the "release assets" stored in Amazon S3. The .tar.gz and .zip files are automatically generated and uploaded by GitHub. You can manually add more files as release assets by editing the release. Ex. https://github.com/microsoft/msbuild/releases/edit/<version>, scroll down where it says Attach binaries by dropping them here or selecting them or even using GitHub API.

In the past I have found this file under the MSBuild folder, so I assumed it was
part of MSBuild.

C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.Cpp.Default.props

However it appears to not be a part of this repository. I was excited when I
noticed that MSBuild was on GitHub, as a 7 MB download is more tolerable
than 6.5 GB download.

this class operates with two collections:
_switchesAdded
_switchOrderList

In ParseParameter method _switchesAdded map is used under condition. I think the intent was to filter duplicates in _switchOrderList list but _switchesAdded map is never updated.

MSTest isn't available cross-platform and the other dotnet open source projects like corefx migrated to xunit already.

As per request from the coreclr people, moving over discussion to here from https://github.com/dotnet/coreclr/issues/497

What is needed for getting MSBuild running on coreclr?

Is this TargetPlatformSdkPath assignment really necessary?

https://github.com/Microsoft/msbuild/blob/master/src/XMakeTasks/Microsoft.Common.CurrentVersion.targets#L88

It doesn't work on Mono, and looks like the logic for getting the sdk path should all be in ToolLocationHelper.

Steps to reproduce:

1. Clone repository
2. Build solution
3. Run unit tests
4. There are 9 failing tests, 349 ignored tests

Expected result: all tests will be green.

I can add more technical details if needed

I'd like to use Microsoft.Build.Evaluation both for parsing project files and writing back to them in OmniSharp https://github.com/OmniSharp/omnisharp-roslyn

Please could you consider creating a nuget package so that I can easily consume this code? Thanks.

Can the owners comment on the branching strategy they intend to use going forward? In particular I am concerned about continuing divergence between master and xplat as time goes on.

Compare to CoreFX, which is implementing cross-platform capabilities on the master branch.

Most build systems that allow the creation of custom targets also have a command-line option for displaying the available targets in a project:

gradle tasks
rake --tasks
grunt --help

Developers working on projects that use MSBuild would benefit from a similar feature.

Unicode characters cause Exec task to fail. Example error output:

------ Build started: Project: TSLProject1, Configuration: Debug x64 ------
    "C:\Users\中文用户\AppData\Local\Microsoft\VisualStudio\11.0\Extensions\qnci5dgg.btj\Binaries\Trinity.TSL.Compiler.exe" --BuildDataModelingProject --ProjectRoot "c:\users\中文用户\documents\visual studio 2012\Projects\TSLProject1\TSLProject1" --ScriptList "MyTSL.tsl" --OutputPath "bin\Debug\ " --AssemblyName Trinity.Extension.0.dll --RootNamespace Trinity.Extension --Clean --BuildDataModelingProjectWithDebugFeatures 
    The system cannot find the path specified.

See also:

http://stackoverflow.com/questions/14224496/

The VisualStudioVersion property is correct without Microsoft.Common.props, but with that props file, the property ends up being 10.0 for ToolsVersion 12.0 and 14.0.

I am using Microsoft.Build.Evaluation.Project to load the project files with the constructor to pass in the global properties. Loaded from assembly: C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\Microsoft.Build\v4.0_4.0.0.0__b03f5f7f11d50a3a\Microsoft.Build.dll

The VisualStudioVersion appears to depend on two things:

1. the ToolsVersion in the project file

2. the Microsoft.Common.props if it exists

3. no ToolsVersion and no common.props has no VisualStudioVersion

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
</Project>

PS C:\Projects\SourceLink1> Fsi.exe .\vsversion.fsx
MSBuildToolsVersion 2.0

2. ToolsVersion 4.0 ends up with VisualStudioVersion 11.0

<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
</Project>

MSBuildToolsVersion 4.0
VisualStudioVersion 11.0

3. ToolsVersion 12.0 ends up with VisualStudioVersion 12.0

<Project ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
</Project>

MSBuildToolsVersion 12.0
VisualStudioVersion 12.0

4. ToolsVersion 14 ends up with VisualStudio 14.0

<Project ToolsVersion="14.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
</Project>

MSBuildToolsVersion 14.0
VisualStudioVersion 14.0

5. 1. no ToolsVersion and with common.props has no VisualStudioVersion

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Import Project="C:\Projects\msbuild\src\XMakeTasks\Microsoft.Common.props" />
</Project>

MSBuildToolsVersion 2.0

6. ToolsVersion 4.0 ends up with VisualStudioVersion 11.0

<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Import Project="C:\Projects\msbuild\src\XMakeTasks\Microsoft.Common.props" />
</Project>

MSBuildToolsVersion 11.0

7. ToolsVersion 12.0 ends up with VisualStudioVersion 10.0

<Project ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Import Project="C:\Projects\msbuild\src\XMakeTasks\Microsoft.Common.props" />
</Project>

MSBuildToolsVersion 10.0

8. ToolsVersion 14.0 ends up with VisualStudioVersion 10.0

<Project ToolsVersion="14.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Import Project="C:\Projects\msbuild\src\XMakeTasks\Microsoft.Common.props" />
</Project>

MSBuildToolsVersion 10.0

I consider 7 & 8 to be bugs. I think this is the cause:
https://github.com/Microsoft/msbuild/blob/master/src/XMakeTasks/Microsoft.Common.props#L38

More info: ctaggart/SourceLink#50 (comment)

Please look at ConfigCache.ClearConfigurations method. It uses _configurations collection which is accessed under lock in other methods of this class.

Hello I would like to use MSBuild on a buildserver without installing it or Visual Studio. I already got the VC++ compiler to run standalone on virtual machine but I also need MSBuild to build the VC++-Solution.

I noticed that the Visual C++ tasks are missing. Is it possible that you add them to the Github repository or is there a way to include the tasks and properties that are bundled with Visual Studio 2015 Preview?

Thanks in advance.

This is probably a frivolous issue, but looking at HEAD there are ~3000 unused using statements spread across >800 files spanning the project. It would be nice to clean these up a bit.

Not picking on any particular class, but lets take /src/XMakeBuildEngine/BackEnd/BuildManager/BuildRequestData.cs

This:

using System;
using System.Collections.Generic;
using System.IO;
using System.Text;

using Microsoft.Build.Collections;
using Microsoft.Build.Evaluation;
using Microsoft.Build.Shared;

can be shortened to this:

using System;
using System.Collections.Generic;

using Microsoft.Build.Collections;
using Microsoft.Build.Shared;

src/Shared/ThreadingUtilities.cs has invalid (truncated) content.

Fun than it seems to be truncated at 2048 😸

NuGet dropped MSBuild support due to a range of design flaws.

Unlike NuGet, though, other projects don't have the luxury of shipping with visual studio. Please solve this problem in a way that can help projects like Paket work out of the box.

Related:

• npm/npm#3697 (comment)
• https://social.technet.microsoft.com/Forums/en-US/e84bb703-27df-4966-bdf1-2b5760c71a1f/filesystem-path-too-long?forum=WinPreview2014Feedback

This is a universally known truth that the Windows limitation of Path Too Long is affecting almost every runtime and programming paradigm. Unfortunately, MSBuild is not different in that regard. Hopefully, someday we will see it get actually fixed by Windows team.. :)

Over at Web Essentials 2013, we are having issues packaging node.js modules into a .visx image, due to too nested dependencies. We are able to mitigate it using Pri.LongPath assembly via reflection(madskristensen/WebEssentials2013#1387 & madskristensen/WebEssentials2013#1803), which worked for a while in PreBuildTask, but now it is causing PathTooLong issue with <Copy> task on packaging the assets to visx (WebEssentials2013.csproj#L1038). Is there a way we can override the default copying behavior and use hacks like "Pri.LongPath via reflection" there as well?

This is main blocker for WE2013's vNext, which is overdue for quite some now. Any help would be much appreciated by all consumers of Web Essentials! 🎉

//cc @madskristensen, @SLaks.

Steps to reproduce

1. Build MSBuild in the Debug-MONO configuration and copy it to an Ubuntu 14.04 box with Mono 3.12.1 from the official Xamarin mono-devel package.
2. Clone https://github.com/mono/coreclr.git
3. Run mono {path to msbuild} {path to coreclr}/src/build.proj -nologo -p:OS=Unix

Expected result

Something approximating a build

Actual result

The following crash occurred:

Invalid type Microsoft.Build.Execution.BuildManager for instance field Microsoft.Build.Execution.BuildSubmission:<BuildManager>k__BackingField
MSBUILD : error MSB1025: An internal failure occurred while running MSBuild.
System.TypeLoadException: A type load exception has occurred.
  at Microsoft.Build.CommandLine.MSBuildApp.Execute (System.String commandLine) [0x00000] in <filename unknown>:0
This is an unhandled exception in MSBuild Engine -- PLEASE OPEN A BUG AGAINST THE MSBUILD TEAM.
System.TypeLoadException: A type load exception has occurred.
  at Microsoft.Build.CommandLine.MSBuildApp.Execute (System.String commandLine) [0x00000] in <filename unknown>:0

Unhandled Exception:
System.TypeLoadException: A type load exception has occurred.
  at Microsoft.Build.CommandLine.MSBuildApp.Execute (System.String commandLine) [0x00000] in <filename unknown>:0
[ERROR] FATAL UNHANDLED EXCEPTION: System.TypeLoadException: A type load exception has occurred.
  at Microsoft.Build.CommandLine.MSBuildApp.Execute (System.String commandLine) [0x00000] in <filename unknown>:0
vagrant@vagrant-ubuntu-trusty-64:/vagrant/git/msbuild/bin/Windows_NT/Debug-MONO$

Additional notes

Through further investigation, I discovered that the TypeLoadException is the result of not being able to load TPL dataflow.

I was able to fix this issue by finding the dependency in Microsoft.Build and setting Copy Local to True in the properties pane, but I don't know if this is the right solution or not.

When comparing collection length it uses the same parameter 'x' twice:
if (x.CloneCustomMetadata().Count != x.CloneCustomMetadata().Count)

Calls to SecurityUtilities.SignFile referencing a certificate that does not include a private key result in a very non-specific NullReferenceException. This would be easier for the caller to fix if a more useful message were provided.

Based on what's already thrown from that method, I would suggest something like an InvalidOperationException with the message: "MSB3487: The signing certificate does not include private key information."

https://randomascii.wordpress.com/2014/03/22/make-vc-compiles-fast-through-parallel-compilation/

Parallel compilation with VS performs really poorly.
To get any intra-project parallelization you need to explicitly set /MP in each project.
And then there are "parallel project builds" on top of that.

With the default settings this even means a worst-case of numCores ^ 2 compiler instances running and totally slowing down the system.
There should be a global scheduler to make optimal parallel builds possible.
If that's only a problem of VS please let me know.

I have run into this problem many times. I am not sure if its in the shared libs from msbuild or in visual studio. But when you for instance use wildcards and then write back a project file the wildcard gets replaced with a list of files (currently matching the wildcards) when you open and save with Visual Studio.

Not sure where this code may be, if someone can point me to it I would be happy to investigate, create some unit tests, and likely send a PR

Cheers,

Greg

After building the project for command line, a few issues I was facing was the conflict between the Powershell to figure out what msbuild was, Running msbuild says Command 'msbuild.exe' cannot be found. whereas msbuild is actually present, At the same time I have to run msbuild.exe for msbuild to be executed to execute the pre installed MsBuild from the installed Framework/vXXXXXXX. Executing msbuild from absolute path works fine.

Does building the solution automatically remove msbuild from the path ?

As seen in Fix 260 character file name length limitation, there's quite a bit of support for better longer-than-MAX_PATH-filename handling.

Will Buik's response w/regard to fixing it was:

We understand that this can be a frustrating issue, however, fixing it requires a large and complicated architectural change across different products and features including Visual Studio, TFS, MSBuild and the .NET Framework. Dedicating resources to this work item would come at the expense of many other features and innovation.

I wondered, how big can those architectural changes be (for MSBuild)?

According to Naming Files, Paths, and Namespaces: Maximum Path Length Limitation, (which I have mirrored here ):

The Windows API has many functions that also have Unicode versions to permit an extended-length path for a maximum total path length of 32,767 characters. This type of path is composed of components separated by backslashes, each up to the value returned in the lpMaximumComponentLength parameter of the GetVolumeInformation function (this value is commonly 255 characters). To specify an extended-length path, use the "\\?\" prefix. For example, "\\?\D:\very long path".
[other stuff]

Because you cannot use the "\\?\" prefix with a relative path, relative paths are always limited to a total of MAX_PATH characters.

(emphasis mine)

...Which means that wherever MSBuild uses full paths, we can should be able to just prepend "\\?\" to ask for a long path.

Of course, we'd need to rework the existing path-length-workaround hack.

This won't fix the whole ecosystem, but it'll get us just one step closer.

I'd like to fix this myself (it seems simple enough), so in accordance with:

• Contributions must be discussed with the team first, or they will likely be declined. As our process matures and our experience grows, the team expects to take larger contributions.
• Only contributions referencing an approved Issue will be accepted.

...this is the suggested issue.

I'm a native developer at heart, not an experienced C# developer, but this shouldn't require anything crazy.

Direct references to MAX_PATH:

• NativeMethods.cs#L15
• NativeMethodsShared_Tests.cs#L53
• NativeMethodsShared.cs#L318
• NativeMethodsShared.cs#L540
• NativeMethodsShared.cs#L750
• FileState.cs#L293
• ComReference.cs#L460
• TargetsFile_Test.cs#L2041

Because most project files assume that the directory path delimiter is a \, MSBuild contains a FileUtilities.FixFilePath method that is used by many tasks to ensure that paths are properly constructed when running on Unix systems.

However, some projects contain references to custom tasks that deal with file paths but do not have access to this method. (see, for example, the DownloadFile task in coreclr)

After some discussion in the coreclr chat room, it was proposed that this functionality might be best exposed as a Property Function.

Such a property function would most likely need to be a member of the MSBuild set of property functions, which are defined in IntrinsicFunctions. It would also need a name--FixFilePath might be acceptable, but I suspect that a more descriptive name would be desired.

I would be happy to submit a Pull Request if a member of the team signs off on this issue (and we agree on a name for the function)

Please take a look at its INodePacketTranslatable.Translate method. It calls to InternalTranslate method which modifies '_itemsStore' field. This field is also accessed in other methods and locks are used to ensure synchronized access. But INodePacketTranslatable.Translate method is not called under lock.