| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Mono keeps unversioned tools in the 4.5 directory, so look there
for 2.0. Additionally, most 3.5 tools are in the 2.0 directory.
|
|
Now that mcs supports multi-targeting, we can use the MSBuild 4.0+
system of finding mscorlib.dll in the target framework folders and
passing it to the compiler, along with the /nostdlib argument.
Like MSBuild, the old NoStdLib property can be set to true to disable
passing mscorlib.dll to the compiler, and the new NoCompilerStandardLib
property can be set to false to disable passing /nostdlib to the compiler.
This makes custom target frameworks work correctly without having to
override CscExe with a wrapper script.
|
|
The escaping/unescaping behaviour of TaskItem:ITaskItem was undocumented
originally in MSBuild, so our implementation did not perform any. This
caused issues with Tasks getting metadata and paths that were escaped,
trying to use them as-is, and failing horribly.
Fortunately the ITaskItem2 interface in .NET 4 provides complementary
accessors with documentation that indicates that it stores values
escaped internally, and the old accessors unescape the values.
This commit implements ITaskItem2, fixes the escaping behavior of the
old accessors, and removes some superluous uses of IDictionary.Contains.
|
|
Directory separators are automatically converted from Windows->Native
when parsing MSBuild files, but any paths provided in code must already
be native.
|
|
With tests.
|
|
This should hopefully fix compilation of projects using files with
names like 'foo@2x.png' in various places like embedded resources
or content items which must be copied to the output directory.
With tests.
|
|
|
|
|
|
It is incorrect to escape the FullPath metadata for a build item when
we invoke GetEvaluatedMetadata. If we do this we end up completely breaking
every file with a special character in it as things like this would always
fail as we'd pass an escaped path to the filesystem:
File.Exists (item.GetEvaluatedMetadata ("FullPath"))
The iOS designer encountered this issue when we added retina images
called "foo@2x.png" to our solution.
With tests.
|
|
|
|
BXC14584 - Console windows pop up during build with mono runtime
|
|
|
|
|
|
|
|
|
|
I need these projects while I'm hacking MSBuild.
This reverts commit f188c158d4643804e1fbece996fe535344fe9450.
|
|
|
|
|
|
|
|
|
|
|
|
Fix for #14922
|
|
|
|
|
|
From VS2013, MSBuild is now decouple from the .NET Framework and is a separate redistributable. This means it has a new location and version numbering scheme. There are also some addition MSBuild properties because of this
|
|
Use the same regex as xbuild uses for error parsing; see 7a2d2c24.
|
|
Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=14767
Some people, when confronted with a problem, think
“I know, I'll use regular expressions.” Now they have two problems.
- http://regex.info/blog/2006-09-15/247
ToolTask uses a regular expression to extract various bits of
information from the warning/error message. Unfortunately it was
inadequate, and didn't correctly match on some errors.
The error message in this case is:
class1.cs(16,4): error CS0152: The label `case 1:' already occurs in this switch statement.
The problem was that while the previous regular expression would
succeed in matching the above string, it was horribly inaccurate in
what it captured:
${file} = "error CS0152"
${line} = "16"
${column} = "4"
${level} = "The"
${number} = "label `case 1"
${message}= "' already occurs in this switch statement."
Did I mention hilariously wrong?
There were two problems with the previous pattern:
1. It allowed filename+(line,column) to be _repeated_, which is
clearly insane. Filename/etc. shouldn't be repeated.
2. ${number} captured ".*\d", i.e. anything ending with a number, so
when the message had a number embedded within it, it was captured.
For good measure, use RegexOptions.IgnorePatternWhitespace so that
we don't have a horrendously long regex pattern to compare for diffs
the next time this needs fixing, and add NUnit tests.
|
|
|
|
Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=10946
The scenario is the "turkish-i problem": Have an MSBuild Task Assembly
which calls ITaskItem.GetMetadata("Identity") (like, oh, the
Xamarin.Android build system...). Run in a Turkish locale (tr-TR), and
things fail badly:
Error executing task AndroidComputeResPaths: System.ArgumentException: Invalid reserved metadata name
at Mono.XBuild.Utilities.ReservedNameUtils.GetReservedMetadata (System.String itemSpec, System.String metadataName, IDictionary metadata) [0x00000] in <filename unknown>:0
at Microsoft.Build.Utilities.TaskItem.GetMetadata (System.String metadataName) [0x00000] in <filename unknown>:0
at Xamarin.Android.Tasks.AndroidComputeResPaths.Execute () [0x00000] in <filename unknown>:0
at Microsoft.Build.BuildEngine.TaskEngine.Execute () [0x00000] in <filename unknown>:0
at Microsoft.Build.BuildEngine.BuildTask.Execute () [0x00000] in <filename unknown>:0
Wat? Well, in tr-TR, "Identity".ToLower() is "ıdentity", which
doesn't match match anything in GetReservedMetadata()'s `switch`
statement, so it throws an ArgumentException. *BOOM*.
So, if you need a culture-invariant comparison, USE IT.
Related: We could have just s/ToLower/ToLowerInvariant/g, which would
have fixed the problem, but would still result in lots of string
temporaries that aren't really necessary. Use the appropriate
string.Compare() or string.Equals() methods instead to avoid the
string temporary as well.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* Microsoft.Build.Utilities/Microsoft.Build.Utilities/ToolTask.cs
(GetProcessStartInfo): Add missing api. This allows more control
over the execution of the tool.
|
|
|
|
|
|
Updating FromMSBuildPath also fixes a bug on windows.
* Microsoft.Build.Engine/Microsoft.Build.BuildEngine/Utilities.cs:
Move to..
* Microsoft.Build.Utilities/Mono.XBuild.Utilities/MSBuildUtils.cs:
.. this. Also, update FromMSBuildPath from monodevelop.
* Update Engine/* and Tasks/* to track the new api.
|
|
Use ProcessStringDictionary in ToolTask for EnvironmentVariables,
as this retains the original case of the keys. Without this
environment vars would all be passed as lowercase!
This was removed in a previous patch by mistake.
|
