Bug 40666 - "The name 'InitializeComponent' does not exist in the current context" VS IntelliSense error due to missing `.g.cs` file if you manually delete the `obj` folder and then reload the solution
Summary: "The name 'InitializeComponent' does not exist in the current context" VS Int...
Status: RESOLVED UPSTREAM
Alias: None
Product: Forms
Classification: Xamarin
Component: Forms ()
Version: 2.2.0
Hardware: PC All
: Normal minor
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2016-04-25 05:36 UTC by Brendan Zagaeski (Xamarin Team, assistant)
Modified: 2017-11-27 21:18 UTC (History)
5 users (show)

Tags: ac
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:
Status:
RESOLVED UPSTREAM

Description Brendan Zagaeski (Xamarin Team, assistant) 2016-04-25 05:36:51 UTC
"The name 'InitializeComponent' does not exist in the current context" due to missing `.g.cs` file if you manually delete the `obj` folder and then reload the solution


This is a follow-up to Bug 33181. It is a _minor_ bug. On top of that, it is a _subtle_ bug. For example, I spent over 8 hours precisely characterizing the bug's behavior before I felt I was ready to file this report. So that's a caution to be especially methodical and attentive when reading this bug report compared to bug reports for other less subtle problems.

The summary of the issue is that the fix for Bug 33181 (that is included in the Xamarin.Forms 2.2.0 pre-releases) leaves 1 very specific situation where the "'InitializeComponent' does not exist" message can _still occur_. This remaining issue seems to happen because Visual Studio writes some information into the `.suo` file that causes Visual Studio not to re-run certain tasks during project load. Workaround options 4 and 5 support this theory: both of those workarounds only modify the `.suo` file.




## Workarounds (tested with Xamarin.Forms 2.2.0.5-pre2 and 2.2.0.23-pre4)


Option 1: Select the portable library project and then click the "Refresh" button in the toolbar of the Solution Explorer.


Option 2: Right-click the `.xaml` file in the Solution Explorer and select "Run Custom Tool".


Option 3: Save any edit to the `.xaml` file. The edit can be simple as selecting any individual character in the file and typing the same character again.


Option 4: Click the "Show All Files" button in the toolbar of the Solution Explorer to switch the file visibility in the portable library project. Then close and reopen the solution.


Option 5 (not recommended): Navigate to the solution directory in Explorer and then delete the hidden `.suo` file (VS 2013) or `.vs` folder (VS 2015).




## Regression status: not a regression

BAD: Xamarin.Forms 2.2.0.23-pre4
BAD: Xamarin.Forms 2.1.0.6529
BAD: Xamarin.Forms 1.4.3.6376

There are some additional subtleties about this regression status because 2.2.0.23-pre4 includes the fix for Bug 33181. For example, on 2.1.0.6529, only workaround options 2 and 3 are effective. None of the other workarounds will work with that older version. I will post a follow-up comment to discuss a few more details about the regression status.




## Steps to replicate

1. Create a new "Visual C# > Cross-Platform > Blank App (Xamarin.Forms Portable)" project in Visual Studio (tested in VS 2013 Update 5 and VS 2015 Update 1).

2. If you're using VS 2013, delete the "GettingStarted.Xamarin" file from the portable library project to avoid Bug 40327.

3. (Optional) Remove all of the projects from the solution except for the portable library project.

4. Add a new "Visual C# > Cross-Platform > Forms Xaml Page" item to the portable library project.

5. Update the Xamarin.Forms NuGet package to 2.2.0.23-pre4 in all of the projects in the solution.

6. Close and save the solution.

7. Re-open and re-close the solution. (This step helps make sure that Visual Studio has written the "bad" information into the `.suo` file.)

8. In Explorer, navigate to the portable library project's project directory.

9. Delete the `obj` folder.

10. Reopen the solution in Visual Studio.

11. Open the `.xaml.cs` file for the "Forms Xaml Page" from step 4.

12. Wait a few moments for the IntelliSense to refresh.




## Results



### In the text editor

`InitializeComponent` has a red squiggly line underneath it.



### In "View > Error List" (with the drop-down set to "IntelliSense Only")

An IntelliSense error appears:

> Error	CS0103	The name 'InitializeComponent' does not exist in the current context



### In the `obj` folder for the portable library project

The `obj` folder does not contain any `.g.cs` file yet:

> C:\source\FormsPortable1\FormsPortable1\FormsPortable1>dir /b obj\Debug\*.g.cs
> File Not Found




## Results after applying one of the workarounds

The IntelliSense error and red squiggly line go away.

And the `obj` folder now _does_ contain a `.g.cs` file:

> C:\source\FormsPortable1\FormsPortable1\FormsPortable1>dir /b obj\Debug\*.g.cs
> FormsPortable1.Page1.xaml.g.cs




## Additional version info (brief)

XF 2.2.0.23-pre4

XamarinVS 4.0.3.214 (0dd817c)

Tested on both Visual Studio 2015 Update 1 and Visual Studio 2013 Update 5

Tested on both Windows 10 (64-bit) and Windows 8.1 (64-bit)
Comment 1 Brendan Zagaeski (Xamarin Team, assistant) 2016-04-25 05:38:17 UTC
## Extra complication: from a certain perspective, this issue actually _is_ a regression in Xamarin.Forms 2.2.0

If you use the _new_ `Xamarin.Forms.targets` from 2.2.0 (that includes the fix for Bug 33181) with the _old_ `Xamarin.Forms.Build.Tasks.dll` from 2.1.0.6529, that _stops_ the problem.

In other words, the reason 2.1.0.6529 and 1.4.3.6376 were "BAD" was that the `.targets` files were "bad." But the breakage in 2.2.0 is a _different_ problem where the `Xamarin.Forms.Build.Tasks.dll` file is "bad."



### Steps to demonstrate this more subtle regression status

1. Start with the "bad" project from Comment 0.


2. Quit Visual Studio.


3. Copy the "Xamarin.Forms.Build.Tasks.dll" file from the Xamarin.Forms 2.1.0.6529 NuGet package into the corresponding location in the "bad" project, overwriting the existing file:

> packages\Xamarin.Forms.2.2.0.23-pre4\build\portable-win+net45+wp80+win81+wpa81+MonoAndroid10+MonoTouch10+Xamarin.iOS10\Xamarin.Forms.Build.Tasks.dll

4. Open the solution in Visual Studio and apply workaround Option 1, 4, or 5. (Don't use option 2 or 3 because they behave a little differently. I believe the problem is that they don't modify the `.suo` file.)


5. You can now repeat steps 7 - 12 from Comment 0 as many times as you like, and the `.g.cs` file will _always_ be generated during project load.



### Even more fun: step 4 might mean that this is an _intentional_ optimization provided by Visual Studio

The fact that step 4 is required hints that Visual Studio writes _extra_ information into the `.suo` file when the "bad" build tasks are loaded. So even after the build tasks have been replaced with the old "good" versions, the extra "bad" information stays in the `.suo` file until the file is explicitly refreshed.

I have a hunch that _maybe_ what's happening is that the new "bad" build tasks might actually be providing _more_ "good" details to Visual Studio. Perhaps Visual Studio uses those additional details to keep track (in the `.suo` file) of whether it has already run all the project-load tasks for the solution. When Visual Studio detects that it _has_ already run the project-load tasks, maybe it simply skips those tasks to save time. If this theory is correct and it is possible to carefully explain why, then this bug can perhaps be marked RESOLVED FEATURE.
Comment 3 David Ortinau [MSFT] 2017-11-27 21:18:47 UTC
Reviewed in VS17 15.5 Preview builds and library projects (.NET Standard in particular) are no longer exhibiting this problem for me.

If anyone observes this issue again, please file it against the IDE product as it's primarily related to design-time build processes.