(Impossible) Feature Request :)

Hi

This is probably not practical, but I'll put it in as a feature request anyway :p

My ViewModel contains many public properties that are only public because they are used by the WPF view.

I use the "Remove unused property" and "Property can be made private" extensively to tidy up my code.

I don't want to turn off the warnings, because it will affect the rest of my code where I need the warning, and I don't want to use the Supress warning message feature.

At the moment, my "workaround" is to put all these "public" properties into the interface for the ViewModel - while this gets around the "resharper issue", it means I've now got an interface that its full of irrelevant properties - interface segregation.

I can't really see how you could do it, but would there be any way for R# to "know" that these properties are being referenced in XAML?

If there is no way to do this, I would be curious as to how other users handle this very common case.

Thanks

Jeremy

14 comments

I don't think this is really an impossible request - it's just that XAML/WPF has been somewhat of a poor-relation for R# and resolving bindings hasn't been implemented yet.   It does feel that that's changing gradually, though it's pretty clear that JB don't really write MVVM-style WPF apps internally.

But in the mean time, you can use Resharper's annotation attributes to mark things as 'used implictly' if they're used by XAML bindings - that stops the false-positive warnings.  If you're feeling brave/lazy, you can apply this attribute to a viewmodel class, and have eveything marked as used-implictly with just one attribute.

Will

0

Gentlemen,

first of all, are these properties used explicitely in XAML? Or they just mentioned somewhere in binding and actual DataContext object is set while runtime to point exactly to the properties?
It would be great, if you send us solution for investigation.
Another workaround is marking these properties with UsedImplicitlyAttribute.

0

Sergey,

I can't speak for the OP, but the situation I see where R# is weak is where they're properties used in bindings.   In situations where the design-time data stuff (d:DataContext="{d:DesignInstance, blah blah}, etc) has been configured, it seems R# *could* resolve many of the bindings (hell, even VS is managing to resolve them), but it doesn't, (yet, I hope).

These bugs are all relevant:

http://youtrack.jetbrains.net/issues?q=DesignInstance

They hint that all this stuff is going to be fixed in 6.0 - is that still the plan?

0

Hi Sergey,

The public properties are all set in the databindings in the XAML. The DataContext is set at runtime.

<Button Command="{Binding OpenSplitRowWindowCommand}" />



 

public ICommand OpenSplitRowWindowCommand
        {
            get { return _openSplitRowWindowCommand ?? (_openSplitRowWindowCommand = new RelayCommand(() => Messenger.Default.Send(new SplitRowMessage(ContractDetailRowService)))); }
        }


Where is the UseImplicitly attribute - I can't find it?

Thanks
Jeremy
0

I just found the UsedImplicitlyAttribute - that seemed to do the trick.

Still - it would be nice if it could determine that the properties are being used in the XAML DataBindings.

Thanks
Jeremy

0

We cannot be sure the identifier used in binding is bound to the property or it's just a coincidence. Why are you setting DataContext at runtime?

0

Hi Sergey

I'm setting the DataContext at runtime because the ViewModel takes a number of parameters in the constructor, and I still haven't learned how to use StructureMap to inject these parameters into the XAML!

My code looks something like:

var viewModel = ObjectFactory.GetInstance<IViewModel>();

var window = new MyWindow{DataContext = viewModel};

Any suggestions most gladly welcomed.

Regards
Jeremy

0

Hello,

My ViewModel contains many public properties that are only public
because they are used by the WPF view.

At the moment, my "workaround" is to put all these "public" properties
into the interface for the ViewModel - while this gets around the
"resharper issue", it means I've now got an interface that its full of
irrelevant properties - interface segregation.


As I've recently learned, WPF does not require properties to be public. You
can reference private properties from XAML bindings in case they're implementing
some interface -- not necessarily the same interface of the ViewModel, of
course. The binding syntax for the property in XAML is "(interface.property)"
in this case, which also gives the advantage of early-bound references in
XAML code because, unlike just the "property" string, this could be fully
validated at design time, updated during refactorings, and so on.

PS (a theoretical question) why're the properties irrelevant to the ViewModel
interface? In my understanding, a view model exists solely for databinding
from XAML, so the interface fits them just good.


Serge Baltic
JetBrains, Inc — http://www.jetbrains.com
“Develop with pleasure!”


0

Hi Serge,

Thanks very much for your very interesting reply.

I will investigate the question of interface.property further.

In fact your question as to why the properties are irrelevant made me rethink entirely what my original complaint was about.

My sloppy logic was as follows:

Resharper was telling me that the public properties in my class could be made private.
I included the properties in the interface - solved the "class problem", but now resharper tells me that only implementations of the properties on the interface are being used.
So after a year or so of this, I finally post a message here whinging about it.

It was only after reading your reply today that it actually dawned on me as to what Resharper was really telling me - namely - that I don't have Tests covering these "irrelevant" properties.

So Serge - I really must thank you for having given me a kick up the backside!

Best regards
Jeremy

0

... which also gives the advantage of early-bound references in
XAML code because, unlike just the "property" string, this could be fully
validated at design time, updated during refactorings, and so on.


It worries my when you say this, because it makes me think that you are working on the basis that ordinary "{Binding MyPublicPropertyName}" bindings cannot be resolved at design time.

This is absolutely definitely not the case - if the d:DataContext="{d:DesignInstance vm:MyViewModel, IsDesignTimeCreatable=True}" stuff is set correctly for the window, then VS has no trouble resolving the bindings - it even creates an instance of the viewmodel, calls the property and puts the result onto to the design surface, which is several steps more than we're asking for R# to be able to.

Let's face it, if VS can manage to do this, then JB ought to be able to get this working during their lunch break.

0

Gentlemen,
I've got good news: I've implemented support of d:DataContext to specify context type. Moreover, today I'm going to create quickfix to easily add this annotation.
Develop with pleasure :)

0

Cool :-)

But actually I find whining on your forum more pleasurable than developing, so don't fix everything...

0

Don't worry, nobody would ever fix everything ;)

0

Please sign in to leave a comment.