dotnet / msbuild Goto Github PK
View Code? Open in Web Editor NEWThe Microsoft Build Engine (MSBuild) is the build platform for .NET and Visual Studio.
Home Page: https://docs.microsoft.com/visualstudio/msbuild/msbuild
License: MIT License
The Microsoft Build Engine (MSBuild) is the build platform for .NET and Visual Studio.
Home Page: https://docs.microsoft.com/visualstudio/msbuild/msbuild
License: MIT License
* [Issue Guide](https://github.com/Microsoft/msbuild/wiki/Issue-Guide)
See https://github.com/Microsoft/msbuild/blob/master/README.md
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:
$(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.Happy to hear your opinion on the described issue
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 ?
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:
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.
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.
in its setter it refers to itself instead of backing field _outputEntryPoint.
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?
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:
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; }
}
MSTest isn't available cross-platform and the other dotnet open source projects like corefx migrated to xunit already.
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.
Is this TargetPlatformSdkPath assignment really necessary?
It doesn't work on Mono, and looks like the logic for getting the sdk path should all be in ToolLocationHelper.
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 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
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.
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.
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.
Related:
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.
Please consider adding support for
We already have
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.
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!
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)
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;
CI build on xplat branch should:
Right now it's the same as on master which builds (using retail msbuild) and then rebuilds (using OSS msbuild).
After Linux support, we need to add support for building on Mac (under mono).
Please look at ConfigCache.ClearConfigurations method. It uses _configurations collection which is accessed under lock in other methods of this class.
Debug-MONO
configuration and copy it to an Ubuntu 14.04 box with Mono 3.12.1 from the official Xamarin mono-devel package.mono {path to msbuild} {path to coreclr}/src/build.proj -nologo -p:OS=Unix
Something approximating a build
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$
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.
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.
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.
The method has access to _activeNodes collection which is accessed under lock in other methods of the class.
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:
the ToolsVersion
in the project file
the Microsoft.Common.props
if it exists
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
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
</Project>
MSBuildToolsVersion 4.0
VisualStudioVersion 11.0
<Project ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
</Project>
MSBuildToolsVersion 12.0
VisualStudioVersion 12.0
<Project ToolsVersion="14.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
</Project>
MSBuildToolsVersion 14.0
VisualStudioVersion 14.0
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="C:\Projects\msbuild\src\XMakeTasks\Microsoft.Common.props" />
</Project>
MSBuildToolsVersion 2.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
<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
<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)
src/Shared/ThreadingUtilities.cs has invalid (truncated) content.
Fun than it seems to be truncated at 2048 ๐ธ
Currently using the mono C# compiler. Tasks/Targets need to be updated to use Roslyn.
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.
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 .
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.
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'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 would like an option to be able to treat all warnings as errors, when running from the command line.
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.
When comparing collection length it uses the same parameter 'x' twice:
if (x.CloneCustomMetadata().Count != x.CloneCustomMetadata().Count)
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.
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>
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.
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.
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.
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."
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.