Bug 32845 - [XVS 3.11.586] Adding a new template AXML layout to the resources folder hangs Visual Studio GUI thread in `JavaProcessConnection.PostMessage()` unless Android Designer is already started
Summary: [XVS 3.11.586] Adding a new template AXML layout to the resources folder hang...
Alias: None
Product: Visual Studio Extensions
Classification: Xamarin
Component: Android Designer ()
Version: 3.11 (C5)
Hardware: PC Windows
: Highest major
Target Milestone: 4.0.0 (C6)
Assignee: Bugzilla
Depends on:
Blocks: 31667
  Show dependency tree
Reported: 2015-08-06 20:24 UTC by Brendan Zagaeski (Xamarin Team, assistant)
Modified: 2015-10-01 08:34 UTC (History)
7 users (show)

Tags: BZRC5SR1S1_C5S3
Is this bug a regression?: ---
Last known good build:

Complete call stack of the Main Thread (4.13 KB, text/plain)
2015-08-06 20:24 UTC, Brendan Zagaeski (Xamarin Team, assistant)

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Brendan Zagaeski (Xamarin Team, assistant) 2015-08-06 20:24:22 UTC
Created attachment 12399 [details]
Complete call stack of the Main Thread

Adding a new template AXML layout to the resources folder hangs Visual Studio GUI thread in `JavaProcessConnection.PostMessage()`

The symptoms of this bug are very similar to Bug 31519, but the steps to reproduce are slightly different, the Android SDK version is _not_ mismatched with the Xamarin version in this bug, and this bug is _not_ yet fixed on master (whereas my tests showed that Bug 31519 _is_ fixed on master).

Opening _existing_ layouts works fine.

The problem does not seem to happen (at least not as easily) on Xamarin Studio on Windows.

## Regression status: appears to be a regression that corresponds with the update for Android SDK Tools 24.3 compatibility (Bug 30556)

### BAD 
Android SDK Tools 24.3.3
Xamarin  5.1.323.0  (7984c9e)

### BAD
Android SDK Tools 24.3.3
Xamarin  3.11.816.0 (cefca47)

### BAD
Android SDK Tools 24.3.3 (also tested with Android SDK Tools 24.3)
Xamarin   3.11.586.0 (a91e30d)

### GOOD
Android SDK Tools 24.2
Xamarin  3.11.458.0 (7acdedd)

## Steps to reproduce

1. Create a new "Visual C# -> Android -> Blank App (Android)".

2. Expand the folder structure in the Solution Explorer to reveal the "Resources\layout" folder.

3. Right click the "layout" folder, and select "Add -> New Item".

4. Pick "Android Layout" for the new item, and click "Add" in the dialog window.

## Results

Visual Studio freezes. Attaching a second instance of VS, pausing, and looking at the Main Thread shows a call stack that appears to be identical to the call stack from Bug 31519.

### Top of the call stack

> WindowsBase.dll!System.Windows.Threading.DispatcherSynchronizationContext.Wait(System.IntPtr[] waitHandles, bool waitAll, int millisecondsTimeout)
> mscorlib.dll!System.Threading.SynchronizationContext.InvokeWaitMethodHelper(System.Threading.SynchronizationContext syncContext, System.IntPtr[] waitHandles, bool waitAll, int millisecondsTimeout)
> [Native to Managed Transition]	
> mscorlib.dll!System.Threading.WaitHandle.InternalWaitOne(System.Runtime.InteropServices.SafeHandle waitableSafeHandle, long millisecondsTimeout, bool hasThreadAffinity, bool exitContext)
> mscorlib.dll!System.Threading.WaitHandle.WaitOne(int millisecondsTimeout, bool exitContext)
> mscorlib.dll!System.Threading.WaitHandle.WaitOne()
> Xamarin.AndroidDesigner.dll!Xamarin.AndroidDesigner.JavaProcessConnection.PostMessage(Xamarin.AndroidDesigner.BinaryMessage message = {Xamarin.AndroidDesigner.BinaryMessage}, bool checkInitialized)
> Xamarin.AndroidDesigner.dll!Xamarin.AndroidDesigner.JavaProcessConnection.PostMessage(Xamarin.AndroidDesigner.BinaryMessage message)
> Xamarin.AndroidDesigner.dll!Xamarin.AndroidDesigner.DesignerProject.NotifyProjectPathChange(string path, bool isFolder, Xamarin.AndroidDesigner.PathChange change)
> Xamarin.AndroidDesigner.dll!Xamarin.AndroidDesigner.DesignerProject.NotifyProjectFileChange.AnonymousMethod__19()
> Xamarin.AndroidDesigner.dll!Xamarin.AndroidDesigner.DesignerProject.NotifyResourceDirectoryProcessed(bool hadBuildErrors = false)
> Xamarin.VisualStudio.Android.dll!Xamarin.VisualStudio.Android.MonoAndroidFlavoredProject.OnDesignerUpdate(object sender, System.EventArgs e)

## Additional version information (brief)

### Windows 8.1 (64-bit) in VMWare Fusion 6.0.6 (2684343)

Microsoft Visual Studio Professional 2013
Version 12.0.30723.00 Update 3
Microsoft .NET Framework
Version 4.6.00081

### Additional Android SDK versions

Android SDK Platform-tools 22
Android SDK Build-tools 21.1.2
Comment 2 Brendan Zagaeski (Xamarin Team, assistant) 2015-08-14 12:10:43 UTC
## Possible workarounds

### Option 1

Copy and paste an existing layout file. Then rename the file as desired. In my tests this worked smoothly.

### Option 2

1. Open an existing layout from the Solution Explorer in the Android Designer. (Or copy and paste an existing layout file, and then delete the duplicate.)

2. Add the new layout to the project.

(Note to the Xamarin engineers: perhaps this workaround hints that the problem is a form of race condition related to the Android Designer attempting to start up and process the new layout immediately as the layout is being added?)

### Option 3

1. Right-click an existing layout in any project (for example, you can create a new Android app from template).

2. Select "Open With..."

3. Highlight "XML (Text) Editor".

4. Click the "Set as Default" button.

5. Restart Visual Studio.

This allowed me to add new layouts to the project without any hangs after step 5. To open the files in the graphical designer, you can then use the "Open With" menu again and select the "Android Designer" (and optionally set it back to the default).
Comment 4 Alan McGovern 2015-08-25 16:20:35 UTC
This was backported to the c5 branch last week: https://github.com/xamarin/md-addins/commit/52ce0d8affae70c2d838929f8e7aa470b163a174
Comment 5 Alan McGovern 2015-08-25 16:22:21 UTC

*** This bug has been marked as a duplicate of bug 31603 ***
Comment 6 Alan McGovern 2015-08-25 16:23:24 UTC

*** This bug has been marked as a duplicate of bug 31519 ***
Comment 7 Brendan Zagaeski (Xamarin Team, assistant) 2015-09-14 13:23:09 UTC
## Verification status: no longer reproducible as of the Alpha channel Cycle 6 Preview

BAD:  XamarinVS 3.11.894.0  (d70d139) + Android SDK Tools 24.3.4
BAD:  XamarinVS 3.11.1433.0 (0ed0149) + Android SDK Tools 24.3.4
GOOD: XamarinVS  (a1dc0d5) + Android SDK Tools 24.3.4

According to my tests this is not a precise duplicate of Bug 31519. If I downgrade to Android SDK Tools 24.3.3 with XamarinVS 3.11.1433.0 (0ed0149) so that my versions are mismatched as in Bug 31519, I do _not_ hit the hang from that bug. I am accordingly adjusting this Bug 32845 to remove the duplicate status.

Because I can still reproduce the problem on the Stable and Beta channels (based on Cycle 5), I am adjusting the target milestone to Cycle 6 (where I no longer see the problem).

## Additional Android SDK version info

Android SDK Platform-tools 23.0.1
Android SDK Build-tools 22.0.1
Comment 9 Abhishek 2015-10-01 08:34:58 UTC
I have checked this issue with the latest C6 build:
Xamarin.VisualStudio_4.0.0.1545_cc6a0f7f436ff8213a21b3d81debf314c3e3da57. This issue is working fine with SDK Tools version 24.3.4 after adding the layout file VS does not hang. Here is the screencast for the same:

Hence closing this issue.