Bug 59800 - iOS 11 related releases of Visual Studio for Mac and Xcode not working properly with solution loaded from Windows share
Summary: iOS 11 related releases of Visual Studio for Mac and Xcode not working proper...
Status: REOPENED
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: iOS add-in (show other bugs)
Version: 7.2 (d15-4)
Hardware: PC Mac OS
: Normal normal
Target Milestone: Future Cycle (TBD)
Assignee: Jeffrey Stedfast
URL:
: 59846 60362 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-09-27 20:25 UTC by David Messina
Modified: 2017-12-13 13:32 UTC (History)
5 users (show)

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


Attachments
Opening Xcode from Visual Studio (62.19 KB, image/jpeg)
2017-09-27 20:25 UTC, David Messina
Details
No assistant results after indexing completes (121.79 KB, image/jpeg)
2017-09-27 20:26 UTC, David Messina
Details
Error creating outlet after manually opening .h file (107.96 KB, image/jpeg)
2017-09-27 20:27 UTC, David Messina
Details
Visual Studio About details (1.90 KB, text/plain)
2017-09-28 13:06 UTC, David Messina
Details
Latest Visual Studio IDE log (31.13 KB, text/plain)
2017-09-28 13:17 UTC, David Messina
Details
file not found popup when opening the storyboard in xcode (30.21 KB, image/jpeg)
2017-10-05 09:36 UTC, softlion
Details

Description David Messina 2017-09-27 20:25:07 UTC
Prior to the iOS 11 related releases of Visual Studio for Mac and Xcode, I was able to open a solution in VS from a Windows share, do my storyboard editing in Xcode, and then click back to VS to sync the changes. I do everything else for the project from Windows.

After updating, however, the Xcode 9 assistant editor shows no results when clicking a view controller. If I manually open the .h file in the assistant editor and try to add an outlet, it throws an error. The 7.4 build 45 release from bug 58198 resolved this problem only when loading a solution that is stored directly on the Mac. The problems persist when working from a Windows share (whether it is SMB or AFP).
Comment 1 David Messina 2017-09-27 20:25:51 UTC
Created attachment 24967 [details]
Opening Xcode from Visual Studio
Comment 2 David Messina 2017-09-27 20:26:27 UTC
Created attachment 24968 [details]
No assistant results after indexing completes
Comment 3 David Messina 2017-09-27 20:27:00 UTC
Created attachment 24969 [details]
Error creating outlet after manually opening .h file
Comment 4 mhendrick 2017-09-28 08:42:03 UTC
An workaround i used is.
To add  the reference in vs for mac. Xcode will pick it up.

Its the name attribute of identity
Comment 5 Matt Ward 2017-09-28 08:43:32 UTC
Thanks for the bug report. To further diagnose the issue, we need some additional information.

1) In the Xamarin Studio About box, click on Show Details and then on Copy Information, then add the information to the bug report.
2) Click on the command Help -> Open Log Directory, then attach the latest IDE log file.
Comment 6 David Messina 2017-09-28 13:06:53 UTC
Created attachment 24995 [details]
Visual Studio About details
Comment 7 David Messina 2017-09-28 13:17:42 UTC
Created attachment 24996 [details]
Latest Visual Studio IDE log
Comment 8 David Messina 2017-09-29 21:03:49 UTC
Information has been provided.
Comment 9 softlion 2017-09-30 12:05:36 UTC
+1
Happens with all versions of Visual Studio Mac.

7.1, 7.2 and even 7.4

Works fine with the same project when it is not on the windows share.
Comment 10 Jeffrey Stedfast 2017-09-30 13:27:53 UTC
*** Bug 59846 has been marked as a duplicate of this bug. ***
Comment 11 softlion 2017-09-30 16:43:28 UTC
Could you also fix:
- file not found popup when opening the storyboard in xcode
- storyboard file not selected when xcode opens
- storyboard files mixed with fake .m/.h source files in a flat folder. Use subfolders instead to make it easy to select storyboard files.
Comment 12 softlion 2017-09-30 16:48:51 UTC
And finally fix:
- vsmac incorrectly creates .designer.cs files for all 'exported' classes in the solution when opening a storyboard in vsmac storyboard editor.
- vsmac adds png/jpg files it finds in the resource folder to any storyboard when opening a storyboard in vsmac storyboard editor.
- vsmac changes the order of items in plist files (from the vs windows counterpart, especially icons), making tracking change by git a mess
- vsmac removes empty xml tags in csproj, tags added by vs windows, making tracking change by git a mess
Comment 13 Jeffrey Stedfast 2017-10-04 14:22:12 UTC
> Could you also fix:
> - file not found popup when opening the storyboard in xcode

I don't get this error

> - storyboard file not selected when xcode opens

The storyboard is selected for me when I open in Xcode...

> - storyboard files mixed with fake .m/.h source files in a flat folder. Use subfolders instead to make it easy to select storyboard files.

They need to be in a flat folder or Xcode9 won't find them. I literally just had to commit a patch to put them in a flat folder because Xcope9 wasn't finding them otherwise and so if you tried to add an Outlet, Xcode9 would say "Cannot find source file for class ViewController" even though you literally just dragged&dropped an Outlet to ViewController.h.
Comment 14 Jeffrey Stedfast 2017-10-04 14:24:52 UTC
> And finally fix:
> - vsmac incorrectly creates .designer.cs files for all 'exported' classes in the solution when opening a storyboard in vsmac storyboard editor.

This is done on purpose because otherwise there's no way to add codebehind. We can't safely add it to the non-designer .cs file or we would risk clobbering your code.

> - vsmac adds png/jpg files it finds in the resource folder to any storyboard when opening a storyboard in vsmac storyboard editor.

This isn't a bug. It does this by design. We have no idea what images you are using and which ones you *might* want to use from Xcode, so we have to export them all.
Comment 15 softlion 2017-10-05 09:36:47 UTC
Created attachment 25118 [details]
file not found popup when opening the storyboard in xcode

- file not found popup when opening the storyboard in xcode

I get that all the time with the version 7.2 of VS Mac.

See my pic capture
Comment 16 softlion 2017-10-05 09:40:32 UTC
The problem is the path: the "resource" folder does not exist in "obj/xcode/0" because you are flattening the hierarchy.

So if you don't get xcode error, then you have a build of vs that i don't.

I use 7.2 build 634
Comment 17 Jeffrey Stedfast 2017-10-09 19:20:30 UTC
Thanks. Comment #16 is extremely useful info... Cooking up a fix now.
Comment 18 Jeffrey Stedfast 2017-10-09 21:09:35 UTC
PR: https://github.com/xamarin/md-addins/pull/2574
Comment 19 softlion 2017-10-09 21:13:06 UTC
Ty !
Comment 20 softlion 2017-10-18 11:45:19 UTC
Any news when this will be available ?
A private build maybe ?
It is *extremly* annoying.

ty.
Comment 21 Brendan Zagaeski (Xamarin Team, assistant) 2017-10-25 17:59:45 UTC
## Bookkeeping status update

The pull request from Comment 18 has now been merged into the "master" development branch (md-addins/0467620a8c6ee41b7846c5d59cabe83499d17f59).  This means that by default the candidate fix will be included in the next version of Visual Studio for Mac that is branched from the "master" development branch.  At the moment, that aligns with the "15.6" Target Milestone as indicated in the "Target Milestone" field of this bug.  The timeline for the first previews that include that candidate fix are still a little ways off since they would fall after the current "15.5" Target Milestone preview (Visual Studio 2017 for Mac version 7.3 Preview) moves to non-preview.

That said, because there are a few users (3 currently) following this bug report who might find it useful to be able to go back as soon as possible to their old Xcode 8 workflow for editing files directly off of Windows share folders (rather than having to copy the projects back and forth), I will send a request to the Visual Studio for Mac team about the possibility of backporting the candidate change to the Visual Studio 2017 for Mac version 7.3 Preview (the "15.5" Target Milestone).  In considering that request, the team will assess the level of risk associated with the fix and the suitability of additional changes to the version 7.3 Preview at this time.
Comment 22 Jeffrey Stedfast 2017-10-26 14:23:39 UTC
I've back-ported the fix to the 15.5 milestone here: https://github.com/xamarin/md-addins/pull/2640
Comment 23 Jeffrey Stedfast 2017-10-26 15:16:42 UTC
*** Bug 60362 has been marked as a duplicate of this bug. ***
Comment 24 xamarin-release-manager 2017-10-26 16:58:54 UTC
Fixed in version 7.3.0.739 (d15-5)

Author: Jeffrey Stedfast
Commit: b175e456f3b43cb02ee16e5fbfb92ff407f3e965 (xamarin/md-addins)
Included in Commit: a0a9119bc4056463c3780f9597fde5323a7d94e1 (mono/monodevelop)
Comment 25 David Messina 2017-12-05 15:56:42 UTC
Since the target milestone is 15.5 and that has now been released, should this fix now be in place? I just updated VS Mac and Xcode to the latest versions and experienced the same behavior as before.
Comment 26 David Messina 2017-12-12 15:29:46 UTC
Also no difference with 15.5.1.
Comment 27 Brendan Zagaeski (Xamarin Team, assistant) 2017-12-13 05:42:47 UTC
## Partial workaround found as part of Experiment 2 (from below)

After opening the storyboard in Xcode (after step 6 of the steps to test below), set "File > Project Properties > Derived Data" in Xcode to "Custom Location" and set the path to a local folder like /private/tmp/DerivedData1 (or whatever other local folder you prefer).

Admittedly since this workaround step must be repeated each time the storyboard is opened, it might not be much more convenient than copying the whole solution directory back and forth.

Experiment 3 below indicates that this issue with the location of the DerivedData affects plain Xcode projects as well with no involvement of Xamarin or Visual Studio.

I will reopen this bug for a little further consideration of whether it might be worth adding some logic in the Visual Studio for Mac Tools for Xamarin to handle this scenario automatically for users (as an enhancement).




## Verification status: not yet fixed for my test environment with the latest released version

> BAD: Visual Studio 2017 for Mac (7.3.0.799) (df59042) (Xamarin addins: 51068d6)
The non-public change from Comment 18 and Comment 22 is included in this version, but based on my new results I wouldn't expect that change to resolve this issue, at least for my testing environment.  For a tiny bit of additional context, the change is related to adjusting the lookup path used to open the generated Xcode project.




## Steps followed to test

1. Share a folder from a Windows computer, allowing read/write privileges.

2. Connect to the shared folder with the Samba protocol in macOS using "Go > Connect to Server" in Finder.

3. Create a new "iOS > App > Single View App" iPhone app in Visual Studio for Mac in the Windows share folder.  (Note: I tried creating the project directly on the share or moving it, and I didn't notice any differences in behavior between those 2 options.)

4. Open the project again in Visual Studio for Mac.

5. Control-click the Main.storyboard file and select "Xcode Interface Builder".

6. After Xcode opens the project, wait for the "Indexing" status to complete in the Xcode status bar.

7. Ensure the storyboard is open in the main window, and open the Assistant editor.




## BAD Results with Xcode 9.0 (9A235)

a. The Assistant editor shows "No Assistant Results".

b. If you add a button to the storyboard, navigate to ViewController.h using the Manual drop-down menu in the Assistant editor, and then try to control-click and drag to create an Outlet or Action for the button, you will get the error:

"Could not insert new outlet connection: Could not find any information for the class named ViewController"




## GOOD Results with Xcode 8.3.3 (8E3004b) on a Windows share, or with Xcode 9.0 when using a local project directory 

a. The Assistant editor automatically selects the ViewController.m file (once the "Indexing" status completes).

b. Adding an Outlet or Action is successful.




## Experiment 1

1. Run the "Xcode Interface Builder" with Xcode 9.0 from a local directory.

2. Copy the "good" generated obj/Xcode directory to the Windows share.

3. Open the .xcodeproj from that directory in Xcode.


Result: BAD.  The BAD behaviors occur.




## Experiment 2


1. Follow the steps from Experiment 1.


2. Now delete the file "*.xcodeproj/project.xcworkspace/xcuserdata/*.xcuserdatad/WorkspaceSettings.xcsettings" from the obj/Xcode directory.  Or delete following lines from that file.

```
<key>IDEWorkspaceUserSettings_DerivedDataCustomLocation</key>
<string>DerivedData</string>
```


3. Again open the .xcodeproj in Xcode.



Result: GOOD.

Interestingly, since /private/tmp/DerivedData1 _does_ work for the custom location, the "good" behavior evidently does _not_ depend on Spotlight indexing (/private/tmp is not indexed).  Maybe there is instead some file metadata that Xcode 9.0 now writes that can't be written on the Windows share?




## Experiment 3

1. Create an Objective-C iOS project in Xcode on the Windows share.

2. Under "File > Project Properties > Derived Data" select "Project-relative Location", and leave the default "DerivedData" value.


Result: BAD.  The same 2 bad behaviors occurs as observed for the Xcode project generated by Visual Studio for Mac.

(Note that this scenario does not involve Xamarin or Visual Studio for Mac at all.)




## Additional testing environment info

Mono Framework MDK 5.4.1.7 (2017-06/e66d9abbb27) (64-bit)

macOS 10.12.6




## Testing notes about a behavior in my environment that might affect my specific results

The obj/Xcode directory does not get fully deleted as it should from the Windows share after I quit Xcode in my environment and bring Visual Studio for Mac back to the foreground.  This seems to be separate from the issue in this bug report because it affects both Xcode 9.0 and Xcode 8.3.3 in my environment.  I believe it is a peculiarity in my testing environment because I ran into the same problem even when just saving files in a Swift project in Xcode.
Comment 28 David Messina 2017-12-13 13:32:29 UTC
Thanks for the information. Changing the derived data folder to a local one is a good enough workaround for now.

Note You need to log in before you can comment on or make changes to this bug.