Bug 27295 - XAML Bindings not resolved in Visual Studio Editor but could be
Summary: XAML Bindings not resolved in Visual Studio Editor but could be
Status: RESOLVED ANSWERED
Alias: None
Product: Forms
Classification: Xamarin
Component: Forms (show other bugs)
Version: 1.3.4
Hardware: PC Windows
: Normal enhancement
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2015-02-22 22:15 UTC by Mobile Dan
Modified: 2017-11-18 13:13 UTC (History)
22 users (show)

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


Attachments

Description Mobile Dan 2015-02-22 22:15:55 UTC
When I edit a Xamarin Forms XAML ContentPage in Visual Studio and look at a bound element like this...

<Entry Text="{Binding Username}" />

I see a little squiggly green line under the first two letters of Username. This is ReSharper letting me know that it "Cannot resolve symbol 'Username' due to unknown DataContext".

By adding the following properties to the ContentPage element, the warning disappeared (this is used in WPF development)

    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="d"
    xmlns:rootViewModel="clr-namespace:MyApp.ViewModels;assembly=MyApp"
    d:DataContext="{d:DesignInstance rootViewModel:LoginViewModel}"

Not only did the ReSharper warnings disappear but many benefits were unlocked! (available only with ReSharper)

- If the bound field was misspelled, I get a ReSharper warning telling me the property is not found in the bound class.
- I can right click and "Go To Declarartion" to the bound property from the XAML.
- If I right click and "Find Usages" to the bound property from the class, the XAML reference shows up is the usage list. I can "Find Usages" from the XAML also.
- I can rename the bound property using the ReSharper renaming option from the XAML or the class and it will change the other.

This makes the XAML more integrated with the code. It could reduce defects and improve efficiency. Unfortunately when I run the app I get this error: "Xamarin.Forms.Xaml.XamlParseException: MarkupExtension not found for d:DesignInstance".

If Xamarin.Forms was modified to ignore these designer XAML properties, it would unlock some great development features for ReSharper users. (There may be a way to enable these features without Resharper but it might be more involved. It already works in the development environment with ReSharper, but causes a runtime error.)
Comment 1 Michael 2015-03-05 13:54:10 UTC
+1 "Me Too" on this very important feature, please. :)  This really adds a *lot* to the development/design experience and would be very much appreciated.
Comment 2 Michael 2015-03-06 12:44:28 UTC
FYI, there is a NuGet package that just released (as in, like, *today* hah) functionality to strip d: namespace elements from Xamarin.Forms Xaml files during the build process.  If anyone else runs into this problem, they can simply install this project from nuget and configure it to remove the content.  

Documentation found here: https://github.com/firstfloorsoftware/xcc/wiki/Remove-ignorable-content

Very solid workaround until the XF Team can find some cycles to put into this issue.
Comment 3 Chase Florell 2015-09-24 14:03:53 UTC
+1 on this bug. I personally don't want to use custom msbuild targets.
Comment 5 Rich Seviora 2015-11-30 19:14:46 UTC
+1 on this bug too.
Comment 6 Alexandre Chohfi 2015-12-11 23:40:25 UTC
Please, fix this! It would make me much more productive!
Comment 7 E.Z. Hart [MSFT] 2016-04-08 19:18:52 UTC
Thank you for taking the time to submit this feature request. We like this idea and have added it to our internal feature tracking system.

Warm regards,
Xamarin Forms Team
Comment 8 Dbl 2016-05-04 22:50:16 UTC
Any ETA on when this feature will come? It's something which is an absolute must have when working with bindings.
Comment 9 Sascha Schwegelbauer 2016-06-06 10:06:23 UTC
+1 on this missing, very important feature!
Comment 10 Igor Sychev 2016-06-12 16:28:46 UTC
+1! Very tired delete "d:DataContext=" each time when i want build project.
Comment 11 Alexandre Chohfi 2016-08-17 00:25:01 UTC
+1! This is absolutelly NEEDED! Anyone that came from a WPF world know, uses, and loves this feature. Please, implement it.
Comment 12 williamd 2016-09-13 17:00:10 UTC
Just wondering if there are plans to release this feature anytime soon.
Comment 13 sh.naz 2016-11-03 15:17:50 UTC
My team is also handicapped because of this problem.
Comment 14 CAO Yang 2016-11-18 17:04:19 UTC
+1 !!!

This will be socially useful.
Comment 15 CAO Yang 2016-11-18 17:04:54 UTC
+1 !!!

This will be socially useful.
Comment 16 Mark Adamson 2017-10-01 21:03:20 UTC
For anybody else coming to this, it's not an issue anymore, but you do need to remember to have the mc:Ignorable="d" that is in the original post. I missed this so then went down a rabbit hole with the workaround that is no longer required.
Comment 17 Sascha Schwegelbauer 2017-10-02 12:59:39 UTC
Hi Mark,

why isn't it an issue anymore?
Withouth using XCC, I have still the "MarkupExtension not found for d:DesignInstance"-Error!

XCC itself isn't working with netstandard in my case.
What's your solution?

Regards,
Sascha
Comment 18 Mark Adamson 2017-10-02 20:41:03 UTC
For me it just worked without needing XCC as soon as I remembered to add the mc:Ignorable bit, I am running Xamarin.Forms 2.4.0.282 from nuget in a .net standard 2.0 library.

My header in full:

<ContentPage xmlns="http://xamarin.com/schemas/2014/forms"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
             xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
             xmlns:d ="http://schemas.microsoft.com/expression/blend/2008"
             xmlns:viewModels="clr-namespace:MyApp.Forms.ViewModels;assembly=MyApp.Forms"
             x:Class="MyApp.SomePage"
             mc:Ignorable="d"
             d:DataContext="{d:DesignInstance viewModels:MyViewModel}"
             >
Comment 19 Sascha Schwegelbauer 2017-10-03 13:40:36 UTC
No,
I get still the "MarkupExtension not found for d:DesignInstance"-Error - even when targeting netstandard2.0 with XF 2.4.0.282
Did you change anything else?
What does Xamarin say? Should it work?

Regards,
Sascha
Comment 20 Mark Adamson 2017-10-03 19:31:23 UTC
Don't think I changed anything else. If you want to put up an example project on GitHub, I'll happily see if it builds on my setup, then we'll know if its code or dev environment that is different between us.
Comment 21 Sascha Schwegelbauer 2017-10-06 16:09:51 UTC
Yes, would be an interesting test, here's the link to github: https://github.com/sascha-schwegelbauer/XamFormsSample
Comment 22 Mark Adamson 2017-10-07 12:39:30 UTC
That builds on my machine first time. Under 2017.3. Have you tried deleting your bin and obj folders and the .sln folder too? I've found that is needed sometimes these days while bugs are ironed out with visual studio or maybe msbuild.
Comment 23 Sascha Schwegelbauer 2017-10-07 15:18:10 UTC
Building is no problem, but does it run, too?
(I did a blank checkout from github)
Comment 24 daniel packard 2017-10-28 21:46:15 UTC
+1 re: @sascha -- my application also builds fine, but at runtime I get:

```
An exception of type 'Xamarin.Forms.Xaml.XamlParseException' occurred in Xamarin.Forms.Xaml.dll but was not handled in user code
Position 12:14. MarkupExtension not found for d:DesignInstance
```

This happens after migrating from netstandard 1.6 PCL to netstandard 2.0, and upgrading xamarin.forms 2.4.0.18342.
Comment 25 cliff 2017-11-11 05:01:21 UTC
why is this marked Resolved/Answered.  It seems to still be a problem.
Comment 26 Mark Adamson 2017-11-18 13:13:27 UTC
@sascha Sorry, it's a bit too tricky for me to actually run things on Android at the minute. One thing I've noticed in your example is that you have no package reference to Xamarin.Forms from your android project. Not sure how it is building when you then reference the Forms code in your MainActivity. Perhaps try adding that reference though and maybe it will make things work.

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