xamarin
/
xamarin-android
зеркало из https://github.com/xamarin/xamarin-android.git
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность
xamarin-android/Xamarin.Android.sln

563 строки
48 KiB
Plaintext
Исходник Обычный вид История

Fix line endings
2016-07-06 18:09:45 +03:00

Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio 2012
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Build-Tools", "Build-Tools", "{E351F97D-EA4F-4E7F-AAA0-8EBB1F2A4A62}"
EndProject
Project("{9344BDBB-3E7F-41FC-A0DD-8665D75EE146}") = "android-toolchain", "build-tools\android-toolchain\android-toolchain.mdproj", "{8FF78EB6-6FC8-46A7-8A15-EBBA9045C5FA}"
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Xamarin.Android.Tools.BootstrapTasks", "src\Xamarin.Android.Tools.BootstrapTasks\Xamarin.Android.Tools.BootstrapTasks.csproj", "{E8492EFB-D14A-4F32-AA28-88848322ECEA}"
EndProject
Project("{9344BDBB-3E7F-41FC-A0DD-8665D75EE146}") = "mono-runtimes", "build-tools\mono-runtimes\mono-runtimes.mdproj", "{C03E6CF1-7460-4CDC-A4AB-292BBC0F61F2}"
EndProject
Project("{9344BDBB-3E7F-41FC-A0DD-8665D75EE146}") = "libzip", "build-tools\libzip\libzip.mdproj", "{900A0F71-BAAD-417A-8D1A-8D330297CDD0}"
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "jnienv-gen", "build-tools\jnienv-gen\jnienv-gen.csproj", "{AFB8F6D1-6EA9-42C3-950B-98F34C669AD2}"
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "api-merge", "build-tools\api-merge\api-merge.csproj", "{3FC3E78B-F7D4-42EA-BBE8-4535DF42BFF8}"
EndProject
Import remap-assembly-ref tool from monodroid/9c345513 (#348) Context: https://github.com/xamarin/xamarin-android/pull/341 `remap-assembly-ref` is utility which changes assembly references. For example, consider `mdoc.exe`: $ monodis --assemblyref bin/Debug/lib/mandroid-internal/mdoc.exe AssemblyRef Table ... 4: Version=0.10.0.0 Name=Mono.Cecil Flags=0x00000000 Public Key: ... By policy, we *don't* want to reference `Mono.Cecil.dll`, because in times past all IDE add-ins would be loaded into the same process, and if an assembly wasn't strong-named -- `Mono.Cecil.dll` isn't -- then all references to `Mono.Cecil.dll` would resolve to the same file, even if used from different add-ins which expected different Cecil versions, and things would break in horrific ways. Lots of hair-pulling ensued, and our response was to "vendorize" Cecil into [`Xamarin.Android.Cecil`][0], which is just Mono.Cecil with a different assembly name. However, we didn't want to have to rebuild everything from source "just because" the assembly name changed, and `mdoc.exe` is such an assembly. It's built as part of mono, references `Mono.Cecil.dll`, and we need it to instead reference `Xamarin.Android.Cecil.dll`. Enter `remap-assembly-ref.exe`: $ mono bin/BuildDebug/remap-assembly-ref.exe Usage: <input assembly filename> <output assembly filename> <source assembly ref> <target assembly> `remap-assembly-ref.exe` will read `<input assembly filename>`, alter all references to `<source assembly ref>` to the name and version information contained in `<target assembly>`, and write the modified assembly to `<output assembly filename>`: $ mono bin/BuildDebug/remap-assembly-ref.exe \ bin/Debug/lib/mandroid-internal/mdoc.exe \ bin/Debug/lib/mandroid/mdoc.exe \ "Mono.Cecil" \ bin/Debug/lib/mandroid/Xamarin.Android.Cecil.dll # Behold, altered assembly name reference! $ monodis --assemblyref bin/Debug/lib/mandroid/mdoc.exe ... 4: Version=0.10.0.0 Name=Xamarin.Android.Cecil Flags=0x00000001 Public Key: 0x00000000: 00 24 00 00 04 80 00 00 94 00 00 00 06 02 00 00 ... *Note*: `remap-assembly-ref.exe` is *brittle*. It does no validation that the types and members referenced from `<source assembly ref>` actually exist in `<target assembly>`, so it's entirely possible that the resulting assembly *will not work*. [0]: https://github.com/xamarin/java.interop/tree/master/src/Xamarin.Android.Cecil
2017-01-04 20:45:58 +03:00
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "remap-assembly-ref", "build-tools\remap-assembly-ref\remap-assembly-ref.csproj", "{C876DA71-8573-4CEF-9149-716D72455ED4}"
EndProject
Fix line endings
2016-07-06 18:09:45 +03:00
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Core", "Core", "{04E3E11E-B47D-4599-8AFC-50515A95E715}"
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Java.Interop", "external\Java.Interop\src\Java.Interop\Java.Interop.csproj", "{94BD81F7-B06F-4295-9636-F8A3B6BDC762}"
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "generator", "external\Java.Interop\tools\generator\generator.csproj", "{D14A1B5C-2060-4930-92BE-F7190256C735}"
EndProject
Reorganize Xamarin.Android.NamingCustomAttributes. (#139) context: https://github.com/xamarin/java.interop/issues/58 dependent on: https://github.com/atsushieno/java.interop/commit/5583d26 Copypasting the changes on Java.Interop We have complicated module interdependency between this and xamarin-android, so this set of changes is to fix the situation. So far, here is the changeset summary: - Xamarin.Android.NamingCustomAttributes.shproj is moved to xamarin-android - there will be new Java.Interop.NamingCustomAttributes.shproj which is for use in this repository. It will be shrinked in the later commits to have only required bits in Java/Interop. Now Xamarin.Android.sln has two NamingCustomAttributes.shproj: one for imported and then slightly stripped version of the original shared project in xamarin-android, and renamed and then significantly stripped version in Java.Interop. Build adjustment comes next.
2016-08-08 17:50:37 +03:00
Project("{D954291E-2A0B-460D-934E-DC6B0785DB48}") = "Java.Interop.NamingCustomAttributes", "external\Java.Interop\src\Java.Interop.NamingCustomAttributes\Java.Interop.NamingCustomAttributes.shproj", "{FE789F04-5E95-42C5-AEF1-E33F8DF06B3F}"
EndProject
Project("{D954291E-2A0B-460D-934E-DC6B0785DB48}") = "Xamarin.Android.NamingCustomAttributes", "src\Xamarin.Android.NamingCustomAttributes\Xamarin.Android.NamingCustomAttributes.shproj", "{74598F5C-B8CC-4CE6-8EE2-AB9CA1400076}"
Fix line endings
2016-07-06 18:09:45 +03:00
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Xamarin.Android.Tools.Aidl", "src\Xamarin.Android.Tools.Aidl\Xamarin.Android.Tools.Aidl.csproj", "{D27AD8F7-7710-40BE-B03B-55EFBEC13C44}"
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Xamarin.Android.Build.Tasks", "src\Xamarin.Android.Build.Tasks\Xamarin.Android.Build.Tasks.csproj", "{3F1F2F50-AF1A-4A5A-BEDB-193372F068D7}"
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Xamarin.Android.Tools.Bytecode", "external\Java.Interop\src\Xamarin.Android.Tools.Bytecode\Xamarin.Android.Tools.Bytecode.csproj", "{B17475BC-45A2-47A3-B8FC-62F3A0959EE0}"
EndProject
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Tools", "Tools", "{864062D3-A415-4A6F-9324-5820237BA058}"
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "jcw-gen", "external\Java.Interop\tools\jcw-gen\jcw-gen.csproj", "{52C7D9B6-E8C8-47D0-9471-652D278D7D77}"
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Java.Interop.Tools.JavaCallableWrappers", "external\Java.Interop\src\Java.Interop.Tools.JavaCallableWrappers\Java.Interop.Tools.JavaCallableWrappers.csproj", "{D18FCF91-8876-48A0-A693-2DC1E7D3D80A}"
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Xamarin.Android.Tools.ApiXmlAdjuster", "external\Java.Interop\src\Xamarin.Android.Tools.ApiXmlAdjuster\Xamarin.Android.Tools.ApiXmlAdjuster.csproj", "{1268EADF-8344-431C-81F6-FCB7CBC99F49}"
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Xamarin.Android.Tools.AnnotationSupport", "external\Java.Interop\src\Xamarin.Android.Tools.AnnotationSupport\Xamarin.Android.Tools.AnnotationSupport.csproj", "{07BC4495-1267-4B78-9EA6-B76FEEA2A64A}"
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Java.Interop.Tools.Diagnostics", "external\Java.Interop\src\Java.Interop.Tools.Diagnostics\Java.Interop.Tools.Diagnostics.csproj", "{64CC4E44-CE3A-4319-BF3F-6CF8BD513870}"
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Java.Interop.Tools.Cecil", "external\Java.Interop\src\Java.Interop.Tools.Cecil\Java.Interop.Tools.Cecil.csproj", "{D48EE8D0-0A0A-4493-AEF5-DAF5F8CF86AD}"
EndProject
Project("{9344BDBB-3E7F-41FC-A0DD-8665D75EE146}") = "monodroid", "src\monodroid\monodroid.mdproj", "{53EE4C57-1C03-405A-8243-8DA539546C88}"
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Xamarin.Android.NUnitLite", "src\Xamarin.Android.NUnitLite\Xamarin.Android.NUnitLite.csproj", "{4D603AA3-3BFD-43C8-8050-0CD6C2601126}"
EndProject
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Tests", "Tests", "{CAB438D8-B0F5-4AF0-BEBD-9E2ADBD7B483}"
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Xamarin.ProjectTools", "src\Xamarin.Android.Build.Tasks\Tests\Xamarin.ProjectTools\Xamarin.ProjectTools.csproj", "{2DD1EE75-6D8D-4653-A800-0A24367F7F38}"
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Xamarin.Android.Build.Tests", "src\Xamarin.Android.Build.Tasks\Tests\Xamarin.Android.Build.Tests\Xamarin.Android.Build.Tests.csproj", "{53E4ABF0-1085-45F9-B964-DCAE4B819998}"
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "System.EnterpriseServices", "src\System.EnterpriseServices\System.EnterpriseServices.csproj", "{2868FC32-A4E7-4008-87C8-2C7879CACB58}"
EndProject
Project("{9344BDBB-3E7F-41FC-A0DD-8665D75EE146}") = "unix-distribution-setup", "build-tools\unix-distribution-setup\unix-distribution-setup.mdproj", "{2CF172E5-BDAE-4ABA-8BC8-08040ED3E77A}"
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Mono.Posix", "src\Mono.Posix\Mono.Posix.csproj", "{1A4B041A-842F-40B3-A50D-49E01D30BD18}"
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "class-parse", "external\Java.Interop\tools\class-parse\class-parse.csproj", "{38C762AB-8FD1-44DE-9855-26AAE7129DC3}"
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "logcat-parse", "external\Java.Interop\tools\logcat-parse\logcat-parse.csproj", "{7387E151-48E3-4885-B2CA-A74434A34045}"
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Mono.Data.Sqlite", "src\Mono.Data.Sqlite\Mono.Data.Sqlite.csproj", "{26781D3A-FF20-4F55-9824-C8A06AA9E484}"
EndProject
Project("{9344BDBB-3E7F-41FC-A0DD-8665D75EE146}") = "sqlite-xamarin", "src\sqlite-xamarin\sqlite-xamarin.mdproj", "{B8F799C5-D7CE-4E09-9CE6-BAA4173E7EC8}"
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "OpenTK", "src\OpenTK-1.0\OpenTK.csproj", "{5EB9E888-E357-417E-9F39-DDEC195CE47F}"
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "libZipSharp", "external\LibZipSharp\libZipSharp.csproj", "{E248B2CA-303B-4645-ADDC-9D4459D550FD}"
EndProject
Build netstandard.dll and System.Drawing.Primitives.dll facades (#572) Build `netstandard.dll` and `System.Drawing.Primitives.dll` facades The old project for `System.Drawing.Primitives` was removed in favor of building the assembly with the existing logic in Mono. Also add them to the bundle since we can't rebuild them if we just have the bundle. Update facades list in `MobileProfile.cs`; `netstandard.dll` and `System.ValueTuple.dll` were missing.
2017-04-21 23:06:08 +03:00
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "System.Drawing.Primitives", "src\System.Drawing.Primitives\System.Drawing.Primitives.mdproj", "{C9FF2E4D-D927-479E-838B-647C16763F64}"
[System.Drawing.Primitives] Add System.Drawing.Primitives.dll Facade (#121) Xamarin.Android needs to support [.NET Standard 1.6][0], which mentions a [`System.Drawing.Primitives.dll` assembly][1] which has not previously been supported or shipped. `System.Drawing.Primitives.dll` contains `System.Drawing.Point` and related typees, which Xamarin.Android places into `Mono.Android.dll`. Add a new `System.Drawing.Primitives.dll` assembly to use as a *facade assembly*, which contains [type forwarders][2] to "redirect" the types from `System.Drawing.Primitives.dll` to the corresponding types within `Mono.Android.dll`. [0]: https://docs.microsoft.com/en-us/dotnet/articles/core/tutorials/libraries [1]: https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md#list-of-net-corefx-apis-and-their-associated-net-platform-standard-version [2]: https://msdn.microsoft.com/en-us/library/ms404275(v=vs.110).aspx
2016-07-15 23:42:03 +03:00
EndProject
[bundle] Add `CreateBundle` target. (#140) Building Mono on Windows is a PITA, and commit 0c073f67 added support to cross-compile Mono for Windows so that Mono could be built from macOS or Linux. The unstated goal of that work was to -- eventually -- build the Mono runtimes *for Windows* on e.g. macOS, *bundle* those runtimes, and then we could update the build process to *download* a pre-built bundle of mono runtimes so that we can ~sanely build xamarin-android on Windows without building *Mono* on Windows. Part Two of this cunning plan involves creating the bundle of built mono runtimes. This in turn got rather complicated because instead of doing the *simple* thing of invoking **zip**(1), I instead wanted to create and use a `<Zip/>` MSBuild task, as this would allow us to specify in one place -- `mono-runtimes.targets` -- which files should be bundled, instead of bundling e.g. everything in `bin/Debug`, which would grab considerably more than just the mono bits. Adding a `<Zip/>` task in turn involves determining which Zip implementation to use, and what assembly to put it in; the obvious answer is to use `libzip`/`libZipSharp.dll` and place it into `Xamarin.Android.Tools.BootstrapTasks.dll` -- which is how we did it -- but this answer was tricky, due to a circular dependency problem: `libzip.mdproj` depends on `android-runtimes.mdproj` which depends on `Xamarin.Android.Tools.BootstrapTasks.dll`. Consequently, adding `libzip.mdproj` as a dependency to `Xamarin.Android.Tools.BootstrapTasks.dll` *doesn't work*. (Question: Why use libzip? Why not use System.IO.Compression? Answer: Because I'd like to be able to update the `<UnzipDirectoryChildren/>` task to use `libzip` instead of "shelling out" to **zip**(1) *like an animal*.) Step 1 is removing the circular dependency. `libzip.mdproj` depends on `android-runtimes.mdproj` because of MXE: `android-runtimes.mdproj` configures the MXE build environment to generate a Windows `libzip.dll` native library, if needed. The fix: introduce a new `libzip-windows.mdproj` project which performs the MXE-based build. This allows `libzip.mdproj` to no longer depend on `android-runtimes.mdproj`; `libzip-windows.mdproj` does. This also involves "refactoring" `libzip.mdproj` so that the build logic can be shared with `libzip-windows.mdproj`. Additionally, improve `libzip.mdproj` so that the native libraries are also set as a `@(Content)` build action. This allows e.g. `libzip.3.0.dylib` to be properly copied into `bin/BuildDebug`, as that's the `$(OutputPath)` of `Xamarin.Android.Tools.BootstrapTasks.csproj`. Step 2 is adding `libZipSharp.csproj` as a `@(ProjectReference)` to `Xamarin.Android.Tools.BootstrapTasks.csproj`. This requires bumping `Xamarin.Android.Tools.BootstrapTasks.csproj` to target .NET 4.5.1, which allows us to add the new `<Zip/>` task, as well as a new `<GitCommit/>` task (so we can determine the abbreviated commit hash of the mono checkout, for encoding into the filename). Step 3 is updating `mono-runtimes.targets` so that the Windows cross-compilers are built into `bin/$(Configuration)/lib/mandroid`, as this matches what is currently done internally. Step 4 is adding a new `build-tools/bundle.mdproj` project with a `CreateBundle` targtet, which will create the file: $(OutputPath)\bundle-$(Configuration)-libzip=$(libzip-hash),llvm=$(llvm-hash),mono=$(mono-hash).zip`. Uploading the `bundle-*.zip` files will be handled by Jenkins as a post-build task. Not yet done: *using* `bundle-*.zip` so that mono/etc. builds can be skipped, *greatly* improving build times.
2016-08-11 00:28:53 +03:00
Project("{9344BDBB-3E7F-41FC-A0DD-8665D75EE146}") = "libzip-windows", "build-tools\libzip-windows\libzip-windows.mdproj", "{0DE278D6-000F-4001-BB98-187C0AF58A61}"
EndProject
Project("{9344BDBB-3E7F-41FC-A0DD-8665D75EE146}") = "bundle", "build-tools\bundle\bundle.mdproj", "{1640725C-4DB8-4D8D-BC96-74E688A06EEF}"
EndProject
[xa-prep-tasks] Use the Mono bundle (#162) Context: https://github.com/xamarin/xamarin-android/commit/fbfd676c102c63e4e06e750857b178725e33450c Stage 3 of the cunning plan is to (attempt to) use the mono bundle introduced in commit fbfd676c. This "simple" desire (ha!) re-raises the architectural project dependency issue "solved" in fbfd676c, but first, a simple question: What should download the mono bundle? There are two plausible answers: 1. `make prepare` can (somehow) handle it. 2. MSBuild can (somehow) handle it. Both are plausible. The problem with using `make` targets (1) is there is increased potential for "duplication" -- duplication of the bundle filename, downloading it, and extracting it. Plus, `make` isn't "Windows friendly", in that GNU make isn't (normally) present with Visual Studio. (`NMAKE` is, but the Makefiles in this project are not compatible with `NMAKE`.) Which brings us to MSBuild (2): can it handle the task? To tackle that, we need to be able to have an MSBuild task project which has *no dependencies*, so that it can download and extract the mono bundle *before anything else runs*, as it may be downloading contents which mean that other projects don't *need* to run. The need for a "pre-bootstrap" task assembly -- called `xa-prep-tasks` -- thus "undoes" *some* of the logic regarding `libzip-windows.mdproj` and the `<Zip/>` task from fbfd676c: it isn't *possible* to rely on `libzip` from a "pre-build" state, as `libzip` is one of the things in the mono bundle, so now we need *two* "bootstrap" task assemblies: one without a `libzip` dependency -- `xa-prep-tasks.dll` -- and one *with* a `libzip` dependency -- `Xamarin.Android.Tools.BootstrapTasks.dll` Move tasks which don't currently require `libzip` -- or won't in the future, or laziness -- from `Xamarin.Android.Tools.BootstrapTasks.dll` and move them into `xa-prep-tasks.dll`. With that architectural compromise in place, add `xa-prep-tasks` as a `@(ProjectReference)` to various projects to help ensure it's built *first*, and rearchitect `bundle.mdproj` so that `xa-prep-tasks.targets` and `bundle.targets` can use the same targets to compute the bundle filename, now in `build-tools/bundle/bundle-path.targets`. Add a post-build step to `xa-prep-tasks.csproj` which downloads and extracts the expected mono bundle. One "problem" (feature?) is that the new `<SystemUnzip/>` task doesn't report errors as errors when unzip'ing the file. This turns out to be fine here because when downloading the mono bundle from Azure we don't get a 404 *anyway* -- Azure instead returns an XML document containing an error message (wat?!). We can thus ignore most error handling entirely...though we're *also* ignoring any checking for invalid downloads, which is something we should address in the future. Update the varioous project files so that they won't attempt to rebuild binaries that were present in the mono bundle.
2016-08-16 23:02:48 +03:00
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "xa-prep-tasks", "build-tools\xa-prep-tasks\xa-prep-tasks.csproj", "{7CE69551-BD73-4726-ACAA-AAF89C84BAF8}"
EndProject
Bump to Java.Interop/f44a11f6 and use its Cecil library (#303) Updated all the projects to use the `Xamarin.Android.Cecil` library instead of `Mono.Cecil` nuget package.
2016-11-18 18:04:49 +03:00
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Xamarin.Android.Cecil", "external\Java.Interop\src\Xamarin.Android.Cecil\Xamarin.Android.Cecil.csproj", "{15945D4B-FF56-4BCC-B598-2718D199DD08}"
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Xamarin.Android.Cecil.Mdb", "external\Java.Interop\src\Xamarin.Android.Cecil\Xamarin.Android.Cecil.Mdb.csproj", "{C0487169-8F81-497F-919E-EB42B1D0243F}"
EndProject
[build] Auto-Provision Dependencies (#447) The #runtime team is requesting that Xamarin.Android support "auto-provisioning": the ability to track dependency *versions*, and if there is a "version mismatch", *install* a dependency that satisfies the minimum. The primary use case is Mono itself: there is a desire to build xamarin-android *itself* against mono/master, to see what breaks. (Does the C# compiler break things? Does the JIT hang? etc.) Extend the existing `@(RequiredProgram)` infrastructure to attempt to support this: * `%(RequiredProgram.MinimumVersion)`: The minimum program version that is supported. * `%(RequiredProgram.MaximumVersion)`: The maximum program version that is supported. * `%(RequiredProgram.CurrentVersionCommand)`: A command to execute to obtain the current program version. Defaults to `%(RequiredProgram.Identity) --version`. * `%(RequiredProgram.MinimumUrl)`: URL to download "something" to use to obtain a version of the program that satisfies `%(MinimumVersion)`. * `%(RequiredProgram.Install)`: Command to execute which installs the minimum version of the program. `%(RequiredProgram.CurrentVersionCommand)`, `%(RequiredProgram.MinimumUrl)`, and `%(RequiredProgram.Install)` can all be "overridden" for platform-specific values by prefixing the value with `$(HostOSName)` and/or `$(HostOS)`. Thus, macOS-specific values can be stored into e.g. `%(RequiredProgram.DarwinMinimumUrl)` and `%(RequiredProgram.DarwinInstall)`. Auto-Provisioning is controlled by the new `$(AutoProvision)` property, which can be provided in `Configuration.Override.props`. It defaults to `False`. If the `$(AutoProvisionUsesSudo)` MSBuild property is True, then `sudo` is used to invoke all install commands.
2017-02-16 19:37:28 +03:00
Project("{9344BDBB-3E7F-41FC-A0DD-8665D75EE146}") = "dependencies", "build-tools\dependencies\dependencies.mdproj", "{C845ECC0-2ED3-498E-8EA8-02EF7AC6E9AD}"
EndProject
[Xamarin.Android.Build.Tasks] Use GPL'd ProGuard (#386) **Background**: many Android SDK features rely on [ProGuard][0], a Java bytecode manipulation library. Some of these features include linking (shrinking) bytecode and [multidex][1]. Xamarin.Android has historically relied on the version of ProGuard bundled with the Android SDK, which is how the `<Proguard/>` task and `@(ProguardConfiguration)` build actions work. Unfortunately, the version of ProGuard bundled with the Android SDK is, at this point, *ancient* (ProGuard v4.7; current version is v5.3), and (more importantly) ProGuard v4.7 doesn't support JDK 1.8 bytecode. Meaning if the end-developer references a Java library targeting JDK 1.8 -- e.g. the Android Support Library v25 -- then the version of ProGuard bundled with the Android SDK *cannot process that library*. This in turn means that the `<Proguard/>` task and `@(ProguardConfiguration)` build actions don't work/are useless. Native Java development "works around" this problem by using Gradle as the build system, and Java projects are configured to download and install a newer version of ProGuard via Gradle. Xamarin.Android projects do not use Gradle, nor will they. (At least not in the foreseeable future.) **Solution**: We have communicated with Eric Lafortune, maintainer of ProGuard, about distributing a newer ProGuard with Xamarin.Android. He replied: > From a licensing point of view, you shouldn't need an exception to > the GPL in many practical configurations: > > * if you indeed run ProGuard in a separate JVM The `<Proguard/>` task is a [`ToolTask`][2], which operates by creating a new process to invoke the specified tool. We thus are *already* using ProGuard within a "separate JVM", and no architectural change is required to comply with ProGuard's licensing without altering Xamarin.Android's licensing. The current ProGuard sources (v5.3.2) have been imported into the [xamarin/proguard][3] module, and we will be using the `xamarin/proguard` module as a git submodule for build purposes. [0]: https://www.guardsquare.com/en/proguard [1]: https://developer.android.com/studio/build/multidex.html [2]: https://msdn.microsoft.com/en-us/library/microsoft.build.utilities.tooltask.aspx [3]: http://github.com/xamarin/proguard/
2017-03-06 18:00:36 +03:00
Project("{9344BDBB-3E7F-41FC-A0DD-8665D75EE146}") = "proguard", "src\proguard\proguard.mdproj", "{4B9D96BB-95AB-44E8-9F87-13B12C8BCED1}"
EndProject
[api-xml-adjuster] move from tools to build-tools (#485) It is build-time tool and should not be used in any production environment.
2017-03-15 16:46:20 +03:00
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "api-xml-adjuster", "build-tools\api-xml-adjuster\api-xml-adjuster.csproj", "{8A6CB07C-E493-4A4F-AB94-038645A27118}"
EndProject
[javadoc2mdoc] import javadoc-to-mdoc from monodroid/fbb0c9d (#500) ... with some changes: - It turned out that we don't have Ionic.Zip, so it is replaced with LibZipSharp (with new entry removal methods thanks to grendel). - We don't import README.samples that indicates some internals. javadoc-to-mdoc is a tool that converts Javadocs or DroidDocs into monodoc format. Then it can be converted to C# docs (csc /doc) or HTML using "mdoc" tool in mono (we also build and ship it within `lib/mandroid`).
2017-03-17 21:18:55 +03:00
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Xamarin.Android.Tools.JavadocImporter", "src\Xamarin.Android.Tools.JavadocImporter\Xamarin.Android.Tools.JavadocImporter.csproj", "{E0890301-F75F-40E7-B008-54C28B3BA542}"
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "javadoc2mdoc", "tools\javadoc2mdoc\javadoc2mdoc.csproj", "{A87352E6-CE7F-4346-B6B1-586AE931C0A7}"
EndProject
[Xamarin.Android.Build.Tests] Move tests into a Shared Project so they can be reused upstream. (#506) Rather than have all the msbuild tests in an assembly this commit moves them into a shared project. This means the source code for the tests can be easily reused upstream. It also means we can make use of things like partial classes to change the tests depending on which repo we are running them from. For example having tests in this repo only run in Release mode but have both Release and Debug upstream.
2017-03-20 19:05:23 +03:00
Project("{D954291E-2A0B-460D-934E-DC6B0785DB48}") = "Xamarin.Android.Build.Tests.Shared", "src\Xamarin.Android.Build.Tasks\Tests\Xamarin.Android.Build.Tests\Xamarin.Android.Build.Tests.Shared.shproj", "{BD1D66BF-5AC7-4926-8EBE-B2198A112EB0}"
EndProject
[create-vsix] Create `.vsix` files (#541) Visual Studio 2017 uses `.vsix` files for Xamarin.Android SDK support. A `.vsix` file is [ZIP container with additional metadata][0], and the [Microsoft.VSSDK.BuildTools NuGet package][1] contains various MSBuild targets and tools to assist in creating `.vsix` files. Add a new `build-tools/create-vsix/create-vsix.csproj` project to create the `bin/Build$(Configuration)/Xamarin.Android.Sdk*.vsix` file, so that we can plausibly provide per-build OSS Xamarin.Android releases that work with Visual Studio 2017. Unfortunately those tools were written on Windows, and not really well tested on macOS or Linux... In particular, there are case-sensitivity and directory-separator-char issues with the tooling, necessitating that `MONO_IOMAP=all` be exported in order to run them: MONO_IOMAP=all MONO_OPTIONS=--arch=64 msbuild \ build-tools/create-vsix/create-vsix.csproj /p:CreateVsixContainer=True Meanwhile, we're still attempting to allow things to be built with `xbuild` [^3]. Thread this needle by "special-casing" the `$(BuildDependsOn)`, `$(CopyVsixManifestFileDependsOn)`, and `$(DetokenizeVsixManifestFileDependsOn)` MSBuild properties so that when the `$(CreateVsixContainer)` MSBuild property is False -- the default -- no `.vsix` package will be created, and `xbuild` will be able to build the project. Similar needle threading is needed to "support" building on Linux: the Microsoft.VSSDK.BuildTools NuGet package uses case in an inconsistent fashion -- or is it `nuget`? -- which results in [failures when building on Linux][2] because `nuget` extracts e.g.: packages/Microsoft.VSSDK.BuildTools.15.0.26201/tools/vssdk/Microsoft.VsSDK.targets while Microsoft.VSSDK.BuildTools attempts to `<Import/>` the file: packages/Microsoft.VSSDK.BuildTools.15.0.26201/tools/VSSDK/Microsoft.VsSDK.targets `vssdk` != `VSSDK` on case-sensitive filesystems, so this results in an error on Ubuntu (and presumably case-senstive macOS as well). Handle the Linux case by extending the `xbuild` case: *even when* `$(CreateVsixContainer)` is True, we won't actually build the `.vsix` unless the `$(VsSDKInstall)` directory exists, which is the `tools/VSSDK` path. Building with `$(CreateVsixContainer)` set to True will require using `msbuild` with `MONO_IOMAP=all` and `MONO_OPPTIONS=--arch=64` exported, while using a case-insensitive filesystem. The new `make create-vsix CONFIGURATIONS=Debug` target can be used to explicitly create the `Xamarin.Android.Sdk*.vsix` file. One problem with creating `.vsix` files: macOS still defaults to using a 32-bit process for `mono`, and `make create-vsix` regularly fails for me with an `OutOfMemoryException` when attempting to generate a `.vsix` file ~600-700+MB in size. (Why so large? In part because for Debug configuration we're including un-`strip`'d native libraries; `libmonosgen-2.0.dll` is *237MB* in size (!); it's closer to 5MB when `strip`'d, but any un-`strip`'d MXE-generated native libraries to the `.vsix` file quickly results in `OutOfMemoryException`s.) A 64-bit mono can be used by using `mono64` -- which isn't easily done with `msbuild` -- or by using `mono --arch=64`, which *can* be done with `msbuild` by exporting `MONO_OPTIONS=--arch=64`. The `make create-vsix` target does this. Finally, once we have a `.visx` being created, we then examine the *contents* of the `.vsix` file, which is...weird: $MSBuild/Xamarin/Android/Xamarin.Android.CSharp.targets # Desirable $ReferenceAssemblies/Microsoft/Framework/MonoAndroid/v1.0/Xamarin.Android.CSharp.targets # wat? $ReferenceAssemblies/Microsoft/Framework/MonoAndroid/v1.0/Facades/Xamarin.Android.CSharp.targets # really?! $ReferenceAssemblies/Microsoft/Framework/MonoAndroid/v7.1/Xamarin.Android.CSharp.targets # !!!! Turns Out™, the problem was due to `@(ProjectReference)`. We're (ab)using `@(ProjectReference)` to explicitly specify project dependencies, and the (implicit) project build order. Unexpectedly (forgetten?), MSBuild *also* copies the *outputs* of `@(ProjectReference)`s into the `$(OutputPath)` of the current project. Since e.g. `Mono.Posix.csproj` had a reference on `Xamarin.Android.Build.Tasks.csproj`, the result of this is that the `$(OutputPath)` of `Mono.Posix.csproj` -- `$prefix/lib/xbuild-frameworks/MonoAndroid/v1.0` -- also contained the `%(None.CopyToOutputDirectory)` items from `Xamarin.Android.Build.Tasks.csproj`. Oops. The fix is to set `%(ProjectReference.Private)` to False, which disables this copying of additional and undesirable files. [0]: https://msdn.microsoft.com/en-us/library/dd997148.aspx [1]: https://www.nuget.org/packages/Microsoft.VSSDK.BuildTools/ [2]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-anroid-linux-pr-builder/297/consoleText [^3]: But for how much longer?
2017-04-05 18:49:37 +03:00
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "create-vsix", "build-tools\create-vsix\create-vsix.csproj", "{94756FEB-1F64-411D-A18E-81B5158F776A}"
EndProject
Build netstandard.dll and System.Drawing.Primitives.dll facades (#572) Build `netstandard.dll` and `System.Drawing.Primitives.dll` facades The old project for `System.Drawing.Primitives` was removed in favor of building the assembly with the existing logic in Mono. Also add them to the bundle since we can't rebuild them if we just have the bundle. Update facades list in `MobileProfile.cs`; `netstandard.dll` and `System.ValueTuple.dll` were missing.
2017-04-21 23:06:08 +03:00
Project("{9344BDBB-3E7F-41FC-A0DD-8665D75EE146}") = "netstandard", "src\netstandard\netstandard.mdproj", "{93614CB8-4564-43B9-93B0-4AF4B3B16AAE}"
EndProject
[Xamarin.Android.Build.Tasks] Use Xamarin.Android.Tools.AndroidSdk (#835) There is some code which is conceptually, if not literally, duplicated between the xamarin-android and the IDEs (Visual Studio, Visual Studio for Mac), in particular code that deals with finding the Android SDK and Java JDK locations. This code has been split out into a new `xamarin-android-tools` repo to facilitate sharing, without the IDEs needing to submodule xamarin-android, which is quite large. Cleanup the xamarin-android repo to use the new xamarin-android-tools repo for Android SDK information/etc.
2017-09-13 13:08:52 +03:00
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "setup-windows", "tools\setup-windows\setup-windows.csproj", "{73DF9E10-E933-4222-B8E1-F4536FFF9FAD}"
[setup-windows] Provide a Windows installer (#708) I really didn't want to do this. I wanted the Xamarin.Android SDK on Windows to be usable side-by-side, so that multiple `oss-xamarin.android*.zip` files could be extracted, and developers could switch between them by overriding MSBuild properties. This is what was documented in commit 87ca2737, by overriding the `$(TargetFrameworkRootPath)` MSBuild property. There's just one "minor" problem with that approach: it only works if the project that is being built, and *all* project dependencies, are Xamarin.Android projects. If *any* other kind of dependency is brought in, this approach will no longer work, as the `GetReferenceAssemblies` target -- which looks for assemblies *rooted within `$(TargetFrameworkRootPath)`* -- won't be able to find them. Unfortunately, *everything of interest* doesn't fit within this restriction. A Xamarin.Forms app, or any other app using PCL assemblies, quickly runs afoul of it: error MSB3644: The reference assemblies for framework ".NETPortable,Version=v4.5,Profile=Profile259" were not found. Consequently, the instructions from commit 87ca2737 are borderline worthless. There is only one way to actually build such projects, and that's to install Xamarin.Android *system-wide*, so that MSBuild's `GetReferenceAssemblies` target can find everything it needs. :-( Thus, we need an "installer." I was hoping for a simple `.cmd` file, but that stymied me. Then I hoped for a PowerShell script, but installation requires access to the `%VSINSTALLDIR%` environment variable, which is only exported from Visual Studio Developer Command Prompts, and all the solutions I found to import the VS command prompt environment info into PowerShell looked decidedly ugly. Which brings us to a minimal effort command-line installer: `setup-windows.exe`. This utility backs up existing installs, then creates symbolic links within the system-wide directories, pointing them into the extracted `oss-xamarin.android*.zip` contents which contains `setup-windows.exe`. `setup-windows.exe /uninstall` is also provided, to put directories back the way they were found. `Documentation/UsingJenkinsBuildArtifacts.md` has been updated accordingly.
2017-07-31 13:51:51 +03:00
EndProject
[xabuild.exe] cross-platform form of tools/scripts/xabuild (#910) Context: https://github.com/jonathanpeppers/xabuild What do we want? A *usable*, *parallel*, build tree. To elaborate: we want to be able to have a "system" Xamarin.Android install, and a "parallel" xamarin-android install, and be able to *easily* switch between the two. (For various definitions of "easy"; here, we mean *command-line* use, not IDE use.) On macOS, this (more or less) Just Works™, and is extremely handy for testing bug fixes: $ xbuild /t:Install Project.csproj # Verify that some bug is triggered $ xbuild /t:Uninstall Project.csproj $ tools/scripts/xabuild /t:Install Project.csproj # Verify that some bug is *fixed* There's One Problem™ with this: MSBuild does not make this easy. (Related: commit aa1db830.) Apps may rely on files located within `$(MSBuildExtensionsPath)` or `$(TargetFrameworkRootPath)`, files such as PCL profile assemblies, or 3rd party frameworks. Meanwhile, on macOS, `xabuild` is *predicated* upon overriding `$(TargetFrameworkRootPath)` and `$(MSBuildExtensionsPath)` and `$(XBUILD_FRAMEWORK_FOLDERS_PATH)`, and creating a bunch of symlinks to "fake out" `msbuild.exe` so that system-installed files such as PCL assemblies can be found *through* the parallel environment. It kinda/sorta works on macOS. It completely falls apart when using Windows. There is no easy "symlink half the world" solution there. Overriding `$(MSBuildExtensionsPath)` means that `Microsoft.Common.targets` can't be found. Overriding `$(TargetFrameworkRootPath)` means PCL files can't be found. It's a mess. Fortunately, more recent versions of MSBuild allow for some of these properties to contain *multiple* directories instead of a single directory, which means *there is a way* to support our desired usable parallel install world order. We "just" need to e.g. force `$(MSBuildExtensionsPath)` to contain *both* the in-tree directory *and* the system directory: ```xml <MSBuildExtensionsPath>In-Tree Directory; System Directory</MSBuildExtensionsPath> ``` Unfortunately, *this isn't easy*. Not all of these properties can be overridden on the `msbuild.exe` command line. Worse, MSBuild doesn't allow `;` to be part of a property value, as `;` is a property name [separator char](https://msdn.microsoft.com/en-us/library/ms164311.aspx) msbuild.exe /property:WarningLevel=2;OutDir=bin\Debug The way to force MSBuild to accept multiple paths in a property value is by providing a `.exe.config` file with the appropriate values. ~~ Enter `xabuild.exe` ~~ `xabuild.exe` is a nice wrapper around MSBuild for compiling Xamarin.Android projects using a locally built version of Xamarin.Android on your system. It seems to work on Windows, macOS, and Linux and doesn’t require elevation or modifications to your system. `xabuild.exe` works by doing the following: 1. Reference `MSBuild.exe` or `MSBuild.dll` depending on the platform 2. Creates symbolic links to `.NETPortable` and `.NETFramework` directories inside the Xamarin.Android build output directory 3. Overrides MSBuild's `app.config` file to set various properties, such as `$(MSBuildExtensionsPath)`. 4. Run MSBuild’s `Main()` method ~~ Usage ~~ On macOS, `tools/scripts/xabuild` has been updated to use `xabuild.exe` when `$MSBUILD` is `msbuild: $ MSBUILD=msbuild tools/scripts/xabuild /t:SignAndroidPackage samples/HelloWorld/HelloWorld.csproj When `$MSBUILD` is `xbuild` (the current default), the previous behavior of overriding `$MSBuildExtensionsPath` and `$XBUILD_FRAMEWORK_FOLDERS_PATH` is still used. On Windows, MSBuild 15.3 from Visual Studio 2017 is required. Simply execute `xabuild.exe`: > bin\Debug\bin\xabuild.exe Xamarin.Android-Tests.sln /p:XAIntegratedTests=False Before `xabuild.exe` existed, `setup-windows.exe` would need to be executed (as Administrator!) in order for `Xamarin.Android-Tests.sln` to be built using `msbuild.exe`.
2017-10-14 00:05:13 +03:00
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "xabuild", "tools\xabuild\xabuild.csproj", "{B7A457E6-9CB6-43F6-BFD6-14D5397FB98D}"
EndProject
[Xamarin.Android.Build.Tasks] Use Xamarin.Android.Tools.AndroidSdk (#835) There is some code which is conceptually, if not literally, duplicated between the xamarin-android and the IDEs (Visual Studio, Visual Studio for Mac), in particular code that deals with finding the Android SDK and Java JDK locations. This code has been split out into a new `xamarin-android-tools` repo to facilitate sharing, without the IDEs needing to submodule xamarin-android, which is quite large. Cleanup the xamarin-android repo to use the new xamarin-android-tools repo for Android SDK information/etc.
2017-09-13 13:08:52 +03:00
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Mono.Android", "src\Mono.Android\Mono.Android.csproj", "{66CF299A-CE95-4131-BCD8-DB66E30C4BF7}"
[setup-windows] Provide a Windows installer (#708) I really didn't want to do this. I wanted the Xamarin.Android SDK on Windows to be usable side-by-side, so that multiple `oss-xamarin.android*.zip` files could be extracted, and developers could switch between them by overriding MSBuild properties. This is what was documented in commit 87ca2737, by overriding the `$(TargetFrameworkRootPath)` MSBuild property. There's just one "minor" problem with that approach: it only works if the project that is being built, and *all* project dependencies, are Xamarin.Android projects. If *any* other kind of dependency is brought in, this approach will no longer work, as the `GetReferenceAssemblies` target -- which looks for assemblies *rooted within `$(TargetFrameworkRootPath)`* -- won't be able to find them. Unfortunately, *everything of interest* doesn't fit within this restriction. A Xamarin.Forms app, or any other app using PCL assemblies, quickly runs afoul of it: error MSB3644: The reference assemblies for framework ".NETPortable,Version=v4.5,Profile=Profile259" were not found. Consequently, the instructions from commit 87ca2737 are borderline worthless. There is only one way to actually build such projects, and that's to install Xamarin.Android *system-wide*, so that MSBuild's `GetReferenceAssemblies` target can find everything it needs. :-( Thus, we need an "installer." I was hoping for a simple `.cmd` file, but that stymied me. Then I hoped for a PowerShell script, but installation requires access to the `%VSINSTALLDIR%` environment variable, which is only exported from Visual Studio Developer Command Prompts, and all the solutions I found to import the VS command prompt environment info into PowerShell looked decidedly ugly. Which brings us to a minimal effort command-line installer: `setup-windows.exe`. This utility backs up existing installs, then creates symbolic links within the system-wide directories, pointing them into the extracted `oss-xamarin.android*.zip` contents which contains `setup-windows.exe`. `setup-windows.exe /uninstall` is also provided, to put directories back the way they were found. `Documentation/UsingJenkinsBuildArtifacts.md` has been updated accordingly.
2017-07-31 13:51:51 +03:00
EndProject
[Xamarin.Android.Build.Tasks] Use Xamarin.Android.Tools.AndroidSdk (#835) There is some code which is conceptually, if not literally, duplicated between the xamarin-android and the IDEs (Visual Studio, Visual Studio for Mac), in particular code that deals with finding the Android SDK and Java JDK locations. This code has been split out into a new `xamarin-android-tools` repo to facilitate sharing, without the IDEs needing to submodule xamarin-android, which is quite large. Cleanup the xamarin-android repo to use the new xamarin-android-tools repo for Android SDK information/etc.
2017-09-13 13:08:52 +03:00
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Mono.Android.Export", "src\Mono.Android.Export\Mono.Android.Export.csproj", "{B8105878-D423-4159-A3E7-028298281EC6}"
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Xamarin.Android.Tools.AndroidSdk", "external\xamarin-android-tools\src\Xamarin.Android.Tools.AndroidSdk\Xamarin.Android.Tools.AndroidSdk.csproj", "{E34BCFA0-CAA4-412C-AA1C-75DB8D67D157}"
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Xamarin.Android.Tools.AndroidSdk-Tests", "external\xamarin-android-tools\src\Xamarin.Android.Tools.AndroidSdk\Tests\Xamarin.Android.Tools.AndroidSdk-Tests.csproj", "{1E5501E8-49C1-4659-838D-CC9720C5208F}"
[setup-windows] Provide a Windows installer (#708) I really didn't want to do this. I wanted the Xamarin.Android SDK on Windows to be usable side-by-side, so that multiple `oss-xamarin.android*.zip` files could be extracted, and developers could switch between them by overriding MSBuild properties. This is what was documented in commit 87ca2737, by overriding the `$(TargetFrameworkRootPath)` MSBuild property. There's just one "minor" problem with that approach: it only works if the project that is being built, and *all* project dependencies, are Xamarin.Android projects. If *any* other kind of dependency is brought in, this approach will no longer work, as the `GetReferenceAssemblies` target -- which looks for assemblies *rooted within `$(TargetFrameworkRootPath)`* -- won't be able to find them. Unfortunately, *everything of interest* doesn't fit within this restriction. A Xamarin.Forms app, or any other app using PCL assemblies, quickly runs afoul of it: error MSB3644: The reference assemblies for framework ".NETPortable,Version=v4.5,Profile=Profile259" were not found. Consequently, the instructions from commit 87ca2737 are borderline worthless. There is only one way to actually build such projects, and that's to install Xamarin.Android *system-wide*, so that MSBuild's `GetReferenceAssemblies` target can find everything it needs. :-( Thus, we need an "installer." I was hoping for a simple `.cmd` file, but that stymied me. Then I hoped for a PowerShell script, but installation requires access to the `%VSINSTALLDIR%` environment variable, which is only exported from Visual Studio Developer Command Prompts, and all the solutions I found to import the VS command prompt environment info into PowerShell looked decidedly ugly. Which brings us to a minimal effort command-line installer: `setup-windows.exe`. This utility backs up existing installs, then creates symbolic links within the system-wide directories, pointing them into the extracted `oss-xamarin.android*.zip` contents which contains `setup-windows.exe`. `setup-windows.exe /uninstall` is also provided, to put directories back the way they were found. `Documentation/UsingJenkinsBuildArtifacts.md` has been updated accordingly.
2017-07-31 13:51:51 +03:00
EndProject
Fix line endings
2016-07-06 18:09:45 +03:00
Global
GlobalSection(SolutionConfigurationPlatforms) = preSolution
Debug|AnyCPU = Debug|AnyCPU
Release|AnyCPU = Release|AnyCPU
XAIntegrationDebug|AnyCPU = XAIntegrationDebug|AnyCPU
XAIntegrationRelease|AnyCPU = XAIntegrationRelease|AnyCPU
EndGlobalSection
GlobalSection(ProjectConfigurationPlatforms) = postSolution
{3F1F2F50-AF1A-4A5A-BEDB-193372F068D7}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
{3F1F2F50-AF1A-4A5A-BEDB-193372F068D7}.Debug|AnyCPU.Build.0 = Debug|Any CPU
{3F1F2F50-AF1A-4A5A-BEDB-193372F068D7}.Release|AnyCPU.ActiveCfg = Release|Any CPU
{3F1F2F50-AF1A-4A5A-BEDB-193372F068D7}.Release|AnyCPU.Build.0 = Release|Any CPU
Sanitize Xamarin.Android.sln: fix several inconsistency bits. (#1159) Manually editing solution file is uncool and error prone, but since the entire xamarin-android source tree is not designed cleanly it is impossible to use IDEs to do the right job. As stated at https://github.com/xamarin/xamarin-android/issues/1129 , we should eliminate this Xamarin.Android.sln as a source file and it should be only generated, not directly committed to the tree. But to achieve that we first need to find the right structure and right content. So far, there were handful of issues that either missed or incorrectly added solution items with inconsistent configurations. These inconsistent parts were found by the solution content analyzer at https://github.com/xamarin/xamarin-android/issues/1129#issuecomment-355484902
2018-01-09 17:55:30 +03:00
{3F1F2F50-AF1A-4A5A-BEDB-193372F068D7}.XAIntegrationDebug|AnyCPU.ActiveCfg = Debug|Any CPU
{3F1F2F50-AF1A-4A5A-BEDB-193372F068D7}.XAIntegrationDebug|AnyCPU.Build.0 = Debug|Any CPU
{3F1F2F50-AF1A-4A5A-BEDB-193372F068D7}.XAIntegrationRelease|AnyCPU.ActiveCfg = Release|Any CPU
{3F1F2F50-AF1A-4A5A-BEDB-193372F068D7}.XAIntegrationRelease|AnyCPU.Build.0 = Release|Any CPU
Fix line endings
2016-07-06 18:09:45 +03:00
{3FC3E78B-F7D4-42EA-BBE8-4535DF42BFF8}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
{3FC3E78B-F7D4-42EA-BBE8-4535DF42BFF8}.Debug|AnyCPU.Build.0 = Debug|Any CPU
{3FC3E78B-F7D4-42EA-BBE8-4535DF42BFF8}.Release|AnyCPU.ActiveCfg = Release|Any CPU
{3FC3E78B-F7D4-42EA-BBE8-4535DF42BFF8}.Release|AnyCPU.Build.0 = Release|Any CPU
Sanitize Xamarin.Android.sln: fix several inconsistency bits. (#1159) Manually editing solution file is uncool and error prone, but since the entire xamarin-android source tree is not designed cleanly it is impossible to use IDEs to do the right job. As stated at https://github.com/xamarin/xamarin-android/issues/1129 , we should eliminate this Xamarin.Android.sln as a source file and it should be only generated, not directly committed to the tree. But to achieve that we first need to find the right structure and right content. So far, there were handful of issues that either missed or incorrectly added solution items with inconsistent configurations. These inconsistent parts were found by the solution content analyzer at https://github.com/xamarin/xamarin-android/issues/1129#issuecomment-355484902
2018-01-09 17:55:30 +03:00
{3FC3E78B-F7D4-42EA-BBE8-4535DF42BFF8}.XAIntegrationDebug|AnyCPU.ActiveCfg = Debug|Any CPU
{3FC3E78B-F7D4-42EA-BBE8-4535DF42BFF8}.XAIntegrationDebug|AnyCPU.Build.0 = Debug|Any CPU
{3FC3E78B-F7D4-42EA-BBE8-4535DF42BFF8}.XAIntegrationRelease|AnyCPU.ActiveCfg = Release|Any CPU
{3FC3E78B-F7D4-42EA-BBE8-4535DF42BFF8}.XAIntegrationRelease|AnyCPU.Build.0 = Release|Any CPU
Fix line endings
2016-07-06 18:09:45 +03:00
{8FF78EB6-6FC8-46A7-8A15-EBBA9045C5FA}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
{8FF78EB6-6FC8-46A7-8A15-EBBA9045C5FA}.Debug|AnyCPU.Build.0 = Debug|Any CPU
[build] Add `make jenkins` target. (#116) The `make jenkins` [^0] target is for use by Continuous Integration machines, to build *everything* [^1]. This is expected to take an eternity. Think *hours*. $ time make jenkins ... real 130m11.608s user 97m22.220s sys 18m20.522s Of particular note is that the above "everything" includes *Release configuration builds* of everything, which is something that didn't actually work before. (Oops.) Bump Java.Interop so that it supports building the Release configuration, update Xamarin.Android.sln so that all required projects are part of the Release configuration, and update Xamarin.Android.Build.Tasks.csproj so that `JCW_ONLY_TYPE_NAMES` isn't defined, as this was preventing compilation. Fix **strip**(1) use: `mono-runtimes.targets` was trying to use `strip -S` on macOS, but the value of `%(_MonoRuntime.Strip)` was quoted, and thus attempted to execute `"strip -S" ...`, which failed. Move the `-S` into a new `%(_MonoRuntime.StripFlags)` value. Fixup `mono-runtimes.targets` and related files so that `$(MonoSourceFullPath)` is used instead of a relative path. This helps alleviate the "mental math" of determining the relative path to the Mono checkout. Plus, the Mono checkout is supposed to be overridable, e.g. commit d205cab2, and using `$(MonoSourceFullPath)` supports that. Download and install `android.jar` for all supported API levels. Fix the `Mono.Android.csproj` build so that `Mono.Android.dll` is stored in a per-API-level intermediate directory. Otherwise, if e.g. API-10 is built after API-23, the API-23 version will be installed, but the JCW build will fail. Additionally, API-24 requires using `javac -source 1.8 -target 1.8`, not 1.6. Fix `Mono.Android/metadata` to use the correct `merge.SourceFile` filename of `Profiles/api-24.xml.in`. Without that fix, API-24 won't build because `NumericShaper.GetContextualShaper()` is emitted twice, and the C# compiler doesn't like that. Disable use of `-lz` when building for Windows. Windows doesn't contain a `Z.DLL` to link against. [^0]: https://en.wikipedia.org/wiki/Leeroy_Jenkins [^1]: https://www.youtube.com/watch?v=hooKVstzbz0
2016-07-18 15:42:39 +03:00
{8FF78EB6-6FC8-46A7-8A15-EBBA9045C5FA}.Release|AnyCPU.ActiveCfg = Release|Any CPU
{8FF78EB6-6FC8-46A7-8A15-EBBA9045C5FA}.Release|AnyCPU.Build.0 = Release|Any CPU
Sanitize Xamarin.Android.sln: fix several inconsistency bits. (#1159) Manually editing solution file is uncool and error prone, but since the entire xamarin-android source tree is not designed cleanly it is impossible to use IDEs to do the right job. As stated at https://github.com/xamarin/xamarin-android/issues/1129 , we should eliminate this Xamarin.Android.sln as a source file and it should be only generated, not directly committed to the tree. But to achieve that we first need to find the right structure and right content. So far, there were handful of issues that either missed or incorrectly added solution items with inconsistent configurations. These inconsistent parts were found by the solution content analyzer at https://github.com/xamarin/xamarin-android/issues/1129#issuecomment-355484902
2018-01-09 17:55:30 +03:00
{8FF78EB6-6FC8-46A7-8A15-EBBA9045C5FA}.XAIntegrationDebug|AnyCPU.ActiveCfg = Debug|Any CPU
{8FF78EB6-6FC8-46A7-8A15-EBBA9045C5FA}.XAIntegrationDebug|AnyCPU.Build.0 = Debug|Any CPU
{8FF78EB6-6FC8-46A7-8A15-EBBA9045C5FA}.XAIntegrationRelease|AnyCPU.ActiveCfg = Release|Any CPU
{8FF78EB6-6FC8-46A7-8A15-EBBA9045C5FA}.XAIntegrationRelease|AnyCPU.Build.0 = Release|Any CPU
Fix line endings
2016-07-06 18:09:45 +03:00
{94BD81F7-B06F-4295-9636-F8A3B6BDC762}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
Sanitize Xamarin.Android.sln: fix several inconsistency bits. (#1159) Manually editing solution file is uncool and error prone, but since the entire xamarin-android source tree is not designed cleanly it is impossible to use IDEs to do the right job. As stated at https://github.com/xamarin/xamarin-android/issues/1129 , we should eliminate this Xamarin.Android.sln as a source file and it should be only generated, not directly committed to the tree. But to achieve that we first need to find the right structure and right content. So far, there were handful of issues that either missed or incorrectly added solution items with inconsistent configurations. These inconsistent parts were found by the solution content analyzer at https://github.com/xamarin/xamarin-android/issues/1129#issuecomment-355484902
2018-01-09 17:55:30 +03:00
{94BD81F7-B06F-4295-9636-F8A3B6BDC762}.Debug|AnyCPU.Build.0 = Debug|Any CPU
Fix line endings
2016-07-06 18:09:45 +03:00
{94BD81F7-B06F-4295-9636-F8A3B6BDC762}.Release|AnyCPU.ActiveCfg = Release|Any CPU
Sanitize Xamarin.Android.sln: fix several inconsistency bits. (#1159) Manually editing solution file is uncool and error prone, but since the entire xamarin-android source tree is not designed cleanly it is impossible to use IDEs to do the right job. As stated at https://github.com/xamarin/xamarin-android/issues/1129 , we should eliminate this Xamarin.Android.sln as a source file and it should be only generated, not directly committed to the tree. But to achieve that we first need to find the right structure and right content. So far, there were handful of issues that either missed or incorrectly added solution items with inconsistent configurations. These inconsistent parts were found by the solution content analyzer at https://github.com/xamarin/xamarin-android/issues/1129#issuecomment-355484902
2018-01-09 17:55:30 +03:00
{94BD81F7-B06F-4295-9636-F8A3B6BDC762}.Release|AnyCPU.Build.0 = Release|Any CPU
{94BD81F7-B06F-4295-9636-F8A3B6BDC762}.XAIntegrationDebug|AnyCPU.ActiveCfg = XAIntegrationDebug|Any CPU
{94BD81F7-B06F-4295-9636-F8A3B6BDC762}.XAIntegrationDebug|AnyCPU.Build.0 = XAIntegrationDebug|Any CPU
{94BD81F7-B06F-4295-9636-F8A3B6BDC762}.XAIntegrationRelease|AnyCPU.ActiveCfg = XAIntegrationRelease|Any CPU
{94BD81F7-B06F-4295-9636-F8A3B6BDC762}.XAIntegrationRelease|AnyCPU.Build.0 = XAIntegrationRelease|Any CPU
Fix line endings
2016-07-06 18:09:45 +03:00
{AFB8F6D1-6EA9-42C3-950B-98F34C669AD2}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
{AFB8F6D1-6EA9-42C3-950B-98F34C669AD2}.Debug|AnyCPU.Build.0 = Debug|Any CPU
{AFB8F6D1-6EA9-42C3-950B-98F34C669AD2}.Release|AnyCPU.ActiveCfg = Release|Any CPU
{AFB8F6D1-6EA9-42C3-950B-98F34C669AD2}.Release|AnyCPU.Build.0 = Release|Any CPU
Sanitize Xamarin.Android.sln: fix several inconsistency bits. (#1159) Manually editing solution file is uncool and error prone, but since the entire xamarin-android source tree is not designed cleanly it is impossible to use IDEs to do the right job. As stated at https://github.com/xamarin/xamarin-android/issues/1129 , we should eliminate this Xamarin.Android.sln as a source file and it should be only generated, not directly committed to the tree. But to achieve that we first need to find the right structure and right content. So far, there were handful of issues that either missed or incorrectly added solution items with inconsistent configurations. These inconsistent parts were found by the solution content analyzer at https://github.com/xamarin/xamarin-android/issues/1129#issuecomment-355484902
2018-01-09 17:55:30 +03:00
{AFB8F6D1-6EA9-42C3-950B-98F34C669AD2}.XAIntegrationDebug|AnyCPU.ActiveCfg = Debug|Any CPU
{AFB8F6D1-6EA9-42C3-950B-98F34C669AD2}.XAIntegrationDebug|AnyCPU.Build.0 = Debug|Any CPU
{AFB8F6D1-6EA9-42C3-950B-98F34C669AD2}.XAIntegrationRelease|AnyCPU.ActiveCfg = Release|Any CPU
{AFB8F6D1-6EA9-42C3-950B-98F34C669AD2}.XAIntegrationRelease|AnyCPU.Build.0 = Release|Any CPU
Fix line endings
2016-07-06 18:09:45 +03:00
{B17475BC-45A2-47A3-B8FC-62F3A0959EE0}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
{B17475BC-45A2-47A3-B8FC-62F3A0959EE0}.Debug|AnyCPU.Build.0 = Debug|Any CPU
{B17475BC-45A2-47A3-B8FC-62F3A0959EE0}.Release|AnyCPU.ActiveCfg = Release|Any CPU
{B17475BC-45A2-47A3-B8FC-62F3A0959EE0}.Release|AnyCPU.Build.0 = Release|Any CPU
Sanitize Xamarin.Android.sln: fix several inconsistency bits. (#1159) Manually editing solution file is uncool and error prone, but since the entire xamarin-android source tree is not designed cleanly it is impossible to use IDEs to do the right job. As stated at https://github.com/xamarin/xamarin-android/issues/1129 , we should eliminate this Xamarin.Android.sln as a source file and it should be only generated, not directly committed to the tree. But to achieve that we first need to find the right structure and right content. So far, there were handful of issues that either missed or incorrectly added solution items with inconsistent configurations. These inconsistent parts were found by the solution content analyzer at https://github.com/xamarin/xamarin-android/issues/1129#issuecomment-355484902
2018-01-09 17:55:30 +03:00
{B17475BC-45A2-47A3-B8FC-62F3A0959EE0}.XAIntegrationDebug|AnyCPU.ActiveCfg = Debug|Any CPU
{B17475BC-45A2-47A3-B8FC-62F3A0959EE0}.XAIntegrationDebug|AnyCPU.Build.0 = Debug|Any CPU
{B17475BC-45A2-47A3-B8FC-62F3A0959EE0}.XAIntegrationRelease|AnyCPU.ActiveCfg = Release|Any CPU
{B17475BC-45A2-47A3-B8FC-62F3A0959EE0}.XAIntegrationRelease|AnyCPU.Build.0 = Release|Any CPU
Fix line endings
2016-07-06 18:09:45 +03:00
{53EE4C57-1C03-405A-8243-8DA539546C88}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
Sanitize Xamarin.Android.sln: fix several inconsistency bits. (#1159) Manually editing solution file is uncool and error prone, but since the entire xamarin-android source tree is not designed cleanly it is impossible to use IDEs to do the right job. As stated at https://github.com/xamarin/xamarin-android/issues/1129 , we should eliminate this Xamarin.Android.sln as a source file and it should be only generated, not directly committed to the tree. But to achieve that we first need to find the right structure and right content. So far, there were handful of issues that either missed or incorrectly added solution items with inconsistent configurations. These inconsistent parts were found by the solution content analyzer at https://github.com/xamarin/xamarin-android/issues/1129#issuecomment-355484902
2018-01-09 17:55:30 +03:00
{53EE4C57-1C03-405A-8243-8DA539546C88}.Debug|AnyCPU.Build.0 = Debug|Any CPU
Fix line endings
2016-07-06 18:09:45 +03:00
{53EE4C57-1C03-405A-8243-8DA539546C88}.Release|AnyCPU.ActiveCfg = Release|Any CPU
Sanitize Xamarin.Android.sln: fix several inconsistency bits. (#1159) Manually editing solution file is uncool and error prone, but since the entire xamarin-android source tree is not designed cleanly it is impossible to use IDEs to do the right job. As stated at https://github.com/xamarin/xamarin-android/issues/1129 , we should eliminate this Xamarin.Android.sln as a source file and it should be only generated, not directly committed to the tree. But to achieve that we first need to find the right structure and right content. So far, there were handful of issues that either missed or incorrectly added solution items with inconsistent configurations. These inconsistent parts were found by the solution content analyzer at https://github.com/xamarin/xamarin-android/issues/1129#issuecomment-355484902
2018-01-09 17:55:30 +03:00
{53EE4C57-1C03-405A-8243-8DA539546C88}.Release|AnyCPU.Build.0 = Release|Any CPU
{53EE4C57-1C03-405A-8243-8DA539546C88}.XAIntegrationDebug|AnyCPU.ActiveCfg = Debug|Any CPU
{53EE4C57-1C03-405A-8243-8DA539546C88}.XAIntegrationDebug|AnyCPU.Build.0 = Debug|Any CPU
{53EE4C57-1C03-405A-8243-8DA539546C88}.XAIntegrationRelease|AnyCPU.ActiveCfg = Release|Any CPU
{53EE4C57-1C03-405A-8243-8DA539546C88}.XAIntegrationRelease|AnyCPU.Build.0 = Release|Any CPU
Fix line endings
2016-07-06 18:09:45 +03:00
{52C7D9B6-E8C8-47D0-9471-652D278D7D77}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
{52C7D9B6-E8C8-47D0-9471-652D278D7D77}.Debug|AnyCPU.Build.0 = Debug|Any CPU
[build] Add `make jenkins` target. (#116) The `make jenkins` [^0] target is for use by Continuous Integration machines, to build *everything* [^1]. This is expected to take an eternity. Think *hours*. $ time make jenkins ... real 130m11.608s user 97m22.220s sys 18m20.522s Of particular note is that the above "everything" includes *Release configuration builds* of everything, which is something that didn't actually work before. (Oops.) Bump Java.Interop so that it supports building the Release configuration, update Xamarin.Android.sln so that all required projects are part of the Release configuration, and update Xamarin.Android.Build.Tasks.csproj so that `JCW_ONLY_TYPE_NAMES` isn't defined, as this was preventing compilation. Fix **strip**(1) use: `mono-runtimes.targets` was trying to use `strip -S` on macOS, but the value of `%(_MonoRuntime.Strip)` was quoted, and thus attempted to execute `"strip -S" ...`, which failed. Move the `-S` into a new `%(_MonoRuntime.StripFlags)` value. Fixup `mono-runtimes.targets` and related files so that `$(MonoSourceFullPath)` is used instead of a relative path. This helps alleviate the "mental math" of determining the relative path to the Mono checkout. Plus, the Mono checkout is supposed to be overridable, e.g. commit d205cab2, and using `$(MonoSourceFullPath)` supports that. Download and install `android.jar` for all supported API levels. Fix the `Mono.Android.csproj` build so that `Mono.Android.dll` is stored in a per-API-level intermediate directory. Otherwise, if e.g. API-10 is built after API-23, the API-23 version will be installed, but the JCW build will fail. Additionally, API-24 requires using `javac -source 1.8 -target 1.8`, not 1.6. Fix `Mono.Android/metadata` to use the correct `merge.SourceFile` filename of `Profiles/api-24.xml.in`. Without that fix, API-24 won't build because `NumericShaper.GetContextualShaper()` is emitted twice, and the C# compiler doesn't like that. Disable use of `-lz` when building for Windows. Windows doesn't contain a `Z.DLL` to link against. [^0]: https://en.wikipedia.org/wiki/Leeroy_Jenkins [^1]: https://www.youtube.com/watch?v=hooKVstzbz0
2016-07-18 15:42:39 +03:00
{52C7D9B6-E8C8-47D0-9471-652D278D7D77}.Release|AnyCPU.ActiveCfg = Release|Any CPU
{52C7D9B6-E8C8-47D0-9471-652D278D7D77}.Release|AnyCPU.Build.0 = Release|Any CPU
Fix line endings
2016-07-06 18:09:45 +03:00
{D18FCF91-8876-48A0-A693-2DC1E7D3D80A}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
{D18FCF91-8876-48A0-A693-2DC1E7D3D80A}.Debug|AnyCPU.Build.0 = Debug|Any CPU
[build] Add `make jenkins` target. (#116) The `make jenkins` [^0] target is for use by Continuous Integration machines, to build *everything* [^1]. This is expected to take an eternity. Think *hours*. $ time make jenkins ... real 130m11.608s user 97m22.220s sys 18m20.522s Of particular note is that the above "everything" includes *Release configuration builds* of everything, which is something that didn't actually work before. (Oops.) Bump Java.Interop so that it supports building the Release configuration, update Xamarin.Android.sln so that all required projects are part of the Release configuration, and update Xamarin.Android.Build.Tasks.csproj so that `JCW_ONLY_TYPE_NAMES` isn't defined, as this was preventing compilation. Fix **strip**(1) use: `mono-runtimes.targets` was trying to use `strip -S` on macOS, but the value of `%(_MonoRuntime.Strip)` was quoted, and thus attempted to execute `"strip -S" ...`, which failed. Move the `-S` into a new `%(_MonoRuntime.StripFlags)` value. Fixup `mono-runtimes.targets` and related files so that `$(MonoSourceFullPath)` is used instead of a relative path. This helps alleviate the "mental math" of determining the relative path to the Mono checkout. Plus, the Mono checkout is supposed to be overridable, e.g. commit d205cab2, and using `$(MonoSourceFullPath)` supports that. Download and install `android.jar` for all supported API levels. Fix the `Mono.Android.csproj` build so that `Mono.Android.dll` is stored in a per-API-level intermediate directory. Otherwise, if e.g. API-10 is built after API-23, the API-23 version will be installed, but the JCW build will fail. Additionally, API-24 requires using `javac -source 1.8 -target 1.8`, not 1.6. Fix `Mono.Android/metadata` to use the correct `merge.SourceFile` filename of `Profiles/api-24.xml.in`. Without that fix, API-24 won't build because `NumericShaper.GetContextualShaper()` is emitted twice, and the C# compiler doesn't like that. Disable use of `-lz` when building for Windows. Windows doesn't contain a `Z.DLL` to link against. [^0]: https://en.wikipedia.org/wiki/Leeroy_Jenkins [^1]: https://www.youtube.com/watch?v=hooKVstzbz0
2016-07-18 15:42:39 +03:00
{D18FCF91-8876-48A0-A693-2DC1E7D3D80A}.Release|AnyCPU.ActiveCfg = Release|Any CPU
{D18FCF91-8876-48A0-A693-2DC1E7D3D80A}.Release|AnyCPU.Build.0 = Release|Any CPU
Fix line endings
2016-07-06 18:09:45 +03:00
{1268EADF-8344-431C-81F6-FCB7CBC99F49}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
{1268EADF-8344-431C-81F6-FCB7CBC99F49}.Debug|AnyCPU.Build.0 = Debug|Any CPU
[build] Add `make jenkins` target. (#116) The `make jenkins` [^0] target is for use by Continuous Integration machines, to build *everything* [^1]. This is expected to take an eternity. Think *hours*. $ time make jenkins ... real 130m11.608s user 97m22.220s sys 18m20.522s Of particular note is that the above "everything" includes *Release configuration builds* of everything, which is something that didn't actually work before. (Oops.) Bump Java.Interop so that it supports building the Release configuration, update Xamarin.Android.sln so that all required projects are part of the Release configuration, and update Xamarin.Android.Build.Tasks.csproj so that `JCW_ONLY_TYPE_NAMES` isn't defined, as this was preventing compilation. Fix **strip**(1) use: `mono-runtimes.targets` was trying to use `strip -S` on macOS, but the value of `%(_MonoRuntime.Strip)` was quoted, and thus attempted to execute `"strip -S" ...`, which failed. Move the `-S` into a new `%(_MonoRuntime.StripFlags)` value. Fixup `mono-runtimes.targets` and related files so that `$(MonoSourceFullPath)` is used instead of a relative path. This helps alleviate the "mental math" of determining the relative path to the Mono checkout. Plus, the Mono checkout is supposed to be overridable, e.g. commit d205cab2, and using `$(MonoSourceFullPath)` supports that. Download and install `android.jar` for all supported API levels. Fix the `Mono.Android.csproj` build so that `Mono.Android.dll` is stored in a per-API-level intermediate directory. Otherwise, if e.g. API-10 is built after API-23, the API-23 version will be installed, but the JCW build will fail. Additionally, API-24 requires using `javac -source 1.8 -target 1.8`, not 1.6. Fix `Mono.Android/metadata` to use the correct `merge.SourceFile` filename of `Profiles/api-24.xml.in`. Without that fix, API-24 won't build because `NumericShaper.GetContextualShaper()` is emitted twice, and the C# compiler doesn't like that. Disable use of `-lz` when building for Windows. Windows doesn't contain a `Z.DLL` to link against. [^0]: https://en.wikipedia.org/wiki/Leeroy_Jenkins [^1]: https://www.youtube.com/watch?v=hooKVstzbz0
2016-07-18 15:42:39 +03:00
{1268EADF-8344-431C-81F6-FCB7CBC99F49}.Release|AnyCPU.ActiveCfg = Release|Any CPU
{1268EADF-8344-431C-81F6-FCB7CBC99F49}.Release|AnyCPU.Build.0 = Release|Any CPU
Fix line endings
2016-07-06 18:09:45 +03:00
{07BC4495-1267-4B78-9EA6-B76FEEA2A64A}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
{07BC4495-1267-4B78-9EA6-B76FEEA2A64A}.Debug|AnyCPU.Build.0 = Debug|Any CPU
[build] Add `make jenkins` target. (#116) The `make jenkins` [^0] target is for use by Continuous Integration machines, to build *everything* [^1]. This is expected to take an eternity. Think *hours*. $ time make jenkins ... real 130m11.608s user 97m22.220s sys 18m20.522s Of particular note is that the above "everything" includes *Release configuration builds* of everything, which is something that didn't actually work before. (Oops.) Bump Java.Interop so that it supports building the Release configuration, update Xamarin.Android.sln so that all required projects are part of the Release configuration, and update Xamarin.Android.Build.Tasks.csproj so that `JCW_ONLY_TYPE_NAMES` isn't defined, as this was preventing compilation. Fix **strip**(1) use: `mono-runtimes.targets` was trying to use `strip -S` on macOS, but the value of `%(_MonoRuntime.Strip)` was quoted, and thus attempted to execute `"strip -S" ...`, which failed. Move the `-S` into a new `%(_MonoRuntime.StripFlags)` value. Fixup `mono-runtimes.targets` and related files so that `$(MonoSourceFullPath)` is used instead of a relative path. This helps alleviate the "mental math" of determining the relative path to the Mono checkout. Plus, the Mono checkout is supposed to be overridable, e.g. commit d205cab2, and using `$(MonoSourceFullPath)` supports that. Download and install `android.jar` for all supported API levels. Fix the `Mono.Android.csproj` build so that `Mono.Android.dll` is stored in a per-API-level intermediate directory. Otherwise, if e.g. API-10 is built after API-23, the API-23 version will be installed, but the JCW build will fail. Additionally, API-24 requires using `javac -source 1.8 -target 1.8`, not 1.6. Fix `Mono.Android/metadata` to use the correct `merge.SourceFile` filename of `Profiles/api-24.xml.in`. Without that fix, API-24 won't build because `NumericShaper.GetContextualShaper()` is emitted twice, and the C# compiler doesn't like that. Disable use of `-lz` when building for Windows. Windows doesn't contain a `Z.DLL` to link against. [^0]: https://en.wikipedia.org/wiki/Leeroy_Jenkins [^1]: https://www.youtube.com/watch?v=hooKVstzbz0
2016-07-18 15:42:39 +03:00
{07BC4495-1267-4B78-9EA6-B76FEEA2A64A}.Release|AnyCPU.ActiveCfg = Release|Any CPU
{07BC4495-1267-4B78-9EA6-B76FEEA2A64A}.Release|AnyCPU.Build.0 = Release|Any CPU
Fix line endings
2016-07-06 18:09:45 +03:00
{64CC4E44-CE3A-4319-BF3F-6CF8BD513870}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
{64CC4E44-CE3A-4319-BF3F-6CF8BD513870}.Debug|AnyCPU.Build.0 = Debug|Any CPU
[build] Add `make jenkins` target. (#116) The `make jenkins` [^0] target is for use by Continuous Integration machines, to build *everything* [^1]. This is expected to take an eternity. Think *hours*. $ time make jenkins ... real 130m11.608s user 97m22.220s sys 18m20.522s Of particular note is that the above "everything" includes *Release configuration builds* of everything, which is something that didn't actually work before. (Oops.) Bump Java.Interop so that it supports building the Release configuration, update Xamarin.Android.sln so that all required projects are part of the Release configuration, and update Xamarin.Android.Build.Tasks.csproj so that `JCW_ONLY_TYPE_NAMES` isn't defined, as this was preventing compilation. Fix **strip**(1) use: `mono-runtimes.targets` was trying to use `strip -S` on macOS, but the value of `%(_MonoRuntime.Strip)` was quoted, and thus attempted to execute `"strip -S" ...`, which failed. Move the `-S` into a new `%(_MonoRuntime.StripFlags)` value. Fixup `mono-runtimes.targets` and related files so that `$(MonoSourceFullPath)` is used instead of a relative path. This helps alleviate the "mental math" of determining the relative path to the Mono checkout. Plus, the Mono checkout is supposed to be overridable, e.g. commit d205cab2, and using `$(MonoSourceFullPath)` supports that. Download and install `android.jar` for all supported API levels. Fix the `Mono.Android.csproj` build so that `Mono.Android.dll` is stored in a per-API-level intermediate directory. Otherwise, if e.g. API-10 is built after API-23, the API-23 version will be installed, but the JCW build will fail. Additionally, API-24 requires using `javac -source 1.8 -target 1.8`, not 1.6. Fix `Mono.Android/metadata` to use the correct `merge.SourceFile` filename of `Profiles/api-24.xml.in`. Without that fix, API-24 won't build because `NumericShaper.GetContextualShaper()` is emitted twice, and the C# compiler doesn't like that. Disable use of `-lz` when building for Windows. Windows doesn't contain a `Z.DLL` to link against. [^0]: https://en.wikipedia.org/wiki/Leeroy_Jenkins [^1]: https://www.youtube.com/watch?v=hooKVstzbz0
2016-07-18 15:42:39 +03:00
{64CC4E44-CE3A-4319-BF3F-6CF8BD513870}.Release|AnyCPU.ActiveCfg = Release|Any CPU
{64CC4E44-CE3A-4319-BF3F-6CF8BD513870}.Release|AnyCPU.Build.0 = Release|Any CPU
Fix line endings
2016-07-06 18:09:45 +03:00
{D48EE8D0-0A0A-4493-AEF5-DAF5F8CF86AD}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
{D48EE8D0-0A0A-4493-AEF5-DAF5F8CF86AD}.Debug|AnyCPU.Build.0 = Debug|Any CPU
[build] Add `make jenkins` target. (#116) The `make jenkins` [^0] target is for use by Continuous Integration machines, to build *everything* [^1]. This is expected to take an eternity. Think *hours*. $ time make jenkins ... real 130m11.608s user 97m22.220s sys 18m20.522s Of particular note is that the above "everything" includes *Release configuration builds* of everything, which is something that didn't actually work before. (Oops.) Bump Java.Interop so that it supports building the Release configuration, update Xamarin.Android.sln so that all required projects are part of the Release configuration, and update Xamarin.Android.Build.Tasks.csproj so that `JCW_ONLY_TYPE_NAMES` isn't defined, as this was preventing compilation. Fix **strip**(1) use: `mono-runtimes.targets` was trying to use `strip -S` on macOS, but the value of `%(_MonoRuntime.Strip)` was quoted, and thus attempted to execute `"strip -S" ...`, which failed. Move the `-S` into a new `%(_MonoRuntime.StripFlags)` value. Fixup `mono-runtimes.targets` and related files so that `$(MonoSourceFullPath)` is used instead of a relative path. This helps alleviate the "mental math" of determining the relative path to the Mono checkout. Plus, the Mono checkout is supposed to be overridable, e.g. commit d205cab2, and using `$(MonoSourceFullPath)` supports that. Download and install `android.jar` for all supported API levels. Fix the `Mono.Android.csproj` build so that `Mono.Android.dll` is stored in a per-API-level intermediate directory. Otherwise, if e.g. API-10 is built after API-23, the API-23 version will be installed, but the JCW build will fail. Additionally, API-24 requires using `javac -source 1.8 -target 1.8`, not 1.6. Fix `Mono.Android/metadata` to use the correct `merge.SourceFile` filename of `Profiles/api-24.xml.in`. Without that fix, API-24 won't build because `NumericShaper.GetContextualShaper()` is emitted twice, and the C# compiler doesn't like that. Disable use of `-lz` when building for Windows. Windows doesn't contain a `Z.DLL` to link against. [^0]: https://en.wikipedia.org/wiki/Leeroy_Jenkins [^1]: https://www.youtube.com/watch?v=hooKVstzbz0
2016-07-18 15:42:39 +03:00
{D48EE8D0-0A0A-4493-AEF5-DAF5F8CF86AD}.Release|AnyCPU.ActiveCfg = Release|Any CPU
{D48EE8D0-0A0A-4493-AEF5-DAF5F8CF86AD}.Release|AnyCPU.Build.0 = Release|Any CPU
Fix line endings
2016-07-06 18:09:45 +03:00
{C03E6CF1-7460-4CDC-A4AB-292BBC0F61F2}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
{C03E6CF1-7460-4CDC-A4AB-292BBC0F61F2}.Debug|AnyCPU.Build.0 = Debug|Any CPU
{C03E6CF1-7460-4CDC-A4AB-292BBC0F61F2}.Release|AnyCPU.ActiveCfg = Release|Any CPU
{C03E6CF1-7460-4CDC-A4AB-292BBC0F61F2}.Release|AnyCPU.Build.0 = Release|Any CPU
Sanitize Xamarin.Android.sln: fix several inconsistency bits. (#1159) Manually editing solution file is uncool and error prone, but since the entire xamarin-android source tree is not designed cleanly it is impossible to use IDEs to do the right job. As stated at https://github.com/xamarin/xamarin-android/issues/1129 , we should eliminate this Xamarin.Android.sln as a source file and it should be only generated, not directly committed to the tree. But to achieve that we first need to find the right structure and right content. So far, there were handful of issues that either missed or incorrectly added solution items with inconsistent configurations. These inconsistent parts were found by the solution content analyzer at https://github.com/xamarin/xamarin-android/issues/1129#issuecomment-355484902
2018-01-09 17:55:30 +03:00
{C03E6CF1-7460-4CDC-A4AB-292BBC0F61F2}.XAIntegrationDebug|AnyCPU.ActiveCfg = Debug|Any CPU
{C03E6CF1-7460-4CDC-A4AB-292BBC0F61F2}.XAIntegrationDebug|AnyCPU.Build.0 = Debug|Any CPU
{C03E6CF1-7460-4CDC-A4AB-292BBC0F61F2}.XAIntegrationRelease|AnyCPU.ActiveCfg = Release|Any CPU
{C03E6CF1-7460-4CDC-A4AB-292BBC0F61F2}.XAIntegrationRelease|AnyCPU.Build.0 = Release|Any CPU
Fix line endings
2016-07-06 18:09:45 +03:00
{D14A1B5C-2060-4930-92BE-F7190256C735}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
{D14A1B5C-2060-4930-92BE-F7190256C735}.Debug|AnyCPU.Build.0 = Debug|Any CPU
{D14A1B5C-2060-4930-92BE-F7190256C735}.Release|AnyCPU.ActiveCfg = Release|Any CPU
{D14A1B5C-2060-4930-92BE-F7190256C735}.Release|AnyCPU.Build.0 = Release|Any CPU
Sanitize Xamarin.Android.sln: fix several inconsistency bits. (#1159) Manually editing solution file is uncool and error prone, but since the entire xamarin-android source tree is not designed cleanly it is impossible to use IDEs to do the right job. As stated at https://github.com/xamarin/xamarin-android/issues/1129 , we should eliminate this Xamarin.Android.sln as a source file and it should be only generated, not directly committed to the tree. But to achieve that we first need to find the right structure and right content. So far, there were handful of issues that either missed or incorrectly added solution items with inconsistent configurations. These inconsistent parts were found by the solution content analyzer at https://github.com/xamarin/xamarin-android/issues/1129#issuecomment-355484902
2018-01-09 17:55:30 +03:00
{D14A1B5C-2060-4930-92BE-F7190256C735}.XAIntegrationDebug|AnyCPU.ActiveCfg = Debug|Any CPU
{D14A1B5C-2060-4930-92BE-F7190256C735}.XAIntegrationDebug|AnyCPU.Build.0 = Debug|Any CPU
{D14A1B5C-2060-4930-92BE-F7190256C735}.XAIntegrationRelease|AnyCPU.ActiveCfg = Release|Any CPU
{D14A1B5C-2060-4930-92BE-F7190256C735}.XAIntegrationRelease|AnyCPU.Build.0 = Release|Any CPU
Fix line endings
2016-07-06 18:09:45 +03:00
{D27AD8F7-7710-40BE-B03B-55EFBEC13C44}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
{D27AD8F7-7710-40BE-B03B-55EFBEC13C44}.Debug|AnyCPU.Build.0 = Debug|Any CPU
{D27AD8F7-7710-40BE-B03B-55EFBEC13C44}.Release|AnyCPU.ActiveCfg = Release|Any CPU
{D27AD8F7-7710-40BE-B03B-55EFBEC13C44}.Release|AnyCPU.Build.0 = Release|Any CPU
Sanitize Xamarin.Android.sln: fix several inconsistency bits. (#1159) Manually editing solution file is uncool and error prone, but since the entire xamarin-android source tree is not designed cleanly it is impossible to use IDEs to do the right job. As stated at https://github.com/xamarin/xamarin-android/issues/1129 , we should eliminate this Xamarin.Android.sln as a source file and it should be only generated, not directly committed to the tree. But to achieve that we first need to find the right structure and right content. So far, there were handful of issues that either missed or incorrectly added solution items with inconsistent configurations. These inconsistent parts were found by the solution content analyzer at https://github.com/xamarin/xamarin-android/issues/1129#issuecomment-355484902
2018-01-09 17:55:30 +03:00
{D27AD8F7-7710-40BE-B03B-55EFBEC13C44}.XAIntegrationDebug|AnyCPU.ActiveCfg = Debug|Any CPU
{D27AD8F7-7710-40BE-B03B-55EFBEC13C44}.XAIntegrationDebug|AnyCPU.Build.0 = Debug|Any CPU
{D27AD8F7-7710-40BE-B03B-55EFBEC13C44}.XAIntegrationRelease|AnyCPU.ActiveCfg = Release|Any CPU
{D27AD8F7-7710-40BE-B03B-55EFBEC13C44}.XAIntegrationRelease|AnyCPU.Build.0 = Release|Any CPU
Fix line endings
2016-07-06 18:09:45 +03:00
{E8492EFB-D14A-4F32-AA28-88848322ECEA}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
{E8492EFB-D14A-4F32-AA28-88848322ECEA}.Debug|AnyCPU.Build.0 = Debug|Any CPU
[build] Add `make jenkins` target. (#116) The `make jenkins` [^0] target is for use by Continuous Integration machines, to build *everything* [^1]. This is expected to take an eternity. Think *hours*. $ time make jenkins ... real 130m11.608s user 97m22.220s sys 18m20.522s Of particular note is that the above "everything" includes *Release configuration builds* of everything, which is something that didn't actually work before. (Oops.) Bump Java.Interop so that it supports building the Release configuration, update Xamarin.Android.sln so that all required projects are part of the Release configuration, and update Xamarin.Android.Build.Tasks.csproj so that `JCW_ONLY_TYPE_NAMES` isn't defined, as this was preventing compilation. Fix **strip**(1) use: `mono-runtimes.targets` was trying to use `strip -S` on macOS, but the value of `%(_MonoRuntime.Strip)` was quoted, and thus attempted to execute `"strip -S" ...`, which failed. Move the `-S` into a new `%(_MonoRuntime.StripFlags)` value. Fixup `mono-runtimes.targets` and related files so that `$(MonoSourceFullPath)` is used instead of a relative path. This helps alleviate the "mental math" of determining the relative path to the Mono checkout. Plus, the Mono checkout is supposed to be overridable, e.g. commit d205cab2, and using `$(MonoSourceFullPath)` supports that. Download and install `android.jar` for all supported API levels. Fix the `Mono.Android.csproj` build so that `Mono.Android.dll` is stored in a per-API-level intermediate directory. Otherwise, if e.g. API-10 is built after API-23, the API-23 version will be installed, but the JCW build will fail. Additionally, API-24 requires using `javac -source 1.8 -target 1.8`, not 1.6. Fix `Mono.Android/metadata` to use the correct `merge.SourceFile` filename of `Profiles/api-24.xml.in`. Without that fix, API-24 won't build because `NumericShaper.GetContextualShaper()` is emitted twice, and the C# compiler doesn't like that. Disable use of `-lz` when building for Windows. Windows doesn't contain a `Z.DLL` to link against. [^0]: https://en.wikipedia.org/wiki/Leeroy_Jenkins [^1]: https://www.youtube.com/watch?v=hooKVstzbz0
2016-07-18 15:42:39 +03:00
{E8492EFB-D14A-4F32-AA28-88848322ECEA}.Release|AnyCPU.ActiveCfg = Release|Any CPU
{E8492EFB-D14A-4F32-AA28-88848322ECEA}.Release|AnyCPU.Build.0 = Release|Any CPU
Sanitize Xamarin.Android.sln: fix several inconsistency bits. (#1159) Manually editing solution file is uncool and error prone, but since the entire xamarin-android source tree is not designed cleanly it is impossible to use IDEs to do the right job. As stated at https://github.com/xamarin/xamarin-android/issues/1129 , we should eliminate this Xamarin.Android.sln as a source file and it should be only generated, not directly committed to the tree. But to achieve that we first need to find the right structure and right content. So far, there were handful of issues that either missed or incorrectly added solution items with inconsistent configurations. These inconsistent parts were found by the solution content analyzer at https://github.com/xamarin/xamarin-android/issues/1129#issuecomment-355484902
2018-01-09 17:55:30 +03:00
{E8492EFB-D14A-4F32-AA28-88848322ECEA}.XAIntegrationDebug|AnyCPU.ActiveCfg = Debug|Any CPU
{E8492EFB-D14A-4F32-AA28-88848322ECEA}.XAIntegrationDebug|AnyCPU.Build.0 = Debug|Any CPU
{E8492EFB-D14A-4F32-AA28-88848322ECEA}.XAIntegrationRelease|AnyCPU.ActiveCfg = Release|Any CPU
{E8492EFB-D14A-4F32-AA28-88848322ECEA}.XAIntegrationRelease|AnyCPU.Build.0 = Release|Any CPU
Fix line endings
2016-07-06 18:09:45 +03:00
{4D603AA3-3BFD-43C8-8050-0CD6C2601126}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
{4D603AA3-3BFD-43C8-8050-0CD6C2601126}.Debug|AnyCPU.Build.0 = Debug|Any CPU
{4D603AA3-3BFD-43C8-8050-0CD6C2601126}.Release|AnyCPU.ActiveCfg = Release|Any CPU
{4D603AA3-3BFD-43C8-8050-0CD6C2601126}.Release|AnyCPU.Build.0 = Release|Any CPU
{4D603AA3-3BFD-43C8-8050-0CD6C2601126}.XAIntegrationDebug|AnyCPU.ActiveCfg = Debug|Any CPU
{4D603AA3-3BFD-43C8-8050-0CD6C2601126}.XAIntegrationDebug|AnyCPU.Build.0 = Debug|Any CPU
Sanitize Xamarin.Android.sln: fix several inconsistency bits. (#1159) Manually editing solution file is uncool and error prone, but since the entire xamarin-android source tree is not designed cleanly it is impossible to use IDEs to do the right job. As stated at https://github.com/xamarin/xamarin-android/issues/1129 , we should eliminate this Xamarin.Android.sln as a source file and it should be only generated, not directly committed to the tree. But to achieve that we first need to find the right structure and right content. So far, there were handful of issues that either missed or incorrectly added solution items with inconsistent configurations. These inconsistent parts were found by the solution content analyzer at https://github.com/xamarin/xamarin-android/issues/1129#issuecomment-355484902
2018-01-09 17:55:30 +03:00
{4D603AA3-3BFD-43C8-8050-0CD6C2601126}.XAIntegrationRelease|AnyCPU.ActiveCfg = Release|Any CPU
{4D603AA3-3BFD-43C8-8050-0CD6C2601126}.XAIntegrationRelease|AnyCPU.Build.0 = Release|Any CPU
Fix line endings
2016-07-06 18:09:45 +03:00
{2DD1EE75-6D8D-4653-A800-0A24367F7F38}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
{2DD1EE75-6D8D-4653-A800-0A24367F7F38}.Debug|AnyCPU.Build.0 = Debug|Any CPU
{2DD1EE75-6D8D-4653-A800-0A24367F7F38}.Release|AnyCPU.ActiveCfg = Release|Any CPU
{2DD1EE75-6D8D-4653-A800-0A24367F7F38}.Release|AnyCPU.Build.0 = Release|Any CPU
{2DD1EE75-6D8D-4653-A800-0A24367F7F38}.XAIntegrationDebug|AnyCPU.ActiveCfg = Debug|Any CPU
{2DD1EE75-6D8D-4653-A800-0A24367F7F38}.XAIntegrationDebug|AnyCPU.Build.0 = Debug|Any CPU
Sanitize Xamarin.Android.sln: fix several inconsistency bits. (#1159) Manually editing solution file is uncool and error prone, but since the entire xamarin-android source tree is not designed cleanly it is impossible to use IDEs to do the right job. As stated at https://github.com/xamarin/xamarin-android/issues/1129 , we should eliminate this Xamarin.Android.sln as a source file and it should be only generated, not directly committed to the tree. But to achieve that we first need to find the right structure and right content. So far, there were handful of issues that either missed or incorrectly added solution items with inconsistent configurations. These inconsistent parts were found by the solution content analyzer at https://github.com/xamarin/xamarin-android/issues/1129#issuecomment-355484902
2018-01-09 17:55:30 +03:00
{2DD1EE75-6D8D-4653-A800-0A24367F7F38}.XAIntegrationRelease|AnyCPU.ActiveCfg = Release|Any CPU
{2DD1EE75-6D8D-4653-A800-0A24367F7F38}.XAIntegrationRelease|AnyCPU.Build.0 = Release|Any CPU
Fix line endings
2016-07-06 18:09:45 +03:00
{2868FC32-A4E7-4008-87C8-2C7879CACB58}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
{2868FC32-A4E7-4008-87C8-2C7879CACB58}.Debug|AnyCPU.Build.0 = Debug|Any CPU
{2868FC32-A4E7-4008-87C8-2C7879CACB58}.Release|AnyCPU.ActiveCfg = Release|Any CPU
{2868FC32-A4E7-4008-87C8-2C7879CACB58}.Release|AnyCPU.Build.0 = Release|Any CPU
{2868FC32-A4E7-4008-87C8-2C7879CACB58}.XAIntegrationDebug|AnyCPU.ActiveCfg = Debug|Any CPU
{2868FC32-A4E7-4008-87C8-2C7879CACB58}.XAIntegrationDebug|AnyCPU.Build.0 = Debug|Any CPU
Sanitize Xamarin.Android.sln: fix several inconsistency bits. (#1159) Manually editing solution file is uncool and error prone, but since the entire xamarin-android source tree is not designed cleanly it is impossible to use IDEs to do the right job. As stated at https://github.com/xamarin/xamarin-android/issues/1129 , we should eliminate this Xamarin.Android.sln as a source file and it should be only generated, not directly committed to the tree. But to achieve that we first need to find the right structure and right content. So far, there were handful of issues that either missed or incorrectly added solution items with inconsistent configurations. These inconsistent parts were found by the solution content analyzer at https://github.com/xamarin/xamarin-android/issues/1129#issuecomment-355484902
2018-01-09 17:55:30 +03:00
{2868FC32-A4E7-4008-87C8-2C7879CACB58}.XAIntegrationRelease|AnyCPU.ActiveCfg = Release|Any CPU
{2868FC32-A4E7-4008-87C8-2C7879CACB58}.XAIntegrationRelease|AnyCPU.Build.0 = Release|Any CPU
Fix line endings
2016-07-06 18:09:45 +03:00
{2CF172E5-BDAE-4ABA-8BC8-08040ED3E77A}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
{2CF172E5-BDAE-4ABA-8BC8-08040ED3E77A}.Debug|AnyCPU.Build.0 = Debug|Any CPU
{2CF172E5-BDAE-4ABA-8BC8-08040ED3E77A}.Release|AnyCPU.ActiveCfg = Release|Any CPU
{2CF172E5-BDAE-4ABA-8BC8-08040ED3E77A}.Release|AnyCPU.Build.0 = Release|Any CPU
{2CF172E5-BDAE-4ABA-8BC8-08040ED3E77A}.XAIntegrationDebug|AnyCPU.ActiveCfg = Debug|Any CPU
{2CF172E5-BDAE-4ABA-8BC8-08040ED3E77A}.XAIntegrationDebug|AnyCPU.Build.0 = Debug|Any CPU
Sanitize Xamarin.Android.sln: fix several inconsistency bits. (#1159) Manually editing solution file is uncool and error prone, but since the entire xamarin-android source tree is not designed cleanly it is impossible to use IDEs to do the right job. As stated at https://github.com/xamarin/xamarin-android/issues/1129 , we should eliminate this Xamarin.Android.sln as a source file and it should be only generated, not directly committed to the tree. But to achieve that we first need to find the right structure and right content. So far, there were handful of issues that either missed or incorrectly added solution items with inconsistent configurations. These inconsistent parts were found by the solution content analyzer at https://github.com/xamarin/xamarin-android/issues/1129#issuecomment-355484902
2018-01-09 17:55:30 +03:00
{2CF172E5-BDAE-4ABA-8BC8-08040ED3E77A}.XAIntegrationRelease|AnyCPU.ActiveCfg = Release|Any CPU
{2CF172E5-BDAE-4ABA-8BC8-08040ED3E77A}.XAIntegrationRelease|AnyCPU.Build.0 = Release|Any CPU
Fix line endings
2016-07-06 18:09:45 +03:00
{1A4B041A-842F-40B3-A50D-49E01D30BD18}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
{1A4B041A-842F-40B3-A50D-49E01D30BD18}.Debug|AnyCPU.Build.0 = Debug|Any CPU
{1A4B041A-842F-40B3-A50D-49E01D30BD18}.Release|AnyCPU.ActiveCfg = Release|Any CPU
{1A4B041A-842F-40B3-A50D-49E01D30BD18}.Release|AnyCPU.Build.0 = Release|Any CPU
{1A4B041A-842F-40B3-A50D-49E01D30BD18}.XAIntegrationDebug|AnyCPU.ActiveCfg = Debug|Any CPU
{1A4B041A-842F-40B3-A50D-49E01D30BD18}.XAIntegrationDebug|AnyCPU.Build.0 = Debug|Any CPU
Sanitize Xamarin.Android.sln: fix several inconsistency bits. (#1159) Manually editing solution file is uncool and error prone, but since the entire xamarin-android source tree is not designed cleanly it is impossible to use IDEs to do the right job. As stated at https://github.com/xamarin/xamarin-android/issues/1129 , we should eliminate this Xamarin.Android.sln as a source file and it should be only generated, not directly committed to the tree. But to achieve that we first need to find the right structure and right content. So far, there were handful of issues that either missed or incorrectly added solution items with inconsistent configurations. These inconsistent parts were found by the solution content analyzer at https://github.com/xamarin/xamarin-android/issues/1129#issuecomment-355484902
2018-01-09 17:55:30 +03:00
{1A4B041A-842F-40B3-A50D-49E01D30BD18}.XAIntegrationRelease|AnyCPU.ActiveCfg = Release|Any CPU
{1A4B041A-842F-40B3-A50D-49E01D30BD18}.XAIntegrationRelease|AnyCPU.Build.0 = Release|Any CPU
Fix line endings
2016-07-06 18:09:45 +03:00
{38C762AB-8FD1-44DE-9855-26AAE7129DC3}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
{38C762AB-8FD1-44DE-9855-26AAE7129DC3}.Debug|AnyCPU.Build.0 = Debug|Any CPU
{38C762AB-8FD1-44DE-9855-26AAE7129DC3}.Release|AnyCPU.ActiveCfg = Release|Any CPU
{38C762AB-8FD1-44DE-9855-26AAE7129DC3}.Release|AnyCPU.Build.0 = Release|Any CPU
{38C762AB-8FD1-44DE-9855-26AAE7129DC3}.XAIntegrationDebug|AnyCPU.ActiveCfg = Debug|Any CPU
{38C762AB-8FD1-44DE-9855-26AAE7129DC3}.XAIntegrationDebug|AnyCPU.Build.0 = Debug|Any CPU
Sanitize Xamarin.Android.sln: fix several inconsistency bits. (#1159) Manually editing solution file is uncool and error prone, but since the entire xamarin-android source tree is not designed cleanly it is impossible to use IDEs to do the right job. As stated at https://github.com/xamarin/xamarin-android/issues/1129 , we should eliminate this Xamarin.Android.sln as a source file and it should be only generated, not directly committed to the tree. But to achieve that we first need to find the right structure and right content. So far, there were handful of issues that either missed or incorrectly added solution items with inconsistent configurations. These inconsistent parts were found by the solution content analyzer at https://github.com/xamarin/xamarin-android/issues/1129#issuecomment-355484902
2018-01-09 17:55:30 +03:00
{38C762AB-8FD1-44DE-9855-26AAE7129DC3}.XAIntegrationRelease|AnyCPU.ActiveCfg = Release|Any CPU
{38C762AB-8FD1-44DE-9855-26AAE7129DC3}.XAIntegrationRelease|AnyCPU.Build.0 = Release|Any CPU
Fix line endings
2016-07-06 18:09:45 +03:00
{7387E151-48E3-4885-B2CA-A74434A34045}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
{7387E151-48E3-4885-B2CA-A74434A34045}.Debug|AnyCPU.Build.0 = Debug|Any CPU
{7387E151-48E3-4885-B2CA-A74434A34045}.Release|AnyCPU.ActiveCfg = Release|Any CPU
{7387E151-48E3-4885-B2CA-A74434A34045}.Release|AnyCPU.Build.0 = Release|Any CPU
{7387E151-48E3-4885-B2CA-A74434A34045}.XAIntegrationDebug|AnyCPU.ActiveCfg = Debug|Any CPU
{7387E151-48E3-4885-B2CA-A74434A34045}.XAIntegrationDebug|AnyCPU.Build.0 = Debug|Any CPU
Sanitize Xamarin.Android.sln: fix several inconsistency bits. (#1159) Manually editing solution file is uncool and error prone, but since the entire xamarin-android source tree is not designed cleanly it is impossible to use IDEs to do the right job. As stated at https://github.com/xamarin/xamarin-android/issues/1129 , we should eliminate this Xamarin.Android.sln as a source file and it should be only generated, not directly committed to the tree. But to achieve that we first need to find the right structure and right content. So far, there were handful of issues that either missed or incorrectly added solution items with inconsistent configurations. These inconsistent parts were found by the solution content analyzer at https://github.com/xamarin/xamarin-android/issues/1129#issuecomment-355484902
2018-01-09 17:55:30 +03:00
{7387E151-48E3-4885-B2CA-A74434A34045}.XAIntegrationRelease|AnyCPU.ActiveCfg = Release|Any CPU
{7387E151-48E3-4885-B2CA-A74434A34045}.XAIntegrationRelease|AnyCPU.Build.0 = Release|Any CPU
Fix line endings
2016-07-06 18:09:45 +03:00
{26781D3A-FF20-4F55-9824-C8A06AA9E484}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
{26781D3A-FF20-4F55-9824-C8A06AA9E484}.Debug|AnyCPU.Build.0 = Debug|Any CPU
{26781D3A-FF20-4F55-9824-C8A06AA9E484}.Release|AnyCPU.ActiveCfg = Release|Any CPU
{26781D3A-FF20-4F55-9824-C8A06AA9E484}.Release|AnyCPU.Build.0 = Release|Any CPU
{26781D3A-FF20-4F55-9824-C8A06AA9E484}.XAIntegrationDebug|AnyCPU.ActiveCfg = Debug|Any CPU
{26781D3A-FF20-4F55-9824-C8A06AA9E484}.XAIntegrationDebug|AnyCPU.Build.0 = Debug|Any CPU
Sanitize Xamarin.Android.sln: fix several inconsistency bits. (#1159) Manually editing solution file is uncool and error prone, but since the entire xamarin-android source tree is not designed cleanly it is impossible to use IDEs to do the right job. As stated at https://github.com/xamarin/xamarin-android/issues/1129 , we should eliminate this Xamarin.Android.sln as a source file and it should be only generated, not directly committed to the tree. But to achieve that we first need to find the right structure and right content. So far, there were handful of issues that either missed or incorrectly added solution items with inconsistent configurations. These inconsistent parts were found by the solution content analyzer at https://github.com/xamarin/xamarin-android/issues/1129#issuecomment-355484902
2018-01-09 17:55:30 +03:00
{26781D3A-FF20-4F55-9824-C8A06AA9E484}.XAIntegrationRelease|AnyCPU.ActiveCfg = Release|Any CPU
{26781D3A-FF20-4F55-9824-C8A06AA9E484}.XAIntegrationRelease|AnyCPU.Build.0 = Release|Any CPU
Fix line endings
2016-07-06 18:09:45 +03:00
{B8F799C5-D7CE-4E09-9CE6-BAA4173E7EC8}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
{B8F799C5-D7CE-4E09-9CE6-BAA4173E7EC8}.Debug|AnyCPU.Build.0 = Debug|Any CPU
{B8F799C5-D7CE-4E09-9CE6-BAA4173E7EC8}.Release|AnyCPU.ActiveCfg = Release|Any CPU
{B8F799C5-D7CE-4E09-9CE6-BAA4173E7EC8}.Release|AnyCPU.Build.0 = Release|Any CPU
{B8F799C5-D7CE-4E09-9CE6-BAA4173E7EC8}.XAIntegrationDebug|AnyCPU.ActiveCfg = Debug|Any CPU
{B8F799C5-D7CE-4E09-9CE6-BAA4173E7EC8}.XAIntegrationDebug|AnyCPU.Build.0 = Debug|Any CPU
Sanitize Xamarin.Android.sln: fix several inconsistency bits. (#1159) Manually editing solution file is uncool and error prone, but since the entire xamarin-android source tree is not designed cleanly it is impossible to use IDEs to do the right job. As stated at https://github.com/xamarin/xamarin-android/issues/1129 , we should eliminate this Xamarin.Android.sln as a source file and it should be only generated, not directly committed to the tree. But to achieve that we first need to find the right structure and right content. So far, there were handful of issues that either missed or incorrectly added solution items with inconsistent configurations. These inconsistent parts were found by the solution content analyzer at https://github.com/xamarin/xamarin-android/issues/1129#issuecomment-355484902
2018-01-09 17:55:30 +03:00
{B8F799C5-D7CE-4E09-9CE6-BAA4173E7EC8}.XAIntegrationRelease|AnyCPU.ActiveCfg = Release|Any CPU
{B8F799C5-D7CE-4E09-9CE6-BAA4173E7EC8}.XAIntegrationRelease|AnyCPU.Build.0 = Release|Any CPU
Fix line endings
2016-07-06 18:09:45 +03:00
{5EB9E888-E357-417E-9F39-DDEC195CE47F}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
{5EB9E888-E357-417E-9F39-DDEC195CE47F}.Debug|AnyCPU.Build.0 = Debug|Any CPU
{5EB9E888-E357-417E-9F39-DDEC195CE47F}.Release|AnyCPU.ActiveCfg = Release|Any CPU
{5EB9E888-E357-417E-9F39-DDEC195CE47F}.Release|AnyCPU.Build.0 = Release|Any CPU
{5EB9E888-E357-417E-9F39-DDEC195CE47F}.XAIntegrationDebug|AnyCPU.ActiveCfg = Debug|Any CPU
{5EB9E888-E357-417E-9F39-DDEC195CE47F}.XAIntegrationDebug|AnyCPU.Build.0 = Debug|Any CPU
Sanitize Xamarin.Android.sln: fix several inconsistency bits. (#1159) Manually editing solution file is uncool and error prone, but since the entire xamarin-android source tree is not designed cleanly it is impossible to use IDEs to do the right job. As stated at https://github.com/xamarin/xamarin-android/issues/1129 , we should eliminate this Xamarin.Android.sln as a source file and it should be only generated, not directly committed to the tree. But to achieve that we first need to find the right structure and right content. So far, there were handful of issues that either missed or incorrectly added solution items with inconsistent configurations. These inconsistent parts were found by the solution content analyzer at https://github.com/xamarin/xamarin-android/issues/1129#issuecomment-355484902
2018-01-09 17:55:30 +03:00
{5EB9E888-E357-417E-9F39-DDEC195CE47F}.XAIntegrationRelease|AnyCPU.ActiveCfg = Release|Any CPU
{5EB9E888-E357-417E-9F39-DDEC195CE47F}.XAIntegrationRelease|AnyCPU.Build.0 = Release|Any CPU
Fix line endings
2016-07-06 18:09:45 +03:00
{900A0F71-BAAD-417A-8D1A-8D330297CDD0}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
{900A0F71-BAAD-417A-8D1A-8D330297CDD0}.Debug|AnyCPU.Build.0 = Debug|Any CPU
[build] Add `make jenkins` target. (#116) The `make jenkins` [^0] target is for use by Continuous Integration machines, to build *everything* [^1]. This is expected to take an eternity. Think *hours*. $ time make jenkins ... real 130m11.608s user 97m22.220s sys 18m20.522s Of particular note is that the above "everything" includes *Release configuration builds* of everything, which is something that didn't actually work before. (Oops.) Bump Java.Interop so that it supports building the Release configuration, update Xamarin.Android.sln so that all required projects are part of the Release configuration, and update Xamarin.Android.Build.Tasks.csproj so that `JCW_ONLY_TYPE_NAMES` isn't defined, as this was preventing compilation. Fix **strip**(1) use: `mono-runtimes.targets` was trying to use `strip -S` on macOS, but the value of `%(_MonoRuntime.Strip)` was quoted, and thus attempted to execute `"strip -S" ...`, which failed. Move the `-S` into a new `%(_MonoRuntime.StripFlags)` value. Fixup `mono-runtimes.targets` and related files so that `$(MonoSourceFullPath)` is used instead of a relative path. This helps alleviate the "mental math" of determining the relative path to the Mono checkout. Plus, the Mono checkout is supposed to be overridable, e.g. commit d205cab2, and using `$(MonoSourceFullPath)` supports that. Download and install `android.jar` for all supported API levels. Fix the `Mono.Android.csproj` build so that `Mono.Android.dll` is stored in a per-API-level intermediate directory. Otherwise, if e.g. API-10 is built after API-23, the API-23 version will be installed, but the JCW build will fail. Additionally, API-24 requires using `javac -source 1.8 -target 1.8`, not 1.6. Fix `Mono.Android/metadata` to use the correct `merge.SourceFile` filename of `Profiles/api-24.xml.in`. Without that fix, API-24 won't build because `NumericShaper.GetContextualShaper()` is emitted twice, and the C# compiler doesn't like that. Disable use of `-lz` when building for Windows. Windows doesn't contain a `Z.DLL` to link against. [^0]: https://en.wikipedia.org/wiki/Leeroy_Jenkins [^1]: https://www.youtube.com/watch?v=hooKVstzbz0
2016-07-18 15:42:39 +03:00
{900A0F71-BAAD-417A-8D1A-8D330297CDD0}.Release|AnyCPU.ActiveCfg = Release|Any CPU
{900A0F71-BAAD-417A-8D1A-8D330297CDD0}.Release|AnyCPU.Build.0 = Release|Any CPU
Sanitize Xamarin.Android.sln: fix several inconsistency bits. (#1159) Manually editing solution file is uncool and error prone, but since the entire xamarin-android source tree is not designed cleanly it is impossible to use IDEs to do the right job. As stated at https://github.com/xamarin/xamarin-android/issues/1129 , we should eliminate this Xamarin.Android.sln as a source file and it should be only generated, not directly committed to the tree. But to achieve that we first need to find the right structure and right content. So far, there were handful of issues that either missed or incorrectly added solution items with inconsistent configurations. These inconsistent parts were found by the solution content analyzer at https://github.com/xamarin/xamarin-android/issues/1129#issuecomment-355484902
2018-01-09 17:55:30 +03:00
{900A0F71-BAAD-417A-8D1A-8D330297CDD0}.XAIntegrationDebug|AnyCPU.ActiveCfg = Debug|Any CPU
{900A0F71-BAAD-417A-8D1A-8D330297CDD0}.XAIntegrationDebug|AnyCPU.Build.0 = Debug|Any CPU
{900A0F71-BAAD-417A-8D1A-8D330297CDD0}.XAIntegrationRelease|AnyCPU.ActiveCfg = Release|Any CPU
{900A0F71-BAAD-417A-8D1A-8D330297CDD0}.XAIntegrationRelease|AnyCPU.Build.0 = Release|Any CPU
Fix line endings
2016-07-06 18:09:45 +03:00
{E248B2CA-303B-4645-ADDC-9D4459D550FD}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
{E248B2CA-303B-4645-ADDC-9D4459D550FD}.Debug|AnyCPU.Build.0 = Debug|Any CPU
{E248B2CA-303B-4645-ADDC-9D4459D550FD}.Release|AnyCPU.ActiveCfg = Release|Any CPU
{E248B2CA-303B-4645-ADDC-9D4459D550FD}.Release|AnyCPU.Build.0 = Release|Any CPU
Sanitize Xamarin.Android.sln: fix several inconsistency bits. (#1159) Manually editing solution file is uncool and error prone, but since the entire xamarin-android source tree is not designed cleanly it is impossible to use IDEs to do the right job. As stated at https://github.com/xamarin/xamarin-android/issues/1129 , we should eliminate this Xamarin.Android.sln as a source file and it should be only generated, not directly committed to the tree. But to achieve that we first need to find the right structure and right content. So far, there were handful of issues that either missed or incorrectly added solution items with inconsistent configurations. These inconsistent parts were found by the solution content analyzer at https://github.com/xamarin/xamarin-android/issues/1129#issuecomment-355484902
2018-01-09 17:55:30 +03:00
{E248B2CA-303B-4645-ADDC-9D4459D550FD}.XAIntegrationDebug|AnyCPU.ActiveCfg = Debug|Any CPU
{E248B2CA-303B-4645-ADDC-9D4459D550FD}.XAIntegrationDebug|AnyCPU.Build.0 = Debug|Any CPU
{E248B2CA-303B-4645-ADDC-9D4459D550FD}.XAIntegrationRelease|AnyCPU.ActiveCfg = Release|Any CPU
{E248B2CA-303B-4645-ADDC-9D4459D550FD}.XAIntegrationRelease|AnyCPU.Build.0 = Release|Any CPU
[System.Drawing.Primitives] Add System.Drawing.Primitives.dll Facade (#121) Xamarin.Android needs to support [.NET Standard 1.6][0], which mentions a [`System.Drawing.Primitives.dll` assembly][1] which has not previously been supported or shipped. `System.Drawing.Primitives.dll` contains `System.Drawing.Point` and related typees, which Xamarin.Android places into `Mono.Android.dll`. Add a new `System.Drawing.Primitives.dll` assembly to use as a *facade assembly*, which contains [type forwarders][2] to "redirect" the types from `System.Drawing.Primitives.dll` to the corresponding types within `Mono.Android.dll`. [0]: https://docs.microsoft.com/en-us/dotnet/articles/core/tutorials/libraries [1]: https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md#list-of-net-corefx-apis-and-their-associated-net-platform-standard-version [2]: https://msdn.microsoft.com/en-us/library/ms404275(v=vs.110).aspx
2016-07-15 23:42:03 +03:00
{C9FF2E4D-D927-479E-838B-647C16763F64}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
{C9FF2E4D-D927-479E-838B-647C16763F64}.Debug|AnyCPU.Build.0 = Debug|Any CPU
{C9FF2E4D-D927-479E-838B-647C16763F64}.Release|AnyCPU.ActiveCfg = Release|Any CPU
{C9FF2E4D-D927-479E-838B-647C16763F64}.Release|AnyCPU.Build.0 = Release|Any CPU
{C9FF2E4D-D927-479E-838B-647C16763F64}.XAIntegrationDebug|AnyCPU.ActiveCfg = Debug|Any CPU
{C9FF2E4D-D927-479E-838B-647C16763F64}.XAIntegrationDebug|AnyCPU.Build.0 = Debug|Any CPU
Sanitize Xamarin.Android.sln: fix several inconsistency bits. (#1159) Manually editing solution file is uncool and error prone, but since the entire xamarin-android source tree is not designed cleanly it is impossible to use IDEs to do the right job. As stated at https://github.com/xamarin/xamarin-android/issues/1129 , we should eliminate this Xamarin.Android.sln as a source file and it should be only generated, not directly committed to the tree. But to achieve that we first need to find the right structure and right content. So far, there were handful of issues that either missed or incorrectly added solution items with inconsistent configurations. These inconsistent parts were found by the solution content analyzer at https://github.com/xamarin/xamarin-android/issues/1129#issuecomment-355484902
2018-01-09 17:55:30 +03:00
{C9FF2E4D-D927-479E-838B-647C16763F64}.XAIntegrationRelease|AnyCPU.ActiveCfg = Release|Any CPU
{C9FF2E4D-D927-479E-838B-647C16763F64}.XAIntegrationRelease|AnyCPU.Build.0 = Release|Any CPU
[bundle] Add `CreateBundle` target. (#140) Building Mono on Windows is a PITA, and commit 0c073f67 added support to cross-compile Mono for Windows so that Mono could be built from macOS or Linux. The unstated goal of that work was to -- eventually -- build the Mono runtimes *for Windows* on e.g. macOS, *bundle* those runtimes, and then we could update the build process to *download* a pre-built bundle of mono runtimes so that we can ~sanely build xamarin-android on Windows without building *Mono* on Windows. Part Two of this cunning plan involves creating the bundle of built mono runtimes. This in turn got rather complicated because instead of doing the *simple* thing of invoking **zip**(1), I instead wanted to create and use a `<Zip/>` MSBuild task, as this would allow us to specify in one place -- `mono-runtimes.targets` -- which files should be bundled, instead of bundling e.g. everything in `bin/Debug`, which would grab considerably more than just the mono bits. Adding a `<Zip/>` task in turn involves determining which Zip implementation to use, and what assembly to put it in; the obvious answer is to use `libzip`/`libZipSharp.dll` and place it into `Xamarin.Android.Tools.BootstrapTasks.dll` -- which is how we did it -- but this answer was tricky, due to a circular dependency problem: `libzip.mdproj` depends on `android-runtimes.mdproj` which depends on `Xamarin.Android.Tools.BootstrapTasks.dll`. Consequently, adding `libzip.mdproj` as a dependency to `Xamarin.Android.Tools.BootstrapTasks.dll` *doesn't work*. (Question: Why use libzip? Why not use System.IO.Compression? Answer: Because I'd like to be able to update the `<UnzipDirectoryChildren/>` task to use `libzip` instead of "shelling out" to **zip**(1) *like an animal*.) Step 1 is removing the circular dependency. `libzip.mdproj` depends on `android-runtimes.mdproj` because of MXE: `android-runtimes.mdproj` configures the MXE build environment to generate a Windows `libzip.dll` native library, if needed. The fix: introduce a new `libzip-windows.mdproj` project which performs the MXE-based build. This allows `libzip.mdproj` to no longer depend on `android-runtimes.mdproj`; `libzip-windows.mdproj` does. This also involves "refactoring" `libzip.mdproj` so that the build logic can be shared with `libzip-windows.mdproj`. Additionally, improve `libzip.mdproj` so that the native libraries are also set as a `@(Content)` build action. This allows e.g. `libzip.3.0.dylib` to be properly copied into `bin/BuildDebug`, as that's the `$(OutputPath)` of `Xamarin.Android.Tools.BootstrapTasks.csproj`. Step 2 is adding `libZipSharp.csproj` as a `@(ProjectReference)` to `Xamarin.Android.Tools.BootstrapTasks.csproj`. This requires bumping `Xamarin.Android.Tools.BootstrapTasks.csproj` to target .NET 4.5.1, which allows us to add the new `<Zip/>` task, as well as a new `<GitCommit/>` task (so we can determine the abbreviated commit hash of the mono checkout, for encoding into the filename). Step 3 is updating `mono-runtimes.targets` so that the Windows cross-compilers are built into `bin/$(Configuration)/lib/mandroid`, as this matches what is currently done internally. Step 4 is adding a new `build-tools/bundle.mdproj` project with a `CreateBundle` targtet, which will create the file: $(OutputPath)\bundle-$(Configuration)-libzip=$(libzip-hash),llvm=$(llvm-hash),mono=$(mono-hash).zip`. Uploading the `bundle-*.zip` files will be handled by Jenkins as a post-build task. Not yet done: *using* `bundle-*.zip` so that mono/etc. builds can be skipped, *greatly* improving build times.
2016-08-11 00:28:53 +03:00
{0DE278D6-000F-4001-BB98-187C0AF58A61}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
{0DE278D6-000F-4001-BB98-187C0AF58A61}.Debug|AnyCPU.Build.0 = Debug|Any CPU
{0DE278D6-000F-4001-BB98-187C0AF58A61}.Release|AnyCPU.ActiveCfg = Release|Any CPU
{0DE278D6-000F-4001-BB98-187C0AF58A61}.Release|AnyCPU.Build.0 = Release|Any CPU
{0DE278D6-000F-4001-BB98-187C0AF58A61}.XAIntegrationDebug|AnyCPU.ActiveCfg = Debug|Any CPU
{0DE278D6-000F-4001-BB98-187C0AF58A61}.XAIntegrationDebug|AnyCPU.Build.0 = Debug|Any CPU
{0DE278D6-000F-4001-BB98-187C0AF58A61}.XAIntegrationRelease|AnyCPU.ActiveCfg = Release|Any CPU
{0DE278D6-000F-4001-BB98-187C0AF58A61}.XAIntegrationRelease|AnyCPU.Build.0 = Release|Any CPU
{1640725C-4DB8-4D8D-BC96-74E688A06EEF}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
{1640725C-4DB8-4D8D-BC96-74E688A06EEF}.Debug|AnyCPU.Build.0 = Debug|Any CPU
{1640725C-4DB8-4D8D-BC96-74E688A06EEF}.Release|AnyCPU.ActiveCfg = Release|Any CPU
{1640725C-4DB8-4D8D-BC96-74E688A06EEF}.Release|AnyCPU.Build.0 = Release|Any CPU
{1640725C-4DB8-4D8D-BC96-74E688A06EEF}.XAIntegrationDebug|AnyCPU.ActiveCfg = Debug|Any CPU
{1640725C-4DB8-4D8D-BC96-74E688A06EEF}.XAIntegrationDebug|AnyCPU.Build.0 = Debug|Any CPU
{1640725C-4DB8-4D8D-BC96-74E688A06EEF}.XAIntegrationRelease|AnyCPU.ActiveCfg = Release|Any CPU
{1640725C-4DB8-4D8D-BC96-74E688A06EEF}.XAIntegrationRelease|AnyCPU.Build.0 = Release|Any CPU
[xa-prep-tasks] Use the Mono bundle (#162) Context: https://github.com/xamarin/xamarin-android/commit/fbfd676c102c63e4e06e750857b178725e33450c Stage 3 of the cunning plan is to (attempt to) use the mono bundle introduced in commit fbfd676c. This "simple" desire (ha!) re-raises the architectural project dependency issue "solved" in fbfd676c, but first, a simple question: What should download the mono bundle? There are two plausible answers: 1. `make prepare` can (somehow) handle it. 2. MSBuild can (somehow) handle it. Both are plausible. The problem with using `make` targets (1) is there is increased potential for "duplication" -- duplication of the bundle filename, downloading it, and extracting it. Plus, `make` isn't "Windows friendly", in that GNU make isn't (normally) present with Visual Studio. (`NMAKE` is, but the Makefiles in this project are not compatible with `NMAKE`.) Which brings us to MSBuild (2): can it handle the task? To tackle that, we need to be able to have an MSBuild task project which has *no dependencies*, so that it can download and extract the mono bundle *before anything else runs*, as it may be downloading contents which mean that other projects don't *need* to run. The need for a "pre-bootstrap" task assembly -- called `xa-prep-tasks` -- thus "undoes" *some* of the logic regarding `libzip-windows.mdproj` and the `<Zip/>` task from fbfd676c: it isn't *possible* to rely on `libzip` from a "pre-build" state, as `libzip` is one of the things in the mono bundle, so now we need *two* "bootstrap" task assemblies: one without a `libzip` dependency -- `xa-prep-tasks.dll` -- and one *with* a `libzip` dependency -- `Xamarin.Android.Tools.BootstrapTasks.dll` Move tasks which don't currently require `libzip` -- or won't in the future, or laziness -- from `Xamarin.Android.Tools.BootstrapTasks.dll` and move them into `xa-prep-tasks.dll`. With that architectural compromise in place, add `xa-prep-tasks` as a `@(ProjectReference)` to various projects to help ensure it's built *first*, and rearchitect `bundle.mdproj` so that `xa-prep-tasks.targets` and `bundle.targets` can use the same targets to compute the bundle filename, now in `build-tools/bundle/bundle-path.targets`. Add a post-build step to `xa-prep-tasks.csproj` which downloads and extracts the expected mono bundle. One "problem" (feature?) is that the new `<SystemUnzip/>` task doesn't report errors as errors when unzip'ing the file. This turns out to be fine here because when downloading the mono bundle from Azure we don't get a 404 *anyway* -- Azure instead returns an XML document containing an error message (wat?!). We can thus ignore most error handling entirely...though we're *also* ignoring any checking for invalid downloads, which is something we should address in the future. Update the varioous project files so that they won't attempt to rebuild binaries that were present in the mono bundle.
2016-08-16 23:02:48 +03:00
{7CE69551-BD73-4726-ACAA-AAF89C84BAF8}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
{7CE69551-BD73-4726-ACAA-AAF89C84BAF8}.Debug|AnyCPU.Build.0 = Debug|Any CPU
{7CE69551-BD73-4726-ACAA-AAF89C84BAF8}.Release|AnyCPU.ActiveCfg = Release|Any CPU
{7CE69551-BD73-4726-ACAA-AAF89C84BAF8}.Release|AnyCPU.Build.0 = Release|Any CPU
{7CE69551-BD73-4726-ACAA-AAF89C84BAF8}.XAIntegrationDebug|AnyCPU.ActiveCfg = Debug|Any CPU
{7CE69551-BD73-4726-ACAA-AAF89C84BAF8}.XAIntegrationDebug|AnyCPU.Build.0 = Debug|Any CPU
Sanitize Xamarin.Android.sln: fix several inconsistency bits. (#1159) Manually editing solution file is uncool and error prone, but since the entire xamarin-android source tree is not designed cleanly it is impossible to use IDEs to do the right job. As stated at https://github.com/xamarin/xamarin-android/issues/1129 , we should eliminate this Xamarin.Android.sln as a source file and it should be only generated, not directly committed to the tree. But to achieve that we first need to find the right structure and right content. So far, there were handful of issues that either missed or incorrectly added solution items with inconsistent configurations. These inconsistent parts were found by the solution content analyzer at https://github.com/xamarin/xamarin-android/issues/1129#issuecomment-355484902
2018-01-09 17:55:30 +03:00
{7CE69551-BD73-4726-ACAA-AAF89C84BAF8}.XAIntegrationRelease|AnyCPU.ActiveCfg = Release|Any CPU
{7CE69551-BD73-4726-ACAA-AAF89C84BAF8}.XAIntegrationRelease|AnyCPU.Build.0 = Release|Any CPU
Bump to Java.Interop/f44a11f6 and use its Cecil library (#303) Updated all the projects to use the `Xamarin.Android.Cecil` library instead of `Mono.Cecil` nuget package.
2016-11-18 18:04:49 +03:00
{15945D4B-FF56-4BCC-B598-2718D199DD08}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
{15945D4B-FF56-4BCC-B598-2718D199DD08}.Debug|AnyCPU.Build.0 = Debug|Any CPU
{15945D4B-FF56-4BCC-B598-2718D199DD08}.Release|AnyCPU.ActiveCfg = Release|Any CPU
{15945D4B-FF56-4BCC-B598-2718D199DD08}.Release|AnyCPU.Build.0 = Release|Any CPU
{15945D4B-FF56-4BCC-B598-2718D199DD08}.XAIntegrationDebug|AnyCPU.ActiveCfg = Debug|Any CPU
{15945D4B-FF56-4BCC-B598-2718D199DD08}.XAIntegrationDebug|AnyCPU.Build.0 = Debug|Any CPU
Sanitize Xamarin.Android.sln: fix several inconsistency bits. (#1159) Manually editing solution file is uncool and error prone, but since the entire xamarin-android source tree is not designed cleanly it is impossible to use IDEs to do the right job. As stated at https://github.com/xamarin/xamarin-android/issues/1129 , we should eliminate this Xamarin.Android.sln as a source file and it should be only generated, not directly committed to the tree. But to achieve that we first need to find the right structure and right content. So far, there were handful of issues that either missed or incorrectly added solution items with inconsistent configurations. These inconsistent parts were found by the solution content analyzer at https://github.com/xamarin/xamarin-android/issues/1129#issuecomment-355484902
2018-01-09 17:55:30 +03:00
{15945D4B-FF56-4BCC-B598-2718D199DD08}.XAIntegrationRelease|AnyCPU.ActiveCfg = Release|Any CPU
{15945D4B-FF56-4BCC-B598-2718D199DD08}.XAIntegrationRelease|AnyCPU.Build.0 = Release|Any CPU
Bump to Java.Interop/f44a11f6 and use its Cecil library (#303) Updated all the projects to use the `Xamarin.Android.Cecil` library instead of `Mono.Cecil` nuget package.
2016-11-18 18:04:49 +03:00
{C0487169-8F81-497F-919E-EB42B1D0243F}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
{C0487169-8F81-497F-919E-EB42B1D0243F}.Debug|AnyCPU.Build.0 = Debug|Any CPU
{C0487169-8F81-497F-919E-EB42B1D0243F}.Release|AnyCPU.ActiveCfg = Release|Any CPU
{C0487169-8F81-497F-919E-EB42B1D0243F}.Release|AnyCPU.Build.0 = Release|Any CPU
{C0487169-8F81-497F-919E-EB42B1D0243F}.XAIntegrationDebug|AnyCPU.ActiveCfg = Debug|Any CPU
{C0487169-8F81-497F-919E-EB42B1D0243F}.XAIntegrationDebug|AnyCPU.Build.0 = Debug|Any CPU
Sanitize Xamarin.Android.sln: fix several inconsistency bits. (#1159) Manually editing solution file is uncool and error prone, but since the entire xamarin-android source tree is not designed cleanly it is impossible to use IDEs to do the right job. As stated at https://github.com/xamarin/xamarin-android/issues/1129 , we should eliminate this Xamarin.Android.sln as a source file and it should be only generated, not directly committed to the tree. But to achieve that we first need to find the right structure and right content. So far, there were handful of issues that either missed or incorrectly added solution items with inconsistent configurations. These inconsistent parts were found by the solution content analyzer at https://github.com/xamarin/xamarin-android/issues/1129#issuecomment-355484902
2018-01-09 17:55:30 +03:00
{C0487169-8F81-497F-919E-EB42B1D0243F}.XAIntegrationRelease|AnyCPU.ActiveCfg = Release|Any CPU
{C0487169-8F81-497F-919E-EB42B1D0243F}.XAIntegrationRelease|AnyCPU.Build.0 = Release|Any CPU
[remap-assembly-ref] Properly add to the XA solution (#351) - the platform was set to x86 only - the project was defined, but not added to the solution tree
2017-01-05 21:20:50 +03:00
{C876DA71-8573-4CEF-9149-716D72455ED4}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
{C876DA71-8573-4CEF-9149-716D72455ED4}.Debug|AnyCPU.Build.0 = Debug|Any CPU
{C876DA71-8573-4CEF-9149-716D72455ED4}.Release|AnyCPU.ActiveCfg = Release|Any CPU
{C876DA71-8573-4CEF-9149-716D72455ED4}.Release|AnyCPU.Build.0 = Release|Any CPU
{C876DA71-8573-4CEF-9149-716D72455ED4}.XAIntegrationDebug|AnyCPU.ActiveCfg = Debug|Any CPU
{C876DA71-8573-4CEF-9149-716D72455ED4}.XAIntegrationDebug|AnyCPU.Build.0 = Debug|Any CPU
Sanitize Xamarin.Android.sln: fix several inconsistency bits. (#1159) Manually editing solution file is uncool and error prone, but since the entire xamarin-android source tree is not designed cleanly it is impossible to use IDEs to do the right job. As stated at https://github.com/xamarin/xamarin-android/issues/1129 , we should eliminate this Xamarin.Android.sln as a source file and it should be only generated, not directly committed to the tree. But to achieve that we first need to find the right structure and right content. So far, there were handful of issues that either missed or incorrectly added solution items with inconsistent configurations. These inconsistent parts were found by the solution content analyzer at https://github.com/xamarin/xamarin-android/issues/1129#issuecomment-355484902
2018-01-09 17:55:30 +03:00
{C876DA71-8573-4CEF-9149-716D72455ED4}.XAIntegrationRelease|AnyCPU.ActiveCfg = Release|Any CPU
{C876DA71-8573-4CEF-9149-716D72455ED4}.XAIntegrationRelease|AnyCPU.Build.0 = Release|Any CPU
[build] Auto-Provision Dependencies (#447) The #runtime team is requesting that Xamarin.Android support "auto-provisioning": the ability to track dependency *versions*, and if there is a "version mismatch", *install* a dependency that satisfies the minimum. The primary use case is Mono itself: there is a desire to build xamarin-android *itself* against mono/master, to see what breaks. (Does the C# compiler break things? Does the JIT hang? etc.) Extend the existing `@(RequiredProgram)` infrastructure to attempt to support this: * `%(RequiredProgram.MinimumVersion)`: The minimum program version that is supported. * `%(RequiredProgram.MaximumVersion)`: The maximum program version that is supported. * `%(RequiredProgram.CurrentVersionCommand)`: A command to execute to obtain the current program version. Defaults to `%(RequiredProgram.Identity) --version`. * `%(RequiredProgram.MinimumUrl)`: URL to download "something" to use to obtain a version of the program that satisfies `%(MinimumVersion)`. * `%(RequiredProgram.Install)`: Command to execute which installs the minimum version of the program. `%(RequiredProgram.CurrentVersionCommand)`, `%(RequiredProgram.MinimumUrl)`, and `%(RequiredProgram.Install)` can all be "overridden" for platform-specific values by prefixing the value with `$(HostOSName)` and/or `$(HostOS)`. Thus, macOS-specific values can be stored into e.g. `%(RequiredProgram.DarwinMinimumUrl)` and `%(RequiredProgram.DarwinInstall)`. Auto-Provisioning is controlled by the new `$(AutoProvision)` property, which can be provided in `Configuration.Override.props`. It defaults to `False`. If the `$(AutoProvisionUsesSudo)` MSBuild property is True, then `sudo` is used to invoke all install commands.
2017-02-16 19:37:28 +03:00
{C845ECC0-2ED3-498E-8EA8-02EF7AC6E9AD}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
{C845ECC0-2ED3-498E-8EA8-02EF7AC6E9AD}.Debug|AnyCPU.Build.0 = Debug|Any CPU
{C845ECC0-2ED3-498E-8EA8-02EF7AC6E9AD}.Release|AnyCPU.ActiveCfg = Release|Any CPU
{C845ECC0-2ED3-498E-8EA8-02EF7AC6E9AD}.Release|AnyCPU.Build.0 = Release|Any CPU
{C845ECC0-2ED3-498E-8EA8-02EF7AC6E9AD}.XAIntegrationDebug|AnyCPU.ActiveCfg = Debug|Any CPU
{C845ECC0-2ED3-498E-8EA8-02EF7AC6E9AD}.XAIntegrationDebug|AnyCPU.Build.0 = Debug|Any CPU
Sanitize Xamarin.Android.sln: fix several inconsistency bits. (#1159) Manually editing solution file is uncool and error prone, but since the entire xamarin-android source tree is not designed cleanly it is impossible to use IDEs to do the right job. As stated at https://github.com/xamarin/xamarin-android/issues/1129 , we should eliminate this Xamarin.Android.sln as a source file and it should be only generated, not directly committed to the tree. But to achieve that we first need to find the right structure and right content. So far, there were handful of issues that either missed or incorrectly added solution items with inconsistent configurations. These inconsistent parts were found by the solution content analyzer at https://github.com/xamarin/xamarin-android/issues/1129#issuecomment-355484902
2018-01-09 17:55:30 +03:00
{C845ECC0-2ED3-498E-8EA8-02EF7AC6E9AD}.XAIntegrationRelease|AnyCPU.ActiveCfg = Release|Any CPU
{C845ECC0-2ED3-498E-8EA8-02EF7AC6E9AD}.XAIntegrationRelease|AnyCPU.Build.0 = Release|Any CPU
[Xamarin.Android.Build.Tasks] Use GPL'd ProGuard (#386) **Background**: many Android SDK features rely on [ProGuard][0], a Java bytecode manipulation library. Some of these features include linking (shrinking) bytecode and [multidex][1]. Xamarin.Android has historically relied on the version of ProGuard bundled with the Android SDK, which is how the `<Proguard/>` task and `@(ProguardConfiguration)` build actions work. Unfortunately, the version of ProGuard bundled with the Android SDK is, at this point, *ancient* (ProGuard v4.7; current version is v5.3), and (more importantly) ProGuard v4.7 doesn't support JDK 1.8 bytecode. Meaning if the end-developer references a Java library targeting JDK 1.8 -- e.g. the Android Support Library v25 -- then the version of ProGuard bundled with the Android SDK *cannot process that library*. This in turn means that the `<Proguard/>` task and `@(ProguardConfiguration)` build actions don't work/are useless. Native Java development "works around" this problem by using Gradle as the build system, and Java projects are configured to download and install a newer version of ProGuard via Gradle. Xamarin.Android projects do not use Gradle, nor will they. (At least not in the foreseeable future.) **Solution**: We have communicated with Eric Lafortune, maintainer of ProGuard, about distributing a newer ProGuard with Xamarin.Android. He replied: > From a licensing point of view, you shouldn't need an exception to > the GPL in many practical configurations: > > * if you indeed run ProGuard in a separate JVM The `<Proguard/>` task is a [`ToolTask`][2], which operates by creating a new process to invoke the specified tool. We thus are *already* using ProGuard within a "separate JVM", and no architectural change is required to comply with ProGuard's licensing without altering Xamarin.Android's licensing. The current ProGuard sources (v5.3.2) have been imported into the [xamarin/proguard][3] module, and we will be using the `xamarin/proguard` module as a git submodule for build purposes. [0]: https://www.guardsquare.com/en/proguard [1]: https://developer.android.com/studio/build/multidex.html [2]: https://msdn.microsoft.com/en-us/library/microsoft.build.utilities.tooltask.aspx [3]: http://github.com/xamarin/proguard/
2017-03-06 18:00:36 +03:00
{4B9D96BB-95AB-44E8-9F87-13B12C8BCED1}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
{4B9D96BB-95AB-44E8-9F87-13B12C8BCED1}.Debug|AnyCPU.Build.0 = Debug|Any CPU
{4B9D96BB-95AB-44E8-9F87-13B12C8BCED1}.Release|AnyCPU.ActiveCfg = Release|Any CPU
{4B9D96BB-95AB-44E8-9F87-13B12C8BCED1}.Release|AnyCPU.Build.0 = Release|Any CPU
{4B9D96BB-95AB-44E8-9F87-13B12C8BCED1}.XAIntegrationDebug|AnyCPU.ActiveCfg = Debug|Any CPU
{4B9D96BB-95AB-44E8-9F87-13B12C8BCED1}.XAIntegrationDebug|AnyCPU.Build.0 = Debug|Any CPU
Sanitize Xamarin.Android.sln: fix several inconsistency bits. (#1159) Manually editing solution file is uncool and error prone, but since the entire xamarin-android source tree is not designed cleanly it is impossible to use IDEs to do the right job. As stated at https://github.com/xamarin/xamarin-android/issues/1129 , we should eliminate this Xamarin.Android.sln as a source file and it should be only generated, not directly committed to the tree. But to achieve that we first need to find the right structure and right content. So far, there were handful of issues that either missed or incorrectly added solution items with inconsistent configurations. These inconsistent parts were found by the solution content analyzer at https://github.com/xamarin/xamarin-android/issues/1129#issuecomment-355484902
2018-01-09 17:55:30 +03:00
{4B9D96BB-95AB-44E8-9F87-13B12C8BCED1}.XAIntegrationRelease|AnyCPU.ActiveCfg = Release|Any CPU
{4B9D96BB-95AB-44E8-9F87-13B12C8BCED1}.XAIntegrationRelease|AnyCPU.Build.0 = Release|Any CPU
[api-xml-adjuster] move from tools to build-tools (#485) It is build-time tool and should not be used in any production environment.
2017-03-15 16:46:20 +03:00
{8A6CB07C-E493-4A4F-AB94-038645A27118}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
{8A6CB07C-E493-4A4F-AB94-038645A27118}.Debug|AnyCPU.Build.0 = Debug|Any CPU
{8A6CB07C-E493-4A4F-AB94-038645A27118}.Release|AnyCPU.ActiveCfg = Release|Any CPU
{8A6CB07C-E493-4A4F-AB94-038645A27118}.Release|AnyCPU.Build.0 = Release|Any CPU
{8A6CB07C-E493-4A4F-AB94-038645A27118}.XAIntegrationDebug|AnyCPU.ActiveCfg = Debug|Any CPU
{8A6CB07C-E493-4A4F-AB94-038645A27118}.XAIntegrationDebug|AnyCPU.Build.0 = Debug|Any CPU
Sanitize Xamarin.Android.sln: fix several inconsistency bits. (#1159) Manually editing solution file is uncool and error prone, but since the entire xamarin-android source tree is not designed cleanly it is impossible to use IDEs to do the right job. As stated at https://github.com/xamarin/xamarin-android/issues/1129 , we should eliminate this Xamarin.Android.sln as a source file and it should be only generated, not directly committed to the tree. But to achieve that we first need to find the right structure and right content. So far, there were handful of issues that either missed or incorrectly added solution items with inconsistent configurations. These inconsistent parts were found by the solution content analyzer at https://github.com/xamarin/xamarin-android/issues/1129#issuecomment-355484902
2018-01-09 17:55:30 +03:00
{8A6CB07C-E493-4A4F-AB94-038645A27118}.XAIntegrationRelease|AnyCPU.ActiveCfg = Release|Any CPU
{8A6CB07C-E493-4A4F-AB94-038645A27118}.XAIntegrationRelease|AnyCPU.Build.0 = Release|Any CPU
[javadoc2mdoc] import javadoc-to-mdoc from monodroid/fbb0c9d (#500) ... with some changes: - It turned out that we don't have Ionic.Zip, so it is replaced with LibZipSharp (with new entry removal methods thanks to grendel). - We don't import README.samples that indicates some internals. javadoc-to-mdoc is a tool that converts Javadocs or DroidDocs into monodoc format. Then it can be converted to C# docs (csc /doc) or HTML using "mdoc" tool in mono (we also build and ship it within `lib/mandroid`).
2017-03-17 21:18:55 +03:00
{E0890301-F75F-40E7-B008-54C28B3BA542}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
{E0890301-F75F-40E7-B008-54C28B3BA542}.Debug|AnyCPU.Build.0 = Debug|Any CPU
{E0890301-F75F-40E7-B008-54C28B3BA542}.Release|AnyCPU.ActiveCfg = Release|Any CPU
{E0890301-F75F-40E7-B008-54C28B3BA542}.Release|AnyCPU.Build.0 = Release|Any CPU
{E0890301-F75F-40E7-B008-54C28B3BA542}.XAIntegrationDebug|AnyCPU.ActiveCfg = Debug|Any CPU
{E0890301-F75F-40E7-B008-54C28B3BA542}.XAIntegrationDebug|AnyCPU.Build.0 = Debug|Any CPU
Sanitize Xamarin.Android.sln: fix several inconsistency bits. (#1159) Manually editing solution file is uncool and error prone, but since the entire xamarin-android source tree is not designed cleanly it is impossible to use IDEs to do the right job. As stated at https://github.com/xamarin/xamarin-android/issues/1129 , we should eliminate this Xamarin.Android.sln as a source file and it should be only generated, not directly committed to the tree. But to achieve that we first need to find the right structure and right content. So far, there were handful of issues that either missed or incorrectly added solution items with inconsistent configurations. These inconsistent parts were found by the solution content analyzer at https://github.com/xamarin/xamarin-android/issues/1129#issuecomment-355484902
2018-01-09 17:55:30 +03:00
{E0890301-F75F-40E7-B008-54C28B3BA542}.XAIntegrationRelease|AnyCPU.ActiveCfg = Release|Any CPU
{E0890301-F75F-40E7-B008-54C28B3BA542}.XAIntegrationRelease|AnyCPU.Build.0 = Release|Any CPU
[javadoc2mdoc] import javadoc-to-mdoc from monodroid/fbb0c9d (#500) ... with some changes: - It turned out that we don't have Ionic.Zip, so it is replaced with LibZipSharp (with new entry removal methods thanks to grendel). - We don't import README.samples that indicates some internals. javadoc-to-mdoc is a tool that converts Javadocs or DroidDocs into monodoc format. Then it can be converted to C# docs (csc /doc) or HTML using "mdoc" tool in mono (we also build and ship it within `lib/mandroid`).
2017-03-17 21:18:55 +03:00
{A87352E6-CE7F-4346-B6B1-586AE931C0A7}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
{A87352E6-CE7F-4346-B6B1-586AE931C0A7}.Debug|AnyCPU.Build.0 = Debug|Any CPU
{A87352E6-CE7F-4346-B6B1-586AE931C0A7}.Release|AnyCPU.ActiveCfg = Release|Any CPU
{A87352E6-CE7F-4346-B6B1-586AE931C0A7}.Release|AnyCPU.Build.0 = Release|Any CPU
{A87352E6-CE7F-4346-B6B1-586AE931C0A7}.XAIntegrationDebug|AnyCPU.ActiveCfg = Debug|Any CPU
{A87352E6-CE7F-4346-B6B1-586AE931C0A7}.XAIntegrationDebug|AnyCPU.Build.0 = Debug|Any CPU
Sanitize Xamarin.Android.sln: fix several inconsistency bits. (#1159) Manually editing solution file is uncool and error prone, but since the entire xamarin-android source tree is not designed cleanly it is impossible to use IDEs to do the right job. As stated at https://github.com/xamarin/xamarin-android/issues/1129 , we should eliminate this Xamarin.Android.sln as a source file and it should be only generated, not directly committed to the tree. But to achieve that we first need to find the right structure and right content. So far, there were handful of issues that either missed or incorrectly added solution items with inconsistent configurations. These inconsistent parts were found by the solution content analyzer at https://github.com/xamarin/xamarin-android/issues/1129#issuecomment-355484902
2018-01-09 17:55:30 +03:00
{A87352E6-CE7F-4346-B6B1-586AE931C0A7}.XAIntegrationRelease|AnyCPU.ActiveCfg = Release|Any CPU
{A87352E6-CE7F-4346-B6B1-586AE931C0A7}.XAIntegrationRelease|AnyCPU.Build.0 = Release|Any CPU
[create-vsix] Create `.vsix` files (#541) Visual Studio 2017 uses `.vsix` files for Xamarin.Android SDK support. A `.vsix` file is [ZIP container with additional metadata][0], and the [Microsoft.VSSDK.BuildTools NuGet package][1] contains various MSBuild targets and tools to assist in creating `.vsix` files. Add a new `build-tools/create-vsix/create-vsix.csproj` project to create the `bin/Build$(Configuration)/Xamarin.Android.Sdk*.vsix` file, so that we can plausibly provide per-build OSS Xamarin.Android releases that work with Visual Studio 2017. Unfortunately those tools were written on Windows, and not really well tested on macOS or Linux... In particular, there are case-sensitivity and directory-separator-char issues with the tooling, necessitating that `MONO_IOMAP=all` be exported in order to run them: MONO_IOMAP=all MONO_OPTIONS=--arch=64 msbuild \ build-tools/create-vsix/create-vsix.csproj /p:CreateVsixContainer=True Meanwhile, we're still attempting to allow things to be built with `xbuild` [^3]. Thread this needle by "special-casing" the `$(BuildDependsOn)`, `$(CopyVsixManifestFileDependsOn)`, and `$(DetokenizeVsixManifestFileDependsOn)` MSBuild properties so that when the `$(CreateVsixContainer)` MSBuild property is False -- the default -- no `.vsix` package will be created, and `xbuild` will be able to build the project. Similar needle threading is needed to "support" building on Linux: the Microsoft.VSSDK.BuildTools NuGet package uses case in an inconsistent fashion -- or is it `nuget`? -- which results in [failures when building on Linux][2] because `nuget` extracts e.g.: packages/Microsoft.VSSDK.BuildTools.15.0.26201/tools/vssdk/Microsoft.VsSDK.targets while Microsoft.VSSDK.BuildTools attempts to `<Import/>` the file: packages/Microsoft.VSSDK.BuildTools.15.0.26201/tools/VSSDK/Microsoft.VsSDK.targets `vssdk` != `VSSDK` on case-sensitive filesystems, so this results in an error on Ubuntu (and presumably case-senstive macOS as well). Handle the Linux case by extending the `xbuild` case: *even when* `$(CreateVsixContainer)` is True, we won't actually build the `.vsix` unless the `$(VsSDKInstall)` directory exists, which is the `tools/VSSDK` path. Building with `$(CreateVsixContainer)` set to True will require using `msbuild` with `MONO_IOMAP=all` and `MONO_OPPTIONS=--arch=64` exported, while using a case-insensitive filesystem. The new `make create-vsix CONFIGURATIONS=Debug` target can be used to explicitly create the `Xamarin.Android.Sdk*.vsix` file. One problem with creating `.vsix` files: macOS still defaults to using a 32-bit process for `mono`, and `make create-vsix` regularly fails for me with an `OutOfMemoryException` when attempting to generate a `.vsix` file ~600-700+MB in size. (Why so large? In part because for Debug configuration we're including un-`strip`'d native libraries; `libmonosgen-2.0.dll` is *237MB* in size (!); it's closer to 5MB when `strip`'d, but any un-`strip`'d MXE-generated native libraries to the `.vsix` file quickly results in `OutOfMemoryException`s.) A 64-bit mono can be used by using `mono64` -- which isn't easily done with `msbuild` -- or by using `mono --arch=64`, which *can* be done with `msbuild` by exporting `MONO_OPTIONS=--arch=64`. The `make create-vsix` target does this. Finally, once we have a `.visx` being created, we then examine the *contents* of the `.vsix` file, which is...weird: $MSBuild/Xamarin/Android/Xamarin.Android.CSharp.targets # Desirable $ReferenceAssemblies/Microsoft/Framework/MonoAndroid/v1.0/Xamarin.Android.CSharp.targets # wat? $ReferenceAssemblies/Microsoft/Framework/MonoAndroid/v1.0/Facades/Xamarin.Android.CSharp.targets # really?! $ReferenceAssemblies/Microsoft/Framework/MonoAndroid/v7.1/Xamarin.Android.CSharp.targets # !!!! Turns Out™, the problem was due to `@(ProjectReference)`. We're (ab)using `@(ProjectReference)` to explicitly specify project dependencies, and the (implicit) project build order. Unexpectedly (forgetten?), MSBuild *also* copies the *outputs* of `@(ProjectReference)`s into the `$(OutputPath)` of the current project. Since e.g. `Mono.Posix.csproj` had a reference on `Xamarin.Android.Build.Tasks.csproj`, the result of this is that the `$(OutputPath)` of `Mono.Posix.csproj` -- `$prefix/lib/xbuild-frameworks/MonoAndroid/v1.0` -- also contained the `%(None.CopyToOutputDirectory)` items from `Xamarin.Android.Build.Tasks.csproj`. Oops. The fix is to set `%(ProjectReference.Private)` to False, which disables this copying of additional and undesirable files. [0]: https://msdn.microsoft.com/en-us/library/dd997148.aspx [1]: https://www.nuget.org/packages/Microsoft.VSSDK.BuildTools/ [2]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-anroid-linux-pr-builder/297/consoleText [^3]: But for how much longer?
2017-04-05 18:49:37 +03:00
{94756FEB-1F64-411D-A18E-81B5158F776A}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
{94756FEB-1F64-411D-A18E-81B5158F776A}.Debug|AnyCPU.Build.0 = Debug|Any CPU
{94756FEB-1F64-411D-A18E-81B5158F776A}.Release|AnyCPU.ActiveCfg = Release|Any CPU
{94756FEB-1F64-411D-A18E-81B5158F776A}.Release|AnyCPU.Build.0 = Release|Any CPU
{94756FEB-1F64-411D-A18E-81B5158F776A}.XAIntegrationDebug|AnyCPU.ActiveCfg = Debug|Any CPU
{94756FEB-1F64-411D-A18E-81B5158F776A}.XAIntegrationDebug|AnyCPU.Build.0 = Debug|Any CPU
Sanitize Xamarin.Android.sln: fix several inconsistency bits. (#1159) Manually editing solution file is uncool and error prone, but since the entire xamarin-android source tree is not designed cleanly it is impossible to use IDEs to do the right job. As stated at https://github.com/xamarin/xamarin-android/issues/1129 , we should eliminate this Xamarin.Android.sln as a source file and it should be only generated, not directly committed to the tree. But to achieve that we first need to find the right structure and right content. So far, there were handful of issues that either missed or incorrectly added solution items with inconsistent configurations. These inconsistent parts were found by the solution content analyzer at https://github.com/xamarin/xamarin-android/issues/1129#issuecomment-355484902
2018-01-09 17:55:30 +03:00
{94756FEB-1F64-411D-A18E-81B5158F776A}.XAIntegrationRelease|AnyCPU.ActiveCfg = Release|Any CPU
{94756FEB-1F64-411D-A18E-81B5158F776A}.XAIntegrationRelease|AnyCPU.Build.0 = Release|Any CPU
Build netstandard.dll and System.Drawing.Primitives.dll facades (#572) Build `netstandard.dll` and `System.Drawing.Primitives.dll` facades The old project for `System.Drawing.Primitives` was removed in favor of building the assembly with the existing logic in Mono. Also add them to the bundle since we can't rebuild them if we just have the bundle. Update facades list in `MobileProfile.cs`; `netstandard.dll` and `System.ValueTuple.dll` were missing.
2017-04-21 23:06:08 +03:00
{93614CB8-4564-43B9-93B0-4AF4B3B16AAE}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
{93614CB8-4564-43B9-93B0-4AF4B3B16AAE}.Debug|AnyCPU.Build.0 = Debug|Any CPU
{93614CB8-4564-43B9-93B0-4AF4B3B16AAE}.Release|AnyCPU.ActiveCfg = Release|Any CPU
{93614CB8-4564-43B9-93B0-4AF4B3B16AAE}.Release|AnyCPU.Build.0 = Release|Any CPU
{93614CB8-4564-43B9-93B0-4AF4B3B16AAE}.XAIntegrationDebug|AnyCPU.ActiveCfg = Debug|Any CPU
{93614CB8-4564-43B9-93B0-4AF4B3B16AAE}.XAIntegrationDebug|AnyCPU.Build.0 = Debug|Any CPU
Sanitize Xamarin.Android.sln: fix several inconsistency bits. (#1159) Manually editing solution file is uncool and error prone, but since the entire xamarin-android source tree is not designed cleanly it is impossible to use IDEs to do the right job. As stated at https://github.com/xamarin/xamarin-android/issues/1129 , we should eliminate this Xamarin.Android.sln as a source file and it should be only generated, not directly committed to the tree. But to achieve that we first need to find the right structure and right content. So far, there were handful of issues that either missed or incorrectly added solution items with inconsistent configurations. These inconsistent parts were found by the solution content analyzer at https://github.com/xamarin/xamarin-android/issues/1129#issuecomment-355484902
2018-01-09 17:55:30 +03:00
{93614CB8-4564-43B9-93B0-4AF4B3B16AAE}.XAIntegrationRelease|AnyCPU.ActiveCfg = Release|Any CPU
{93614CB8-4564-43B9-93B0-4AF4B3B16AAE}.XAIntegrationRelease|AnyCPU.Build.0 = Release|Any CPU
[setup-windows] Infer install prefix from install location (#710) I'm not entirely sure what posessed me to use `Environment.GetCommandLineArgs()` to determine the location of `setup-windows.exe`, from which the installation prefix is derived. It seemed like a good idea at the time? Regardless, the problem with using `Environment.GetCommandLineArgs()` in this fashion is that you can't execute the utility without providing the full path name: > cd C:\xa-sdk\oss-xamarin.android_v7.4.99.60_Darwin-x86_64_master_4f3d604\bin\Debug\bin > .\setup-windows.exe setup-windows.exe: This program must be run from the `bin` directory. This is decidedly dumb. Update the logic to instead use `typeof(SetupWindows).Assembly.Location`. which will behave in a more reasonable fashion. Additionally, update `UsingJenkinsBuildArtifacts.md` so that the mentioned macOS+Windows versions actually contain `setup-windows.exe`, instead of hand-waving things away. Finally, fix `Xamarin.Android.sln` so that Visual Studio for Mac doesn't show an "Invalid configuration mapping" error status on the `setup-windows` project.
2017-08-02 18:36:06 +03:00
{73DF9E10-E933-4222-B8E1-F4536FFF9FAD}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
{73DF9E10-E933-4222-B8E1-F4536FFF9FAD}.Debug|AnyCPU.Build.0 = Debug|Any CPU
{73DF9E10-E933-4222-B8E1-F4536FFF9FAD}.Release|AnyCPU.ActiveCfg = Release|Any CPU
{73DF9E10-E933-4222-B8E1-F4536FFF9FAD}.Release|AnyCPU.Build.0 = Release|Any CPU
{73DF9E10-E933-4222-B8E1-F4536FFF9FAD}.XAIntegrationDebug|AnyCPU.ActiveCfg = Debug|Any CPU
{73DF9E10-E933-4222-B8E1-F4536FFF9FAD}.XAIntegrationDebug|AnyCPU.Build.0 = Debug|Any CPU
{73DF9E10-E933-4222-B8E1-F4536FFF9FAD}.XAIntegrationRelease|AnyCPU.ActiveCfg = Release|Any CPU
{73DF9E10-E933-4222-B8E1-F4536FFF9FAD}.XAIntegrationRelease|AnyCPU.Build.0 = Release|Any CPU
[Xamarin.Android.Build.Tasks] Use Xamarin.Android.Tools.AndroidSdk (#835) There is some code which is conceptually, if not literally, duplicated between the xamarin-android and the IDEs (Visual Studio, Visual Studio for Mac), in particular code that deals with finding the Android SDK and Java JDK locations. This code has been split out into a new `xamarin-android-tools` repo to facilitate sharing, without the IDEs needing to submodule xamarin-android, which is quite large. Cleanup the xamarin-android repo to use the new xamarin-android-tools repo for Android SDK information/etc.
2017-09-13 13:08:52 +03:00
{66CF299A-CE95-4131-BCD8-DB66E30C4BF7}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
{66CF299A-CE95-4131-BCD8-DB66E30C4BF7}.Debug|AnyCPU.Build.0 = Debug|Any CPU
{66CF299A-CE95-4131-BCD8-DB66E30C4BF7}.Release|AnyCPU.ActiveCfg = Release|Any CPU
{66CF299A-CE95-4131-BCD8-DB66E30C4BF7}.Release|AnyCPU.Build.0 = Release|Any CPU
Sanitize Xamarin.Android.sln: fix several inconsistency bits. (#1159) Manually editing solution file is uncool and error prone, but since the entire xamarin-android source tree is not designed cleanly it is impossible to use IDEs to do the right job. As stated at https://github.com/xamarin/xamarin-android/issues/1129 , we should eliminate this Xamarin.Android.sln as a source file and it should be only generated, not directly committed to the tree. But to achieve that we first need to find the right structure and right content. So far, there were handful of issues that either missed or incorrectly added solution items with inconsistent configurations. These inconsistent parts were found by the solution content analyzer at https://github.com/xamarin/xamarin-android/issues/1129#issuecomment-355484902
2018-01-09 17:55:30 +03:00
{66CF299A-CE95-4131-BCD8-DB66E30C4BF7}.XAIntegrationDebug|AnyCPU.ActiveCfg = Debug|Any CPU
{66CF299A-CE95-4131-BCD8-DB66E30C4BF7}.XAIntegrationDebug|AnyCPU.Build.0 = Debug|Any CPU
{66CF299A-CE95-4131-BCD8-DB66E30C4BF7}.XAIntegrationRelease|AnyCPU.ActiveCfg = Release|Any CPU
{66CF299A-CE95-4131-BCD8-DB66E30C4BF7}.XAIntegrationRelease|AnyCPU.Build.0 = Release|Any CPU
[Xamarin.Android.Build.Tasks] Use Xamarin.Android.Tools.AndroidSdk (#835) There is some code which is conceptually, if not literally, duplicated between the xamarin-android and the IDEs (Visual Studio, Visual Studio for Mac), in particular code that deals with finding the Android SDK and Java JDK locations. This code has been split out into a new `xamarin-android-tools` repo to facilitate sharing, without the IDEs needing to submodule xamarin-android, which is quite large. Cleanup the xamarin-android repo to use the new xamarin-android-tools repo for Android SDK information/etc.
2017-09-13 13:08:52 +03:00
{B8105878-D423-4159-A3E7-028298281EC6}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
{B8105878-D423-4159-A3E7-028298281EC6}.Debug|AnyCPU.Build.0 = Debug|Any CPU
{B8105878-D423-4159-A3E7-028298281EC6}.Release|AnyCPU.ActiveCfg = Release|Any CPU
{B8105878-D423-4159-A3E7-028298281EC6}.Release|AnyCPU.Build.0 = Release|Any CPU
Sanitize Xamarin.Android.sln: fix several inconsistency bits. (#1159) Manually editing solution file is uncool and error prone, but since the entire xamarin-android source tree is not designed cleanly it is impossible to use IDEs to do the right job. As stated at https://github.com/xamarin/xamarin-android/issues/1129 , we should eliminate this Xamarin.Android.sln as a source file and it should be only generated, not directly committed to the tree. But to achieve that we first need to find the right structure and right content. So far, there were handful of issues that either missed or incorrectly added solution items with inconsistent configurations. These inconsistent parts were found by the solution content analyzer at https://github.com/xamarin/xamarin-android/issues/1129#issuecomment-355484902
2018-01-09 17:55:30 +03:00
{B8105878-D423-4159-A3E7-028298281EC6}.XAIntegrationDebug|AnyCPU.ActiveCfg = Debug|Any CPU
{B8105878-D423-4159-A3E7-028298281EC6}.XAIntegrationDebug|AnyCPU.Build.0 = Debug|Any CPU
{B8105878-D423-4159-A3E7-028298281EC6}.XAIntegrationRelease|AnyCPU.ActiveCfg = Release|Any CPU
{B8105878-D423-4159-A3E7-028298281EC6}.XAIntegrationRelease|AnyCPU.Build.0 = Release|Any CPU
[Xamarin.Android.Build.Tasks] Use Xamarin.Android.Tools.AndroidSdk (#835) There is some code which is conceptually, if not literally, duplicated between the xamarin-android and the IDEs (Visual Studio, Visual Studio for Mac), in particular code that deals with finding the Android SDK and Java JDK locations. This code has been split out into a new `xamarin-android-tools` repo to facilitate sharing, without the IDEs needing to submodule xamarin-android, which is quite large. Cleanup the xamarin-android repo to use the new xamarin-android-tools repo for Android SDK information/etc.
2017-09-13 13:08:52 +03:00
{E34BCFA0-CAA4-412C-AA1C-75DB8D67D157}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
{E34BCFA0-CAA4-412C-AA1C-75DB8D67D157}.Debug|AnyCPU.Build.0 = Debug|Any CPU
{E34BCFA0-CAA4-412C-AA1C-75DB8D67D157}.Release|AnyCPU.ActiveCfg = Release|Any CPU
{E34BCFA0-CAA4-412C-AA1C-75DB8D67D157}.Release|AnyCPU.Build.0 = Release|Any CPU
{E34BCFA0-CAA4-412C-AA1C-75DB8D67D157}.XAIntegrationDebug|AnyCPU.ActiveCfg = Debug|Any CPU
{E34BCFA0-CAA4-412C-AA1C-75DB8D67D157}.XAIntegrationDebug|AnyCPU.Build.0 = Debug|Any CPU
Sanitize Xamarin.Android.sln: fix several inconsistency bits. (#1159) Manually editing solution file is uncool and error prone, but since the entire xamarin-android source tree is not designed cleanly it is impossible to use IDEs to do the right job. As stated at https://github.com/xamarin/xamarin-android/issues/1129 , we should eliminate this Xamarin.Android.sln as a source file and it should be only generated, not directly committed to the tree. But to achieve that we first need to find the right structure and right content. So far, there were handful of issues that either missed or incorrectly added solution items with inconsistent configurations. These inconsistent parts were found by the solution content analyzer at https://github.com/xamarin/xamarin-android/issues/1129#issuecomment-355484902
2018-01-09 17:55:30 +03:00
{E34BCFA0-CAA4-412C-AA1C-75DB8D67D157}.XAIntegrationRelease|AnyCPU.ActiveCfg = Release|Any CPU
{E34BCFA0-CAA4-412C-AA1C-75DB8D67D157}.XAIntegrationRelease|AnyCPU.Build.0 = Release|Any CPU
[Xamarin.Android.Build.Tasks] Use Xamarin.Android.Tools.AndroidSdk (#835) There is some code which is conceptually, if not literally, duplicated between the xamarin-android and the IDEs (Visual Studio, Visual Studio for Mac), in particular code that deals with finding the Android SDK and Java JDK locations. This code has been split out into a new `xamarin-android-tools` repo to facilitate sharing, without the IDEs needing to submodule xamarin-android, which is quite large. Cleanup the xamarin-android repo to use the new xamarin-android-tools repo for Android SDK information/etc.
2017-09-13 13:08:52 +03:00
{1E5501E8-49C1-4659-838D-CC9720C5208F}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
{1E5501E8-49C1-4659-838D-CC9720C5208F}.Debug|AnyCPU.Build.0 = Debug|Any CPU
{1E5501E8-49C1-4659-838D-CC9720C5208F}.Release|AnyCPU.ActiveCfg = Release|Any CPU
{1E5501E8-49C1-4659-838D-CC9720C5208F}.Release|AnyCPU.Build.0 = Release|Any CPU
Sanitize Xamarin.Android.sln: fix several inconsistency bits. (#1159) Manually editing solution file is uncool and error prone, but since the entire xamarin-android source tree is not designed cleanly it is impossible to use IDEs to do the right job. As stated at https://github.com/xamarin/xamarin-android/issues/1129 , we should eliminate this Xamarin.Android.sln as a source file and it should be only generated, not directly committed to the tree. But to achieve that we first need to find the right structure and right content. So far, there were handful of issues that either missed or incorrectly added solution items with inconsistent configurations. These inconsistent parts were found by the solution content analyzer at https://github.com/xamarin/xamarin-android/issues/1129#issuecomment-355484902
2018-01-09 17:55:30 +03:00
{1E5501E8-49C1-4659-838D-CC9720C5208F}.XAIntegrationDebug|AnyCPU.ActiveCfg = Debug|Any CPU
{1E5501E8-49C1-4659-838D-CC9720C5208F}.XAIntegrationDebug|AnyCPU.Build.0 = Debug|Any CPU
{1E5501E8-49C1-4659-838D-CC9720C5208F}.XAIntegrationRelease|AnyCPU.ActiveCfg = Release|Any CPU
{1E5501E8-49C1-4659-838D-CC9720C5208F}.XAIntegrationRelease|AnyCPU.Build.0 = Release|Any CPU
[xabuild.exe] cross-platform form of tools/scripts/xabuild (#910) Context: https://github.com/jonathanpeppers/xabuild What do we want? A *usable*, *parallel*, build tree. To elaborate: we want to be able to have a "system" Xamarin.Android install, and a "parallel" xamarin-android install, and be able to *easily* switch between the two. (For various definitions of "easy"; here, we mean *command-line* use, not IDE use.) On macOS, this (more or less) Just Works™, and is extremely handy for testing bug fixes: $ xbuild /t:Install Project.csproj # Verify that some bug is triggered $ xbuild /t:Uninstall Project.csproj $ tools/scripts/xabuild /t:Install Project.csproj # Verify that some bug is *fixed* There's One Problem™ with this: MSBuild does not make this easy. (Related: commit aa1db830.) Apps may rely on files located within `$(MSBuildExtensionsPath)` or `$(TargetFrameworkRootPath)`, files such as PCL profile assemblies, or 3rd party frameworks. Meanwhile, on macOS, `xabuild` is *predicated* upon overriding `$(TargetFrameworkRootPath)` and `$(MSBuildExtensionsPath)` and `$(XBUILD_FRAMEWORK_FOLDERS_PATH)`, and creating a bunch of symlinks to "fake out" `msbuild.exe` so that system-installed files such as PCL assemblies can be found *through* the parallel environment. It kinda/sorta works on macOS. It completely falls apart when using Windows. There is no easy "symlink half the world" solution there. Overriding `$(MSBuildExtensionsPath)` means that `Microsoft.Common.targets` can't be found. Overriding `$(TargetFrameworkRootPath)` means PCL files can't be found. It's a mess. Fortunately, more recent versions of MSBuild allow for some of these properties to contain *multiple* directories instead of a single directory, which means *there is a way* to support our desired usable parallel install world order. We "just" need to e.g. force `$(MSBuildExtensionsPath)` to contain *both* the in-tree directory *and* the system directory: ```xml <MSBuildExtensionsPath>In-Tree Directory; System Directory</MSBuildExtensionsPath> ``` Unfortunately, *this isn't easy*. Not all of these properties can be overridden on the `msbuild.exe` command line. Worse, MSBuild doesn't allow `;` to be part of a property value, as `;` is a property name [separator char](https://msdn.microsoft.com/en-us/library/ms164311.aspx) msbuild.exe /property:WarningLevel=2;OutDir=bin\Debug The way to force MSBuild to accept multiple paths in a property value is by providing a `.exe.config` file with the appropriate values. ~~ Enter `xabuild.exe` ~~ `xabuild.exe` is a nice wrapper around MSBuild for compiling Xamarin.Android projects using a locally built version of Xamarin.Android on your system. It seems to work on Windows, macOS, and Linux and doesn’t require elevation or modifications to your system. `xabuild.exe` works by doing the following: 1. Reference `MSBuild.exe` or `MSBuild.dll` depending on the platform 2. Creates symbolic links to `.NETPortable` and `.NETFramework` directories inside the Xamarin.Android build output directory 3. Overrides MSBuild's `app.config` file to set various properties, such as `$(MSBuildExtensionsPath)`. 4. Run MSBuild’s `Main()` method ~~ Usage ~~ On macOS, `tools/scripts/xabuild` has been updated to use `xabuild.exe` when `$MSBUILD` is `msbuild: $ MSBUILD=msbuild tools/scripts/xabuild /t:SignAndroidPackage samples/HelloWorld/HelloWorld.csproj When `$MSBUILD` is `xbuild` (the current default), the previous behavior of overriding `$MSBuildExtensionsPath` and `$XBUILD_FRAMEWORK_FOLDERS_PATH` is still used. On Windows, MSBuild 15.3 from Visual Studio 2017 is required. Simply execute `xabuild.exe`: > bin\Debug\bin\xabuild.exe Xamarin.Android-Tests.sln /p:XAIntegratedTests=False Before `xabuild.exe` existed, `setup-windows.exe` would need to be executed (as Administrator!) in order for `Xamarin.Android-Tests.sln` to be built using `msbuild.exe`.
2017-10-14 00:05:13 +03:00
{B7A457E6-9CB6-43F6-BFD6-14D5397FB98D}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
{B7A457E6-9CB6-43F6-BFD6-14D5397FB98D}.Debug|AnyCPU.Build.0 = Debug|Any CPU
{B7A457E6-9CB6-43F6-BFD6-14D5397FB98D}.Release|AnyCPU.ActiveCfg = Release|Any CPU
{B7A457E6-9CB6-43F6-BFD6-14D5397FB98D}.Release|AnyCPU.Build.0 = Release|Any CPU
{B7A457E6-9CB6-43F6-BFD6-14D5397FB98D}.XAIntegrationDebug|AnyCPU.ActiveCfg = Debug|Any CPU
{B7A457E6-9CB6-43F6-BFD6-14D5397FB98D}.XAIntegrationDebug|AnyCPU.Build.0 = Debug|Any CPU
Sanitize Xamarin.Android.sln: fix several inconsistency bits. (#1159) Manually editing solution file is uncool and error prone, but since the entire xamarin-android source tree is not designed cleanly it is impossible to use IDEs to do the right job. As stated at https://github.com/xamarin/xamarin-android/issues/1129 , we should eliminate this Xamarin.Android.sln as a source file and it should be only generated, not directly committed to the tree. But to achieve that we first need to find the right structure and right content. So far, there were handful of issues that either missed or incorrectly added solution items with inconsistent configurations. These inconsistent parts were found by the solution content analyzer at https://github.com/xamarin/xamarin-android/issues/1129#issuecomment-355484902
2018-01-09 17:55:30 +03:00
{B7A457E6-9CB6-43F6-BFD6-14D5397FB98D}.XAIntegrationRelease|AnyCPU.ActiveCfg = Release|Any CPU
{B7A457E6-9CB6-43F6-BFD6-14D5397FB98D}.XAIntegrationRelease|AnyCPU.Build.0 = Release|Any CPU
[Xamarin.Android.Build.Tests] Make log searching more efficient. (#1034) The current implementation of `LastBuildOutput` loads the entire logfile into memory for searching. This causes OutOfMemory problems on windows, especially now that we are running multiple tests at the same time. This commit switches the `LastBuildOutput` over to be an `IEnumerable<string>`. The idea is that we will stream through the buildlog one line at a time to search for the strings we want to check. This might not be as quick, but it should be more efficient.
2017-11-20 19:06:06 +03:00
{53E4ABF0-1085-45F9-B964-DCAE4B819998}.Debug|AnyCPU.ActiveCfg = Debug|Any CPU
{53E4ABF0-1085-45F9-B964-DCAE4B819998}.Debug|AnyCPU.Build.0 = Debug|Any CPU
{53E4ABF0-1085-45F9-B964-DCAE4B819998}.Release|AnyCPU.ActiveCfg = Release|Any CPU
{53E4ABF0-1085-45F9-B964-DCAE4B819998}.Release|AnyCPU.Build.0 = Release|Any CPU
{53E4ABF0-1085-45F9-B964-DCAE4B819998}.XAIntegrationDebug|AnyCPU.ActiveCfg = Debug|Any CPU
{53E4ABF0-1085-45F9-B964-DCAE4B819998}.XAIntegrationDebug|AnyCPU.Build.0 = Debug|Any CPU
Sanitize Xamarin.Android.sln: fix several inconsistency bits. (#1159) Manually editing solution file is uncool and error prone, but since the entire xamarin-android source tree is not designed cleanly it is impossible to use IDEs to do the right job. As stated at https://github.com/xamarin/xamarin-android/issues/1129 , we should eliminate this Xamarin.Android.sln as a source file and it should be only generated, not directly committed to the tree. But to achieve that we first need to find the right structure and right content. So far, there were handful of issues that either missed or incorrectly added solution items with inconsistent configurations. These inconsistent parts were found by the solution content analyzer at https://github.com/xamarin/xamarin-android/issues/1129#issuecomment-355484902
2018-01-09 17:55:30 +03:00
{53E4ABF0-1085-45F9-B964-DCAE4B819998}.XAIntegrationRelease|AnyCPU.ActiveCfg = Release|Any CPU
{53E4ABF0-1085-45F9-B964-DCAE4B819998}.XAIntegrationRelease|AnyCPU.Build.0 = Release|Any CPU
Fix line endings
2016-07-06 18:09:45 +03:00
EndGlobalSection
GlobalSection(NestedProjects) = preSolution
{8FF78EB6-6FC8-46A7-8A15-EBBA9045C5FA} = {E351F97D-EA4F-4E7F-AAA0-8EBB1F2A4A62}
{E8492EFB-D14A-4F32-AA28-88848322ECEA} = {E351F97D-EA4F-4E7F-AAA0-8EBB1F2A4A62}
{C03E6CF1-7460-4CDC-A4AB-292BBC0F61F2} = {E351F97D-EA4F-4E7F-AAA0-8EBB1F2A4A62}
{AFB8F6D1-6EA9-42C3-950B-98F34C669AD2} = {E351F97D-EA4F-4E7F-AAA0-8EBB1F2A4A62}
{3FC3E78B-F7D4-42EA-BBE8-4535DF42BFF8} = {E351F97D-EA4F-4E7F-AAA0-8EBB1F2A4A62}
{94BD81F7-B06F-4295-9636-F8A3B6BDC762} = {04E3E11E-B47D-4599-8AFC-50515A95E715}
{D14A1B5C-2060-4930-92BE-F7190256C735} = {04E3E11E-B47D-4599-8AFC-50515A95E715}
Reorganize Xamarin.Android.NamingCustomAttributes. (#139) context: https://github.com/xamarin/java.interop/issues/58 dependent on: https://github.com/atsushieno/java.interop/commit/5583d26 Copypasting the changes on Java.Interop We have complicated module interdependency between this and xamarin-android, so this set of changes is to fix the situation. So far, here is the changeset summary: - Xamarin.Android.NamingCustomAttributes.shproj is moved to xamarin-android - there will be new Java.Interop.NamingCustomAttributes.shproj which is for use in this repository. It will be shrinked in the later commits to have only required bits in Java/Interop. Now Xamarin.Android.sln has two NamingCustomAttributes.shproj: one for imported and then slightly stripped version of the original shared project in xamarin-android, and renamed and then significantly stripped version in Java.Interop. Build adjustment comes next.
2016-08-08 17:50:37 +03:00
{FE789F04-5E95-42C5-AEF1-E33F8DF06B3F} = {04E3E11E-B47D-4599-8AFC-50515A95E715}
Fix line endings
2016-07-06 18:09:45 +03:00
{74598F5C-B8CC-4CE6-8EE2-AB9CA1400076} = {04E3E11E-B47D-4599-8AFC-50515A95E715}
{D27AD8F7-7710-40BE-B03B-55EFBEC13C44} = {04E3E11E-B47D-4599-8AFC-50515A95E715}
{3F1F2F50-AF1A-4A5A-BEDB-193372F068D7} = {04E3E11E-B47D-4599-8AFC-50515A95E715}
{B17475BC-45A2-47A3-B8FC-62F3A0959EE0} = {04E3E11E-B47D-4599-8AFC-50515A95E715}
{52C7D9B6-E8C8-47D0-9471-652D278D7D77} = {864062D3-A415-4A6F-9324-5820237BA058}
{D18FCF91-8876-48A0-A693-2DC1E7D3D80A} = {864062D3-A415-4A6F-9324-5820237BA058}
{1268EADF-8344-431C-81F6-FCB7CBC99F49} = {864062D3-A415-4A6F-9324-5820237BA058}
{07BC4495-1267-4B78-9EA6-B76FEEA2A64A} = {864062D3-A415-4A6F-9324-5820237BA058}
{64CC4E44-CE3A-4319-BF3F-6CF8BD513870} = {864062D3-A415-4A6F-9324-5820237BA058}
{D48EE8D0-0A0A-4493-AEF5-DAF5F8CF86AD} = {864062D3-A415-4A6F-9324-5820237BA058}
{53EE4C57-1C03-405A-8243-8DA539546C88} = {04E3E11E-B47D-4599-8AFC-50515A95E715}
{4D603AA3-3BFD-43C8-8050-0CD6C2601126} = {04E3E11E-B47D-4599-8AFC-50515A95E715}
{2DD1EE75-6D8D-4653-A800-0A24367F7F38} = {CAB438D8-B0F5-4AF0-BEBD-9E2ADBD7B483}
{2868FC32-A4E7-4008-87C8-2C7879CACB58} = {04E3E11E-B47D-4599-8AFC-50515A95E715}
{2CF172E5-BDAE-4ABA-8BC8-08040ED3E77A} = {E351F97D-EA4F-4E7F-AAA0-8EBB1F2A4A62}
{1A4B041A-842F-40B3-A50D-49E01D30BD18} = {04E3E11E-B47D-4599-8AFC-50515A95E715}
{38C762AB-8FD1-44DE-9855-26AAE7129DC3} = {864062D3-A415-4A6F-9324-5820237BA058}
{7387E151-48E3-4885-B2CA-A74434A34045} = {864062D3-A415-4A6F-9324-5820237BA058}
{26781D3A-FF20-4F55-9824-C8A06AA9E484} = {04E3E11E-B47D-4599-8AFC-50515A95E715}
{B8F799C5-D7CE-4E09-9CE6-BAA4173E7EC8} = {04E3E11E-B47D-4599-8AFC-50515A95E715}
{5EB9E888-E357-417E-9F39-DDEC195CE47F} = {04E3E11E-B47D-4599-8AFC-50515A95E715}
{900A0F71-BAAD-417A-8D1A-8D330297CDD0} = {E351F97D-EA4F-4E7F-AAA0-8EBB1F2A4A62}
{E248B2CA-303B-4645-ADDC-9D4459D550FD} = {04E3E11E-B47D-4599-8AFC-50515A95E715}
[System.Drawing.Primitives] Add System.Drawing.Primitives.dll Facade (#121) Xamarin.Android needs to support [.NET Standard 1.6][0], which mentions a [`System.Drawing.Primitives.dll` assembly][1] which has not previously been supported or shipped. `System.Drawing.Primitives.dll` contains `System.Drawing.Point` and related typees, which Xamarin.Android places into `Mono.Android.dll`. Add a new `System.Drawing.Primitives.dll` assembly to use as a *facade assembly*, which contains [type forwarders][2] to "redirect" the types from `System.Drawing.Primitives.dll` to the corresponding types within `Mono.Android.dll`. [0]: https://docs.microsoft.com/en-us/dotnet/articles/core/tutorials/libraries [1]: https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md#list-of-net-corefx-apis-and-their-associated-net-platform-standard-version [2]: https://msdn.microsoft.com/en-us/library/ms404275(v=vs.110).aspx
2016-07-15 23:42:03 +03:00
{C9FF2E4D-D927-479E-838B-647C16763F64} = {04E3E11E-B47D-4599-8AFC-50515A95E715}
[bundle] Add `CreateBundle` target. (#140) Building Mono on Windows is a PITA, and commit 0c073f67 added support to cross-compile Mono for Windows so that Mono could be built from macOS or Linux. The unstated goal of that work was to -- eventually -- build the Mono runtimes *for Windows* on e.g. macOS, *bundle* those runtimes, and then we could update the build process to *download* a pre-built bundle of mono runtimes so that we can ~sanely build xamarin-android on Windows without building *Mono* on Windows. Part Two of this cunning plan involves creating the bundle of built mono runtimes. This in turn got rather complicated because instead of doing the *simple* thing of invoking **zip**(1), I instead wanted to create and use a `<Zip/>` MSBuild task, as this would allow us to specify in one place -- `mono-runtimes.targets` -- which files should be bundled, instead of bundling e.g. everything in `bin/Debug`, which would grab considerably more than just the mono bits. Adding a `<Zip/>` task in turn involves determining which Zip implementation to use, and what assembly to put it in; the obvious answer is to use `libzip`/`libZipSharp.dll` and place it into `Xamarin.Android.Tools.BootstrapTasks.dll` -- which is how we did it -- but this answer was tricky, due to a circular dependency problem: `libzip.mdproj` depends on `android-runtimes.mdproj` which depends on `Xamarin.Android.Tools.BootstrapTasks.dll`. Consequently, adding `libzip.mdproj` as a dependency to `Xamarin.Android.Tools.BootstrapTasks.dll` *doesn't work*. (Question: Why use libzip? Why not use System.IO.Compression? Answer: Because I'd like to be able to update the `<UnzipDirectoryChildren/>` task to use `libzip` instead of "shelling out" to **zip**(1) *like an animal*.) Step 1 is removing the circular dependency. `libzip.mdproj` depends on `android-runtimes.mdproj` because of MXE: `android-runtimes.mdproj` configures the MXE build environment to generate a Windows `libzip.dll` native library, if needed. The fix: introduce a new `libzip-windows.mdproj` project which performs the MXE-based build. This allows `libzip.mdproj` to no longer depend on `android-runtimes.mdproj`; `libzip-windows.mdproj` does. This also involves "refactoring" `libzip.mdproj` so that the build logic can be shared with `libzip-windows.mdproj`. Additionally, improve `libzip.mdproj` so that the native libraries are also set as a `@(Content)` build action. This allows e.g. `libzip.3.0.dylib` to be properly copied into `bin/BuildDebug`, as that's the `$(OutputPath)` of `Xamarin.Android.Tools.BootstrapTasks.csproj`. Step 2 is adding `libZipSharp.csproj` as a `@(ProjectReference)` to `Xamarin.Android.Tools.BootstrapTasks.csproj`. This requires bumping `Xamarin.Android.Tools.BootstrapTasks.csproj` to target .NET 4.5.1, which allows us to add the new `<Zip/>` task, as well as a new `<GitCommit/>` task (so we can determine the abbreviated commit hash of the mono checkout, for encoding into the filename). Step 3 is updating `mono-runtimes.targets` so that the Windows cross-compilers are built into `bin/$(Configuration)/lib/mandroid`, as this matches what is currently done internally. Step 4 is adding a new `build-tools/bundle.mdproj` project with a `CreateBundle` targtet, which will create the file: $(OutputPath)\bundle-$(Configuration)-libzip=$(libzip-hash),llvm=$(llvm-hash),mono=$(mono-hash).zip`. Uploading the `bundle-*.zip` files will be handled by Jenkins as a post-build task. Not yet done: *using* `bundle-*.zip` so that mono/etc. builds can be skipped, *greatly* improving build times.
2016-08-11 00:28:53 +03:00
{0DE278D6-000F-4001-BB98-187C0AF58A61} = {E351F97D-EA4F-4E7F-AAA0-8EBB1F2A4A62}
{1640725C-4DB8-4D8D-BC96-74E688A06EEF} = {E351F97D-EA4F-4E7F-AAA0-8EBB1F2A4A62}
[xa-prep-tasks] Use the Mono bundle (#162) Context: https://github.com/xamarin/xamarin-android/commit/fbfd676c102c63e4e06e750857b178725e33450c Stage 3 of the cunning plan is to (attempt to) use the mono bundle introduced in commit fbfd676c. This "simple" desire (ha!) re-raises the architectural project dependency issue "solved" in fbfd676c, but first, a simple question: What should download the mono bundle? There are two plausible answers: 1. `make prepare` can (somehow) handle it. 2. MSBuild can (somehow) handle it. Both are plausible. The problem with using `make` targets (1) is there is increased potential for "duplication" -- duplication of the bundle filename, downloading it, and extracting it. Plus, `make` isn't "Windows friendly", in that GNU make isn't (normally) present with Visual Studio. (`NMAKE` is, but the Makefiles in this project are not compatible with `NMAKE`.) Which brings us to MSBuild (2): can it handle the task? To tackle that, we need to be able to have an MSBuild task project which has *no dependencies*, so that it can download and extract the mono bundle *before anything else runs*, as it may be downloading contents which mean that other projects don't *need* to run. The need for a "pre-bootstrap" task assembly -- called `xa-prep-tasks` -- thus "undoes" *some* of the logic regarding `libzip-windows.mdproj` and the `<Zip/>` task from fbfd676c: it isn't *possible* to rely on `libzip` from a "pre-build" state, as `libzip` is one of the things in the mono bundle, so now we need *two* "bootstrap" task assemblies: one without a `libzip` dependency -- `xa-prep-tasks.dll` -- and one *with* a `libzip` dependency -- `Xamarin.Android.Tools.BootstrapTasks.dll` Move tasks which don't currently require `libzip` -- or won't in the future, or laziness -- from `Xamarin.Android.Tools.BootstrapTasks.dll` and move them into `xa-prep-tasks.dll`. With that architectural compromise in place, add `xa-prep-tasks` as a `@(ProjectReference)` to various projects to help ensure it's built *first*, and rearchitect `bundle.mdproj` so that `xa-prep-tasks.targets` and `bundle.targets` can use the same targets to compute the bundle filename, now in `build-tools/bundle/bundle-path.targets`. Add a post-build step to `xa-prep-tasks.csproj` which downloads and extracts the expected mono bundle. One "problem" (feature?) is that the new `<SystemUnzip/>` task doesn't report errors as errors when unzip'ing the file. This turns out to be fine here because when downloading the mono bundle from Azure we don't get a 404 *anyway* -- Azure instead returns an XML document containing an error message (wat?!). We can thus ignore most error handling entirely...though we're *also* ignoring any checking for invalid downloads, which is something we should address in the future. Update the varioous project files so that they won't attempt to rebuild binaries that were present in the mono bundle.
2016-08-16 23:02:48 +03:00
{7CE69551-BD73-4726-ACAA-AAF89C84BAF8} = {E351F97D-EA4F-4E7F-AAA0-8EBB1F2A4A62}
Bump to Java.Interop/f44a11f6 and use its Cecil library (#303) Updated all the projects to use the `Xamarin.Android.Cecil` library instead of `Mono.Cecil` nuget package.
2016-11-18 18:04:49 +03:00
{15945D4B-FF56-4BCC-B598-2718D199DD08} = {864062D3-A415-4A6F-9324-5820237BA058}
{C0487169-8F81-497F-919E-EB42B1D0243F} = {864062D3-A415-4A6F-9324-5820237BA058}
[remap-assembly-ref] Properly add to the XA solution (#351) - the platform was set to x86 only - the project was defined, but not added to the solution tree
2017-01-05 21:20:50 +03:00
{C876DA71-8573-4CEF-9149-716D72455ED4} = {E351F97D-EA4F-4E7F-AAA0-8EBB1F2A4A62}
[build] Auto-Provision Dependencies (#447) The #runtime team is requesting that Xamarin.Android support "auto-provisioning": the ability to track dependency *versions*, and if there is a "version mismatch", *install* a dependency that satisfies the minimum. The primary use case is Mono itself: there is a desire to build xamarin-android *itself* against mono/master, to see what breaks. (Does the C# compiler break things? Does the JIT hang? etc.) Extend the existing `@(RequiredProgram)` infrastructure to attempt to support this: * `%(RequiredProgram.MinimumVersion)`: The minimum program version that is supported. * `%(RequiredProgram.MaximumVersion)`: The maximum program version that is supported. * `%(RequiredProgram.CurrentVersionCommand)`: A command to execute to obtain the current program version. Defaults to `%(RequiredProgram.Identity) --version`. * `%(RequiredProgram.MinimumUrl)`: URL to download "something" to use to obtain a version of the program that satisfies `%(MinimumVersion)`. * `%(RequiredProgram.Install)`: Command to execute which installs the minimum version of the program. `%(RequiredProgram.CurrentVersionCommand)`, `%(RequiredProgram.MinimumUrl)`, and `%(RequiredProgram.Install)` can all be "overridden" for platform-specific values by prefixing the value with `$(HostOSName)` and/or `$(HostOS)`. Thus, macOS-specific values can be stored into e.g. `%(RequiredProgram.DarwinMinimumUrl)` and `%(RequiredProgram.DarwinInstall)`. Auto-Provisioning is controlled by the new `$(AutoProvision)` property, which can be provided in `Configuration.Override.props`. It defaults to `False`. If the `$(AutoProvisionUsesSudo)` MSBuild property is True, then `sudo` is used to invoke all install commands.
2017-02-16 19:37:28 +03:00
{C845ECC0-2ED3-498E-8EA8-02EF7AC6E9AD} = {E351F97D-EA4F-4E7F-AAA0-8EBB1F2A4A62}
[Xamarin.Android.Build.Tasks] Use GPL'd ProGuard (#386) **Background**: many Android SDK features rely on [ProGuard][0], a Java bytecode manipulation library. Some of these features include linking (shrinking) bytecode and [multidex][1]. Xamarin.Android has historically relied on the version of ProGuard bundled with the Android SDK, which is how the `<Proguard/>` task and `@(ProguardConfiguration)` build actions work. Unfortunately, the version of ProGuard bundled with the Android SDK is, at this point, *ancient* (ProGuard v4.7; current version is v5.3), and (more importantly) ProGuard v4.7 doesn't support JDK 1.8 bytecode. Meaning if the end-developer references a Java library targeting JDK 1.8 -- e.g. the Android Support Library v25 -- then the version of ProGuard bundled with the Android SDK *cannot process that library*. This in turn means that the `<Proguard/>` task and `@(ProguardConfiguration)` build actions don't work/are useless. Native Java development "works around" this problem by using Gradle as the build system, and Java projects are configured to download and install a newer version of ProGuard via Gradle. Xamarin.Android projects do not use Gradle, nor will they. (At least not in the foreseeable future.) **Solution**: We have communicated with Eric Lafortune, maintainer of ProGuard, about distributing a newer ProGuard with Xamarin.Android. He replied: > From a licensing point of view, you shouldn't need an exception to > the GPL in many practical configurations: > > * if you indeed run ProGuard in a separate JVM The `<Proguard/>` task is a [`ToolTask`][2], which operates by creating a new process to invoke the specified tool. We thus are *already* using ProGuard within a "separate JVM", and no architectural change is required to comply with ProGuard's licensing without altering Xamarin.Android's licensing. The current ProGuard sources (v5.3.2) have been imported into the [xamarin/proguard][3] module, and we will be using the `xamarin/proguard` module as a git submodule for build purposes. [0]: https://www.guardsquare.com/en/proguard [1]: https://developer.android.com/studio/build/multidex.html [2]: https://msdn.microsoft.com/en-us/library/microsoft.build.utilities.tooltask.aspx [3]: http://github.com/xamarin/proguard/
2017-03-06 18:00:36 +03:00
{4B9D96BB-95AB-44E8-9F87-13B12C8BCED1} = {04E3E11E-B47D-4599-8AFC-50515A95E715}
[api-xml-adjuster] move from tools to build-tools (#485) It is build-time tool and should not be used in any production environment.
2017-03-15 16:46:20 +03:00
{8A6CB07C-E493-4A4F-AB94-038645A27118} = {E351F97D-EA4F-4E7F-AAA0-8EBB1F2A4A62}
[javadoc2mdoc] import javadoc-to-mdoc from monodroid/fbb0c9d (#500) ... with some changes: - It turned out that we don't have Ionic.Zip, so it is replaced with LibZipSharp (with new entry removal methods thanks to grendel). - We don't import README.samples that indicates some internals. javadoc-to-mdoc is a tool that converts Javadocs or DroidDocs into monodoc format. Then it can be converted to C# docs (csc /doc) or HTML using "mdoc" tool in mono (we also build and ship it within `lib/mandroid`).
2017-03-17 21:18:55 +03:00
{E0890301-F75F-40E7-B008-54C28B3BA542} = {864062D3-A415-4A6F-9324-5820237BA058}
{A87352E6-CE7F-4346-B6B1-586AE931C0A7} = {864062D3-A415-4A6F-9324-5820237BA058}
[Xamarin.Android.Build.Tests] Move tests into a Shared Project so they can be reused upstream. (#506) Rather than have all the msbuild tests in an assembly this commit moves them into a shared project. This means the source code for the tests can be easily reused upstream. It also means we can make use of things like partial classes to change the tests depending on which repo we are running them from. For example having tests in this repo only run in Release mode but have both Release and Debug upstream.
2017-03-20 19:05:23 +03:00
{BD1D66BF-5AC7-4926-8EBE-B2198A112EB0} = {CAB438D8-B0F5-4AF0-BEBD-9E2ADBD7B483}
[create-vsix] Create `.vsix` files (#541) Visual Studio 2017 uses `.vsix` files for Xamarin.Android SDK support. A `.vsix` file is [ZIP container with additional metadata][0], and the [Microsoft.VSSDK.BuildTools NuGet package][1] contains various MSBuild targets and tools to assist in creating `.vsix` files. Add a new `build-tools/create-vsix/create-vsix.csproj` project to create the `bin/Build$(Configuration)/Xamarin.Android.Sdk*.vsix` file, so that we can plausibly provide per-build OSS Xamarin.Android releases that work with Visual Studio 2017. Unfortunately those tools were written on Windows, and not really well tested on macOS or Linux... In particular, there are case-sensitivity and directory-separator-char issues with the tooling, necessitating that `MONO_IOMAP=all` be exported in order to run them: MONO_IOMAP=all MONO_OPTIONS=--arch=64 msbuild \ build-tools/create-vsix/create-vsix.csproj /p:CreateVsixContainer=True Meanwhile, we're still attempting to allow things to be built with `xbuild` [^3]. Thread this needle by "special-casing" the `$(BuildDependsOn)`, `$(CopyVsixManifestFileDependsOn)`, and `$(DetokenizeVsixManifestFileDependsOn)` MSBuild properties so that when the `$(CreateVsixContainer)` MSBuild property is False -- the default -- no `.vsix` package will be created, and `xbuild` will be able to build the project. Similar needle threading is needed to "support" building on Linux: the Microsoft.VSSDK.BuildTools NuGet package uses case in an inconsistent fashion -- or is it `nuget`? -- which results in [failures when building on Linux][2] because `nuget` extracts e.g.: packages/Microsoft.VSSDK.BuildTools.15.0.26201/tools/vssdk/Microsoft.VsSDK.targets while Microsoft.VSSDK.BuildTools attempts to `<Import/>` the file: packages/Microsoft.VSSDK.BuildTools.15.0.26201/tools/VSSDK/Microsoft.VsSDK.targets `vssdk` != `VSSDK` on case-sensitive filesystems, so this results in an error on Ubuntu (and presumably case-senstive macOS as well). Handle the Linux case by extending the `xbuild` case: *even when* `$(CreateVsixContainer)` is True, we won't actually build the `.vsix` unless the `$(VsSDKInstall)` directory exists, which is the `tools/VSSDK` path. Building with `$(CreateVsixContainer)` set to True will require using `msbuild` with `MONO_IOMAP=all` and `MONO_OPPTIONS=--arch=64` exported, while using a case-insensitive filesystem. The new `make create-vsix CONFIGURATIONS=Debug` target can be used to explicitly create the `Xamarin.Android.Sdk*.vsix` file. One problem with creating `.vsix` files: macOS still defaults to using a 32-bit process for `mono`, and `make create-vsix` regularly fails for me with an `OutOfMemoryException` when attempting to generate a `.vsix` file ~600-700+MB in size. (Why so large? In part because for Debug configuration we're including un-`strip`'d native libraries; `libmonosgen-2.0.dll` is *237MB* in size (!); it's closer to 5MB when `strip`'d, but any un-`strip`'d MXE-generated native libraries to the `.vsix` file quickly results in `OutOfMemoryException`s.) A 64-bit mono can be used by using `mono64` -- which isn't easily done with `msbuild` -- or by using `mono --arch=64`, which *can* be done with `msbuild` by exporting `MONO_OPTIONS=--arch=64`. The `make create-vsix` target does this. Finally, once we have a `.visx` being created, we then examine the *contents* of the `.vsix` file, which is...weird: $MSBuild/Xamarin/Android/Xamarin.Android.CSharp.targets # Desirable $ReferenceAssemblies/Microsoft/Framework/MonoAndroid/v1.0/Xamarin.Android.CSharp.targets # wat? $ReferenceAssemblies/Microsoft/Framework/MonoAndroid/v1.0/Facades/Xamarin.Android.CSharp.targets # really?! $ReferenceAssemblies/Microsoft/Framework/MonoAndroid/v7.1/Xamarin.Android.CSharp.targets # !!!! Turns Out™, the problem was due to `@(ProjectReference)`. We're (ab)using `@(ProjectReference)` to explicitly specify project dependencies, and the (implicit) project build order. Unexpectedly (forgetten?), MSBuild *also* copies the *outputs* of `@(ProjectReference)`s into the `$(OutputPath)` of the current project. Since e.g. `Mono.Posix.csproj` had a reference on `Xamarin.Android.Build.Tasks.csproj`, the result of this is that the `$(OutputPath)` of `Mono.Posix.csproj` -- `$prefix/lib/xbuild-frameworks/MonoAndroid/v1.0` -- also contained the `%(None.CopyToOutputDirectory)` items from `Xamarin.Android.Build.Tasks.csproj`. Oops. The fix is to set `%(ProjectReference.Private)` to False, which disables this copying of additional and undesirable files. [0]: https://msdn.microsoft.com/en-us/library/dd997148.aspx [1]: https://www.nuget.org/packages/Microsoft.VSSDK.BuildTools/ [2]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-anroid-linux-pr-builder/297/consoleText [^3]: But for how much longer?
2017-04-05 18:49:37 +03:00
{94756FEB-1F64-411D-A18E-81B5158F776A} = {E351F97D-EA4F-4E7F-AAA0-8EBB1F2A4A62}
Build netstandard.dll and System.Drawing.Primitives.dll facades (#572) Build `netstandard.dll` and `System.Drawing.Primitives.dll` facades The old project for `System.Drawing.Primitives` was removed in favor of building the assembly with the existing logic in Mono. Also add them to the bundle since we can't rebuild them if we just have the bundle. Update facades list in `MobileProfile.cs`; `netstandard.dll` and `System.ValueTuple.dll` were missing.
2017-04-21 23:06:08 +03:00
{93614CB8-4564-43B9-93B0-4AF4B3B16AAE} = {04E3E11E-B47D-4599-8AFC-50515A95E715}
[setup-windows] Provide a Windows installer (#708) I really didn't want to do this. I wanted the Xamarin.Android SDK on Windows to be usable side-by-side, so that multiple `oss-xamarin.android*.zip` files could be extracted, and developers could switch between them by overriding MSBuild properties. This is what was documented in commit 87ca2737, by overriding the `$(TargetFrameworkRootPath)` MSBuild property. There's just one "minor" problem with that approach: it only works if the project that is being built, and *all* project dependencies, are Xamarin.Android projects. If *any* other kind of dependency is brought in, this approach will no longer work, as the `GetReferenceAssemblies` target -- which looks for assemblies *rooted within `$(TargetFrameworkRootPath)`* -- won't be able to find them. Unfortunately, *everything of interest* doesn't fit within this restriction. A Xamarin.Forms app, or any other app using PCL assemblies, quickly runs afoul of it: error MSB3644: The reference assemblies for framework ".NETPortable,Version=v4.5,Profile=Profile259" were not found. Consequently, the instructions from commit 87ca2737 are borderline worthless. There is only one way to actually build such projects, and that's to install Xamarin.Android *system-wide*, so that MSBuild's `GetReferenceAssemblies` target can find everything it needs. :-( Thus, we need an "installer." I was hoping for a simple `.cmd` file, but that stymied me. Then I hoped for a PowerShell script, but installation requires access to the `%VSINSTALLDIR%` environment variable, which is only exported from Visual Studio Developer Command Prompts, and all the solutions I found to import the VS command prompt environment info into PowerShell looked decidedly ugly. Which brings us to a minimal effort command-line installer: `setup-windows.exe`. This utility backs up existing installs, then creates symbolic links within the system-wide directories, pointing them into the extracted `oss-xamarin.android*.zip` contents which contains `setup-windows.exe`. `setup-windows.exe /uninstall` is also provided, to put directories back the way they were found. `Documentation/UsingJenkinsBuildArtifacts.md` has been updated accordingly.
2017-07-31 13:51:51 +03:00
{73DF9E10-E933-4222-B8E1-F4536FFF9FAD} = {864062D3-A415-4A6F-9324-5820237BA058}
[Xamarin.Android.Build.Tasks] Use Xamarin.Android.Tools.AndroidSdk (#835) There is some code which is conceptually, if not literally, duplicated between the xamarin-android and the IDEs (Visual Studio, Visual Studio for Mac), in particular code that deals with finding the Android SDK and Java JDK locations. This code has been split out into a new `xamarin-android-tools` repo to facilitate sharing, without the IDEs needing to submodule xamarin-android, which is quite large. Cleanup the xamarin-android repo to use the new xamarin-android-tools repo for Android SDK information/etc.
2017-09-13 13:08:52 +03:00
{66CF299A-CE95-4131-BCD8-DB66E30C4BF7} = {04E3E11E-B47D-4599-8AFC-50515A95E715}
{B8105878-D423-4159-A3E7-028298281EC6} = {04E3E11E-B47D-4599-8AFC-50515A95E715}
{E34BCFA0-CAA4-412C-AA1C-75DB8D67D157} = {04E3E11E-B47D-4599-8AFC-50515A95E715}
{1E5501E8-49C1-4659-838D-CC9720C5208F} = {CAB438D8-B0F5-4AF0-BEBD-9E2ADBD7B483}
[xabuild.exe] cross-platform form of tools/scripts/xabuild (#910) Context: https://github.com/jonathanpeppers/xabuild What do we want? A *usable*, *parallel*, build tree. To elaborate: we want to be able to have a "system" Xamarin.Android install, and a "parallel" xamarin-android install, and be able to *easily* switch between the two. (For various definitions of "easy"; here, we mean *command-line* use, not IDE use.) On macOS, this (more or less) Just Works™, and is extremely handy for testing bug fixes: $ xbuild /t:Install Project.csproj # Verify that some bug is triggered $ xbuild /t:Uninstall Project.csproj $ tools/scripts/xabuild /t:Install Project.csproj # Verify that some bug is *fixed* There's One Problem™ with this: MSBuild does not make this easy. (Related: commit aa1db830.) Apps may rely on files located within `$(MSBuildExtensionsPath)` or `$(TargetFrameworkRootPath)`, files such as PCL profile assemblies, or 3rd party frameworks. Meanwhile, on macOS, `xabuild` is *predicated* upon overriding `$(TargetFrameworkRootPath)` and `$(MSBuildExtensionsPath)` and `$(XBUILD_FRAMEWORK_FOLDERS_PATH)`, and creating a bunch of symlinks to "fake out" `msbuild.exe` so that system-installed files such as PCL assemblies can be found *through* the parallel environment. It kinda/sorta works on macOS. It completely falls apart when using Windows. There is no easy "symlink half the world" solution there. Overriding `$(MSBuildExtensionsPath)` means that `Microsoft.Common.targets` can't be found. Overriding `$(TargetFrameworkRootPath)` means PCL files can't be found. It's a mess. Fortunately, more recent versions of MSBuild allow for some of these properties to contain *multiple* directories instead of a single directory, which means *there is a way* to support our desired usable parallel install world order. We "just" need to e.g. force `$(MSBuildExtensionsPath)` to contain *both* the in-tree directory *and* the system directory: ```xml <MSBuildExtensionsPath>In-Tree Directory; System Directory</MSBuildExtensionsPath> ``` Unfortunately, *this isn't easy*. Not all of these properties can be overridden on the `msbuild.exe` command line. Worse, MSBuild doesn't allow `;` to be part of a property value, as `;` is a property name [separator char](https://msdn.microsoft.com/en-us/library/ms164311.aspx) msbuild.exe /property:WarningLevel=2;OutDir=bin\Debug The way to force MSBuild to accept multiple paths in a property value is by providing a `.exe.config` file with the appropriate values. ~~ Enter `xabuild.exe` ~~ `xabuild.exe` is a nice wrapper around MSBuild for compiling Xamarin.Android projects using a locally built version of Xamarin.Android on your system. It seems to work on Windows, macOS, and Linux and doesn’t require elevation or modifications to your system. `xabuild.exe` works by doing the following: 1. Reference `MSBuild.exe` or `MSBuild.dll` depending on the platform 2. Creates symbolic links to `.NETPortable` and `.NETFramework` directories inside the Xamarin.Android build output directory 3. Overrides MSBuild's `app.config` file to set various properties, such as `$(MSBuildExtensionsPath)`. 4. Run MSBuild’s `Main()` method ~~ Usage ~~ On macOS, `tools/scripts/xabuild` has been updated to use `xabuild.exe` when `$MSBUILD` is `msbuild: $ MSBUILD=msbuild tools/scripts/xabuild /t:SignAndroidPackage samples/HelloWorld/HelloWorld.csproj When `$MSBUILD` is `xbuild` (the current default), the previous behavior of overriding `$MSBuildExtensionsPath` and `$XBUILD_FRAMEWORK_FOLDERS_PATH` is still used. On Windows, MSBuild 15.3 from Visual Studio 2017 is required. Simply execute `xabuild.exe`: > bin\Debug\bin\xabuild.exe Xamarin.Android-Tests.sln /p:XAIntegratedTests=False Before `xabuild.exe` existed, `setup-windows.exe` would need to be executed (as Administrator!) in order for `Xamarin.Android-Tests.sln` to be built using `msbuild.exe`.
2017-10-14 00:05:13 +03:00
{B7A457E6-9CB6-43F6-BFD6-14D5397FB98D} = {864062D3-A415-4A6F-9324-5820237BA058}
[Xamarin.Android.Build.Tests] Make log searching more efficient. (#1034) The current implementation of `LastBuildOutput` loads the entire logfile into memory for searching. This causes OutOfMemory problems on windows, especially now that we are running multiple tests at the same time. This commit switches the `LastBuildOutput` over to be an `IEnumerable<string>`. The idea is that we will stream through the buildlog one line at a time to search for the strings we want to check. This might not be as quick, but it should be more efficient.
2017-11-20 19:06:06 +03:00
{53E4ABF0-1085-45F9-B964-DCAE4B819998} = {CAB438D8-B0F5-4AF0-BEBD-9E2ADBD7B483}
Fix line endings
2016-07-06 18:09:45 +03:00
EndGlobalSection
GlobalSection(MonoDevelopProperties) = preSolution
Policies = $0
$0.DotNetNamingPolicy = $1
EndGlobalSection
EndGlobal