search

mono / monodevelop

MonoDevelop is a cross platform .NET IDE
http://www.monodevelop.com
2.84k stars 1.02k forks source link

VS for Mac Xamarin.Android Archive for Publishing Broken Without Building First #5192

Open jonathanpeppers opened 6 years ago

jonathanpeppers commented 6 years ago

From @adamzucchi on June 11, 2018 2:35

Steps to Reproduce

  1. Create a new Xamarin.Forms solution that has an Android project.
  2. Right click the Android project and choose "Archive for Publishing."
  3. Almost immediately a "Package creation failed" error occurs.
  4. Workaround: For whatever reason I then attempted building the Android project under the release configuration first, then chose "Archive for Publishing" and then the archive works.

Expected Behavior

The Android project should create a published archive of the project (.apk)

Actual Behavior

Package creation fails.

However, as noted above if you first build the Android project under the release configuration and then choose to "Archive for Publishing" the archive works as expected.

Version Information

=== Visual Studio Community 2017 for Mac ===

Version 7.5.2 (build 40) Installation UUID: d308199c-14c5-4fad-bbae-24606d319b97 Runtime: Mono 5.10.1.57 (2017-12/ea8a24b1bbf) (64-bit) GTK+ 2.24.23 (Raleigh theme) Xamarin.Mac 4.4.1.178 (master / eeaeb7e6)

Package version: 510010057

=== NuGet ===

Version: 4.3.1.4445

=== .NET Core ===

Runtime: /usr/local/share/dotnet/dotnet Runtime Versions: 2.0.5 2.0.0 SDK: /usr/local/share/dotnet/sdk/2.1.4/Sdks SDK Versions: 2.1.4 2.0.0 MSBuild SDKs: /Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/msbuild/15.0/bin/Sdks

=== Xamarin.Profiler ===

Version: 1.6.2 Location: /Applications/Xamarin Profiler.app/Contents/MacOS/Xamarin Profiler

=== Apple Developer Tools ===

Xcode 9.4 (14160) Build 9F1027a

=== Xamarin.Mac ===

Version: 4.4.1.193 (Visual Studio Community)

=== Xamarin.iOS ===

Version: 11.12.0.4 (Visual Studio Community) Hash: 64fece5f Branch: d15-7 Build date: 2018-05-29 20:00:44-0400

=== Xamarin.Android ===

Version: 8.3.3.2 (Visual Studio Community) Android SDK: /Users/azcreatescode/Library/Developer/Xamarin/android-sdk-macosx Supported Android versions: 4.0.3 (API level 15) 4.1 (API level 16) 4.2 (API level 17) 4.3 (API level 18) 4.4 (API level 19) 4.4.87 (API level 20) 5.0 (API level 21) 5.1 (API level 22) 6.0 (API level 23) 7.0 (API level 24) 7.1 (API level 25) 8.0 (API level 26) 8.1 (API level 27)

SDK Tools Version: 26.1.1 SDK Platform Tools Version: 27.0.1 SDK Build Tools Version: 26.0.3

Java SDK: /usr java version "1.8.0_131" Java(TM) SE Runtime Environment (build 1.8.0_131-b11) Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)

Android Designer EPL code available here: https://github.com/xamarin/AndroidDesigner.EPL

=== Xamarin Inspector ===

Version: 1.4.0 Hash: b3f92f9 Branch: master Build date: Fri, 19 Jan 2018 22:00:34 GMT Client compatibility: 1

=== Build Information ===

Release ID: 705020040 Git revision: cfe2fc0566bc4db990242959de40505a13f58352 Build date: 2018-05-30 11:24:18-04 Xamarin addins: 3ac7413ef51a88e06367313c27aec8f7292752a6 Build lane: monodevelop-lion-d15-7

=== Operating System ===

Mac OS X 10.13.5 Darwin 17.6.0 Darwin Kernel Version 17.6.0 Tue May 8 15:22:16 PDT 2018 root:xnu-4570.61.1~1/RELEASE_X86_64 x86_64

=== Enabled user installed addins ===

LiveXAML 1.3.31 MvvmCross Template pack 2.0.1 Prism QuickStart TemplatePack 1.5.0 Redth's Addins 1.0.9 Internet of Things (IoT) development (Preview) 7.5

Screenshare Link

Screenshare Steps: Android Archive Bug

Copied from original issue: xamarin/xamarin-android#1805

VS bug #638582

jonathanpeppers commented 6 years ago

From @pierceboggan on June 22, 2018 1:28

@kzu Do we know if this reproduces on Windows as well. I'm not sure to what extent this code is shared amongst IDEs.

jonathanpeppers commented 6 years ago

When I click "Archive" in VS for Windows it triggers a build before archiving, so it seems to work properly there.

adamzucchi commented 6 years ago

@jonathanpeppers & @pierceboggan - Sorry, did I put this issue in the wrong spot?

sgmunn commented 6 years ago

@slluis the issue is related to a fix we did where VSM would do an explicit build prior to archiving. this caused another issue with AfterBuild targets which would be called twice because the targets we have to call to create the .apk would also do an implicit build.

The reason this fails is that it appears that BuildingInsideVisualStudio is set to true when we call the targets to create the .apk, which results in the packaging target not building dependent projects - which is the issue here (the common forms project is not built).

Would setting BuildingInsideVisualStudio to false when we call the package target work?

Thoughts?

slluis commented 6 years ago

@sgmunn Maybe we can add a buildDependencies argument to Project.RunTarget(). Although I'm wondering, does the packaging target does no build dependencies, but does it build the project itself?

sgmunn commented 6 years ago

@slluis the packaging target does build dependent projects but not if BuildingInsideVisualStudio is true. Why? not sure perhaps @dellis1972 or @jonathanpeppers can answer that directly. If the target is run on the cmdline, the dependent project is built.

jonathanpeppers commented 6 years ago

From what I understand, this is an MSBuild thing... maybe @dellis1972 can chime in?

On Windows at least, BuildingInsideVisualStudio tells MSBuild that VS is handling building dependencies. You can see the same thing happen with non-Xamarin.Android projects.

sgmunn commented 6 years ago

VS is handling building dependencies

ok, so that kind of makes sense. What would be the impact of the android add in simply disabling that property when we build the .apk for archiving - @slluis ?

slluis commented 6 years ago

The problem is that configuration mappings are done at solution level, so if you rely on a project to build its dependencies, it may build the wrong configurations.

KirillOsenkov commented 6 years ago

You can consider specifying the CurrentSolutionConfigurationContents which is an XML blob essentially containing the contents of the .sln in XML format. When you build an .sln via MSBuild, you can set the environment variable MSBUILDEMITSOLUTION = 1, which will persist the generated .sln.metaproj to disk, and you can see exactly how MSBuild builds a solution. If you mimic what that does, you can ensure that GetTargetPath on P2P references returns the correct result based on current configuration and platform.