Bug 1077 - Code completion does not update when references/framework changed if using xbuild/msbuild
Summary: Code completion does not update when references/framework changed if using xb...
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Text Editor ()
Version: 2.8 beta 3
Hardware: Macintosh Mac OS
: High major
Target Milestone: master
Assignee: Lluis Sanchez
: 2837 9743 10301 10486 ()
Depends on:
Reported: 2011-09-27 11:01 UTC by Chris Hardy [MSFT]
Modified: 2015-02-25 06:09 UTC (History)
11 users (show)

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

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 or GitHub 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 Chris Hardy [MSFT] 2011-09-27 11:01:40 UTC
Video of the bug: http://screencast.com/t/5wqEMbP0

When changing from Mono for Android 2.2 to 2.3, this exposes new properties and methods. Both are not exposed through code completion. So first section is MonoDevelop not showing code completion for Camera.CameraInfo which doesn't exist. But then when changing the target framework and showing that MonoAndroid.dll has been updated, the new properties and methods aren't shown.

1) Create a new Mono for Android project.

2) Add the following line into the bottom of the activity. Notice no code completion (correct). Camera.CameraInfo cameraInfo = new Camera.CameraInfo();

3) Build and notice it fails (correct)

3) Update the project to Mono for Android 2.3

4) Add another Camera.CameraInfo line to see if code completion is updated, it is not.

5) Build and notice it builds correctly since those properties and methods exist.
Comment 1 Chris Hardy [MSFT] 2011-09-27 11:04:31 UTC
MonoDevelop 2.8 Beta 3 (2.7.22)
Operating System:
	Mac OS X
	Mono 2.10.5 (tarball Mon Aug 22 20:38:08 EDT 2011)
	GTK 2.24.5 (GTK#
Mono for Android: 1.9.26810.19237066
Monotouch: 4.2.1
Build information:
	Release ID: 20722000
	Git revision: 2db47e2ef89d973930cdc71e53a9883daf534fa1
	Build date: 2011-09-23 11:29:15+0000
Comment 2 Mikayla Hutchinson [MSFT] 2011-09-27 11:25:41 UTC
Pretty sure this is a duplicate of 961, but someone needs to verify this issue
is resolved by that fix.
Comment 3 Mike Krüger 2011-09-28 03:25:46 UTC
I thought first it was a dup, but it wasn't.

Seems that GetReferencedAssemblies/GetReferencedItems functions don't work correctly on monodroid projects. 

I now use the References property & manually do GetReferencedAssemblies - this works now & is the same the project browser is doing to display the references.
Comment 4 Lluis Sanchez 2011-09-28 07:50:05 UTC
Reopening since the patch did not really fix the issue and has been reverted.
Comment 5 Mike Krüger 2011-09-30 00:39:34 UTC
Reopen when that happens again.

*** This bug has been marked as a duplicate of bug 961 ***
Comment 6 Chris Hardy [MSFT] 2011-12-08 16:03:59 UTC
Why did this bug get marked as resolved when this issue is not resolved?
Comment 7 Chris Hardy [MSFT] 2012-01-07 12:36:08 UTC
This issue still exists in 2.8.5 and was never fixed.
Comment 8 Mike Krüger 2012-01-10 02:39:30 UTC
@Chris: It was fixed, but the patch was reverted, because it was not a real fix. The GetReferencedAssemblies/GetReferencedItems functions need to work - then the fix wouldn't be needed.
Comment 9 Mike Bluestein 2012-01-10 14:47:28 UTC
*** Bug 2837 has been marked as a duplicate of this bug. ***
Comment 10 Mikayla Hutchinson [MSFT] 2012-05-01 19:00:42 UTC
Maybe code completion is calling GetReferencedAssemblies/GetReferencedItems *before* the the project builders are  refreshed by the project save.
Comment 11 Mikayla Hutchinson [MSFT] 2013-01-24 17:14:57 UTC
*** Bug 9743 has been marked as a duplicate of this bug. ***
Comment 12 Mikayla Hutchinson [MSFT] 2013-02-15 14:03:22 UTC
*** Bug 10301 has been marked as a duplicate of this bug. ***
Comment 13 Mikayla Hutchinson [MSFT] 2013-02-20 21:01:52 UTC
*** Bug 10486 has been marked as a duplicate of this bug. ***
Comment 14 Lluis Sanchez 2013-06-10 11:49:18 UTC
Fixed in master (e207440ffae73b47a0e88cb9f5953866364a2421).
Comment 15 narayanp 2013-06-19 09:33:10 UTC
Today I have checked this issue with following builds:

X.S 4.0.9(build3)
Xamarin.Android 4.7.10-24
Mono 3.0.12

And we observed that when we use this code while target framework is 2.2, Code completion appears for camera.cameraInfo and gives the same build error after build the project. If we change Target framework to 2.3 and use the same code, we are not seeing code completion for camera.cameraInfo and getting same build error after build the project. This is the screencast for the same: http://screencast.com/t/rsPfMmNdeJ6

Hence reopening this issue
Comment 16 Mikayla Hutchinson [MSFT] 2013-06-19 12:13:08 UTC
This fix is not in the 4.0.9 branch.
Comment 17 Mikayla Hutchinson [MSFT] 2013-08-07 12:46:57 UTC
This fix broke building some projects:

Backing it out of master and 4.0.11.
Comment 18 Mikayla Hutchinson [MSFT] 2013-08-07 19:17:51 UTC
I'm curious why we didn't take the simpler and more efficient approach of deferring the code completion update until the project was saved?

The code completion system could set a flag when the references were changed, then, when the project was saved, do the actual update if the flag was set. Or we could defer actually firing the change events until the save event was fired, e.g. events could add delegates to some fireOnSave queue, and Save would fire them.
Comment 19 Lluis Sanchez 2013-08-20 08:03:58 UTC
There are always different ways of fixing an issue. I used this approach because is a more general and self-contained solution. It is more general because it will cover other cases in which we may depend on an up-to-date msbuild file, and more self-contained since it doesn't require changes outside the msbuild project model.
Comment 20 Lluis Sanchez 2013-08-27 13:30:04 UTC
The fix has been re-applied.
Comment 21 Alan McGovern 2013-08-27 14:49:05 UTC
The fix broke compilation for all csproj files built using the hosted msbuild builder.
Comment 22 Alan McGovern 2013-08-27 19:08:57 UTC
To repro try and build Main.sln inside monodevelop, or build MTDesigner.sln from the md-addins repository.
Comment 23 Mikayla Hutchinson [MSFT] 2013-08-27 19:30:45 UTC
Unfortunately the Load method wipes out the FullFileName value:

Changing the order of the calls doesn't work because Load needs the location to be correct to resolve the imports.

I don't know whether this is an xbuild bug (in which case we could work around it by reflecting project_load_settings, fullFileName, PushThisFileProperty, DoLoad) or whether it's simply not possible.

There's also the question of why it's even hitting this codepath on an unmodified project.

Either way we should have unit tests for this so it's not committed in a broken state again.
Comment 24 Lluis Sanchez 2013-08-28 12:49:29 UTC
We are hitting this code path because at some point after loading the solution, MD marks the project as modified. Maybe this modification notification can be fixed, but to be in the safe side, I'm now forcing MD to use the saved files when building a project.
Comment 25 Mikayla Hutchinson [MSFT] 2013-08-28 13:03:47 UTC
Hm, that seems like a hack that hides real bugs.
Comment 26 Mikayla Hutchinson [MSFT] 2013-08-28 16:38:10 UTC
It's still going to be broken resolving relative references and custom targets in relative paths. 

I confirmed MSBuild doesn't nuke the FullFileName value so this is an xbuild bug.

Checklist for full fix:
1) Fix xbuild's Project.Load(TextReader) to leave FullFileName and pass it to PushThisFileProperty.
2) Work around the bug by duplicating the fixed Project.Load(TextReader) method using reflection.
3) Fix the project incorrectly becoming marked as modified.
4) Remove the "don't use unsaved content when executing targets" hack.
Comment 27 Lluis Sanchez 2013-08-29 05:03:33 UTC
Already fixed.
Comment 28 Sunil Kumar 2014-05-02 06:35:52 UTC
Today we have checked this issue  and  we observed that when we use this code while target framework is 2.2. Code completion does not appears for Camera.CameraInfo and gives the same build error. But after changing the Target framework  2.3 and use the same code than I am seeing autocompletion for Camera.CameraInfo and build the code successfully. 

Screencast: http://screencast.com/t/xscUtuPVkz

Environment info:
=== Xamarin Studio ===

Version 5.0 (build 830)
Installation UUID: 2939b8b4-8977-42bd-82d6-100275ccd9cd
	Mono 3.4.0 ((no/c3fc3ba)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 304000204

=== Apple Developer Tools ===

Xcode 5.1 (5084)
Build 5B130a

=== Xamarin.iOS ===

Version: (Indie Edition)
Hash: 931130b
Build date: 2014-05-01 14:38:28-0400

=== Xamarin.Android ===

Version: 4.12.4 (Indie Edition)
Android SDK: /Users/360_macmini/Library/Developer/Xamarin/android-sdk-mac_x86
	Supported Android versions:
		2.1   (API level 7)
		2.2   (API level 8)
		2.3   (API level 10)
		3.1   (API level 12)
		4.0   (API level 14)
		4.0.3 (API level 15)
Java SDK: /usr
java version "1.6.0_65"
Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609)
Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-462, mixed mode)

=== Xamarin.Mac ===


=== Build Information ===

Release ID: 500000830
Git revision: 1d419850dfed9bc855a1df86d552bf4acd7f4a3e
Build date: 2014-05-01 19:10:08-04
Xamarin addins: ef22d4a21f5135cb3fc0b1bb68e1f0508e5e7fb3

=== Operating System ===

Mac OS X 10.9.0
Darwin 360-MACMINIs-Mac-mini.local 13.0.0 Darwin Kernel Version 13.0.0
    Thu Sep 19 22:22:27 PDT 2013
    root:xnu-2422.1.72~6/RELEASE_X86_64 x86_64

Hence reopening this issue.
Comment 29 Lluis Sanchez 2014-06-09 04:48:26 UTC
Version 2.2 of the framework doesn't have this class, that's why you don't get code completion for it and the build fails.
Comment 30 Naqeeb 2015-02-25 06:09:47 UTC
As per comment 29, we'll not get code completion for version 2.2 because version 2.2 of the framework doesn't have this class.

Hence closing this issue.