Bug 32341 - [XF 1.4.4] Generated .g.cs files for XAML are not seen by Visual Studio Intellisense
Summary: [XF 1.4.4] Generated .g.cs files for XAML are not seen by Visual Studio Intel...
Alias: None
Product: Forms
Classification: Xamarin
Component: Forms ()
Version: 1.4.4
Hardware: PC Windows
: Normal normal
Target Milestone: ---
Assignee: Stephane Delcroix
Depends on:
Reported: 2015-07-22 22:13 UTC by Brendan Zagaeski (Xamarin Team, assistant)
Modified: 2015-11-21 12:18 UTC (History)
9 users (show)

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

Test case (269.44 KB, application/zip)
2015-07-22 22:13 UTC, Brendan Zagaeski (Xamarin Team, assistant)
Additional version information (3.49 KB, text/plain)
2015-07-22 22:13 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 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 Brendan Zagaeski (Xamarin Team, assistant) 2015-07-22 22:13:13 UTC
Created attachment 12175 [details]
Test case

[XF 1.4.4] Generated .g.cs files for XAML are not seen by Visual Studio Intellisense

This issue does not affect Xamarin Studio, presumably because Xamarin Studio uses a different mechanism to register the information from the generated files into code completion.

## Regression status: regression between 1.4.3 and 1.4.4


## Steps to reproduce

1. Open the attached test case. (I tested in VS 2013 Update 4).

2. Restore the NuGet packages.

3. Make a modification to the `Page1.xaml` file and save it. This step is just to kick the "MSBuild:UpdateDesignTimeXaml" Custom Tool to create the `.g.cs` file. So it is sufficient just to overwrite "Page1" with "Page1" and save the file.

4. Navigate to the `Page1.xaml.cs` file to check if the types from `.g.cs` are seen by Intellisense.

(Note: the test case is just a new "Visual C# -> Mobile Apps -> Blank App (Xamarin.Forms Portable)" project created in VS, updated using NuGet package manager to Xamarin.Forms, with a default template XAML page added.)

## Results

Step 3 does _not_ produce a `.g.cs` file. The `obj\Debug\` folder does not contain any `.g.cs` files.

Building the FormsApp1 project _does_ produce a `.g.cs` file:
> obj\Debug\FormsApp1.Page1.xaml.g.cs

But the Intellisense apparently does not pay attention to that file. So for example, the `InitializeComponent()` call in `Page1.xaml.cs` is still listed as "The name 'InitializeComponent' does not exist in the current context" even after building the project successfully. A more troublesome example is that adding `x:name="MyLabel"` to the Label element in the `.xaml` file does not allow Intellisense completion of "MyLabel" in `Page1.xaml.cs`.

## "Expected" results from XF

Step 3 _does_ produce a `.g.cs` file:
> obj\Debug\Page1.xaml.g.cs

Building the FormsApp1 project generates this same file name.

The Intellisense _does_ pay attention this file, so `InitializeComponent()` in `Page1.xaml.cs` is defined, and it's possible to jump to the definition within the `.g.cs` file.

## Additional version info (brief)

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

Microsoft Visual Studio Professional 2013
Version 12.0.31101.00 Update 4
Microsoft .NET Framework
Version 4.6.00057

Xamarin   3.11.785.0 (d8dbdd9)
Comment 1 Brendan Zagaeski (Xamarin Team, assistant) 2015-07-22 22:13:32 UTC
Created attachment 12176 [details]
Additional version information
Comment 2 Stephane Delcroix 2015-07-28 16:03:52 UTC
fixed in 1.4.4
Comment 3 Ahmed Alejo 2015-08-03 00:07:32 UTC
Has this been released, cos i was still having this issue with the version a minute ago.

Before getting to the post that resulted into the bug filing.

I didn´t even have a clue it was xamarin forms specific.

After reading Brendan Zagaeski´s detailed explanation i downgraded to Xamarin.Forms which worked flawlessly.
Comment 4 philip 2015-08-10 17:41:04 UTC
The issue still exists with and XamarinVS 3.11.836, Cycle 5

It does not appear to be fixed.
Comment 5 Brendan Zagaeski (Xamarin Team, assistant) 2015-08-11 02:10:12 UTC
I have now verified that this issue is fixed in XF and higher. That said, it is important to note that this verification is only for the _exact_ test case and steps to reproduce listed in Comment 0.

@philip, since the test case from Comment 0 is no longer sufficient to produce a problem, we're back to my old reply from the forum thread [1]. In short, the Xamarin.Forms engineers will need a new test case to investigate the distinct issue you are seeing. The new test case should be filed on a separate bug report. If you have a Business or higher license, you can send the test case to the Support Team via email [2] (and ideally mention that I requested the test case). An alternative is to attach the new test case directly on a new bug report and add a comment back on this report with the new bug number. Thanks in advance!

> [1] http://forums.xamarin.com/discussion/comment/141442/#Comment_141442

> [2] https://kb.xamarin.com/customer/portal/articles/1632104-how-do-i-contact-xamarin-for-support-

## Verification status: verified fixed in XF and higher


(Tested on VS 2013 Update 3, VS 2013 Update 5, and VS 2015.)

## Steps to verify

1. Open the test case from Comment 0 in Visual Studio.

2. Restore the NuGet packages.

3. Close and reopen the solution. This avoids a potential issue with the NuGet Package Manager where it will sometimes fail to update the assembly references properly in VS 2013 (https://github.com/NuGet/Home/issues/1152).

4. Update the NuGet packages to XF or

5. Open the "Page1.xaml" file.

6. Add `x:Name="MyLabel"` to the label element in the XAML file and save the file.

7. Open the "Page1.xaml.cs" codebehind file.

8. Type a carriage return after "InitializeComponent();", and then start typing "MyLabel".

## Verification results

IntelliSense correctly offers the autocompletion for "MyLabel".

## Additional version information (brief)

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

Microsoft Visual Studio Professional 2013
Version 12.0.40629.00 Update 5
Microsoft .NET Framework
Version 4.6.00081

NuGet Package Manager   2.8.60723.765

Xamarin   3.11.836.0 (ed5c750)
Xamarin.Forms Intellisense   1.0
Comment 6 philip 2015-08-11 15:30:23 UTC
Hi Brendan.

I can confirm that the problem is indeed fixed for the originally attached sample.  Editing the XAML file gets rid of the intellisense error for InitializeComponent(); in the code behind.  This is good because it indicates the problem is not specific to my PC.

However, I don't think a new bug report makes sense because the same problem persists with other projects.  For example, if you download XLabs, you can see that it is not possible to get rid of the intellisense errors.  This is with and XamarinVS 3.11.836 and VS2015.

So I think the included test case just does not exercise the problem sufficiently....  Can you test this with XLabs and let me know if that works for you?

Comment 7 Brendan Zagaeski (Xamarin Team, assistant) 2015-08-11 23:47:28 UTC
Thanks for tip about XLabs. It was not immediately evident to me which project I should focus on, but I took a guess that the "XLabs.Sample" project would be a good place to start, and I found two additional issues:

- Bug 32987
- Bug 32988

(Both are regressions in Xamarin.Forms 1.4.4 compared to 1.4.3. Neither one is related to VS 2015.)

> I don't think a new bug report makes sense

Keep in mind that filing a new bug report will often help an unresolved issue be resolved more quickly and more precisely. (In other words, "when in, doubt file a new bug report.") I also like to follow a rule of exactly 1 test case per bug report (with occasional exceptions for bugs where a follow-up test case is in fact a minimized version of the original test case). Including any more than 1 test case on a bug report can easily lead to confusion and incomplete bug fixes.
Comment 8 philip 2015-08-11 23:52:08 UTC
Great, I'm glad you duplicated these issues with XLabs - that's 90% of the battle!

You guys should make xlabs and other large open source XF projects part of your production tests.  I think I duplicated some previous bugs with xlabs as well.

But I think it's a mistake to open a new bug report if you know it's the same issue.  Of course that's up to you...