What's wrong with
public partial class MainWindow : Window
{
public ObservableCollection<TabViewModel> Tabs { get; set; }
public ICollectionView TabsViewSource { get; set; }
public int CurrentIndex { get { return TabsViewSource.CurrentPosition; } }
I get
Inconsistent accessibility: property type 'System.Collections.ObjectModel.ObservableCollection' is less accessible than property 'TabsRendering.MainWindow.Tabs'
when i change the code to
public partial class MainWindow : Window
{
ObservableCollection<TabViewModel> Tabs { get; set; }
public ICollectionView TabsViewSource { get; set; }
public int CurrentIndex { get { return TabsViewSource.CurrentPosition; } }
It works. Whats wrong with the public on the ObservableCollection
MakeTabViewModela public type too.
Obviously, it doesn't make sense for a public property on a public containing-type to be of a type that is not public. How could the property present itself to external assemblies?
Your second sample works because, as a general rule, providing no accessibility modifiers means that the least applicable modifier is chosen as the default - in this case: private. Clearly, there are no consistency issues with declaring a private property of an internal (?) type.
What's the accessibility on TabViewModel? I'm guessing it's not public.
The message is very straight-forward. It is contradicting to what you want to do. It says you have something declared as public (Tabs, in this case) but the guy who would be using it also need to know about TabViewModel which is not public. Either make both public or some consistent access specifier.
All of the information above is completely correct and works fine. I just want to add from personal experience that if you are using TFS and getting your project from TFS, different Visual Studio versions can also generate this error.
I entered a project with Visual Studio 2013 update 2 and synched with the TFS to get the solution. When I tried to run the project I got 80 errors. All of them were like "... less accessible than property...". Now it turns out I needed update 4. Once my Visual Studio was update I revered the changes and it worked perfectly.
This might be useful if none of the above works and you are using TFS.
Related
There is a bit of C# syntax that I don't understand.
I am on the receiving end of a couple of classes. Simplified, let's say it's this
public class ParentClass
{
public ParentClass();
public RandomEnumerated Random_Enumerated; //No get/set. Relevant?
}
public class ReceivedClass : ParentClass
{
public ReceivedClass();
public char Random_Field { get; set; }
}
When I do this
public class ExtendedReceivedClass : ReceivedClass
{
public ExtendedReceivedClass();
public char A_New_Random_Field_of_My_Own { get; set; }
}
I get hit by the error
ExtendedReceivedClass.ExtendedReceivedClass() must declare a body because it is not marked abstract, extern, or partial FuelTaCSClient
So instead of being able to do what the parental classes do
public ParentClass();
or
public ReceivedClass();
I have to do this
public LocalWreckerVehicleClass() {}
So my question is
a
Is the "public ReceivedClass();" in ReceivedClass the constructor? Same for ParentClass.
b
If it is, why can they do a shortcut version but I can't
or
if it isn't, what is it?
"I am on the receiving end of a couple of classes" -- I think you're looking at those classes using Visual Studio's "Go To Definition" or similar, and they're defined in another DLL?
You'll notice that Visual Studio is showing you method signatures, but not the bodies of the methods: when all it has is a DLL, it's easy to get the signatures, but harder to get the original C# code which was used to build the DLL. This is just intended to give you an overview of what methods are available, and it's not supposed to be valid C#.
public ParentClass(); is not valid C#. It's the signature of a constructor (showing that there's a public parameterless constructor), but when you define a constructor in C# you need to provide a body:
public ParentClass()
{
// ...
}
I am going to accept this as the answer because it seems to make the most sense. I have no trouble believing that when I ask VS to tell me what is in a parent class that it will give me an abbreviated and slightly askew version of what's actually in it.
I am doing a hard search for the parent class by name using a third-party search tool and if I see anything that either affirms or refutes this conclusion I will post an update.
Thank you to everyone who helped! And canton7 - thank you and have this upvote!
Our Application is an MVC Application . I tried to run code analysis using ReSharper. I am getting "Auto-property accessor is never used" as warnings in many of my view model properties.
For example, ReSharper shows the warning on this:
public bool IsLegalEntry { get; set; }
Can I make a private setter, or can anybody suggest an alternative?
You could make the setter private
public bool IsLegalEntry { get; private set; }
However, this could cause a runtime error if the setter is used implicitly. Alternatively you could decorate the setter with the JetBrains.Annotations.UsedImplicitlyAttribute.
public bool IsLegalEntry { get; [UsedImplicitly] set; }
Alternative to "warning fixing/suppressing" paradigm, you can add testing project to your solution. Then write a test for you business logic hitting the accessor(s) in question among other things.
Not sure this is the action you were looking for, however
it provides the effect you were after
saves for redundant annotation attributes
adds testing bonus
I am trying to create a simple model for parsing a yaml file to my domain object using YamlDotNet. The caveat is, that I want the domain model to be readonly, so I'm attempting to solve this through inheritance and internal setters.
For some reason though, the library throws an exception stating:
Property 'HtmlTemplate' not found on type
'ConsoleApplication1.Repositories.YamlTemplateRepository+DeserializeableTemplate'.
I am using an alias, but even scratching that, and using a test class with the right property names does not set it right.
What am I doing wrong? Have I misunderstood how the library should be used?
The code that calls YamlDotNet looks like this:
deserializer.Deserialize<DeserializeableTemplate>(yamlContents);
and the class I'm deserializing looks like this:
private class DeserializeableTemplate : Template
{
[YamlMember(Alias = "HtmlTemplate")]
public string HtmlTemplateWrapper
{
get { return HtmlTemplate; }
set { HtmlTemplate = value; }
}
// A few more properties...
}
and the class I am inheriting:
public class Template
{
public string HtmlTemplate { get; internal set; }
// A few more properties...
}
(Small console test application with the same error can be found here)
Old question, but I had a similar issue, which was solved by changing the access modifier of the inherited property setter to protected. I'm guessing the internal modifier used here is playing tricks on the deserialization. This might be an unwanted solution for this problem regarding making the model truly readonly, but I wanted to share my solution for future troubleshooters.
I'm using the latest ReSharper - 9. I also have StyleCop installed as well.
When I implement an interface with properties it does this:
public class MyClass : IMyClass
{
public bool MyProperty
{
get
{
}
set
{
}
}
}
I want it to implement like this:
public class MyClass : IMyClass
{
public bool MyProperty { get; set; }
}
Exactly how do I set this up?
I had a similar thing happen on Resharper 9, and I found this related bug in the Resharper issue tracker. Installing the update fixed it for me. Also you could try the Alt + Insert workaround as mentioned on that bug.
You should mark the setting from the screenshot
When you tell ReSharper to 'Implement Missing Members', there's a dropdown in the form that appears called 'Properties As:'. If you set this to Automatic property, it will generate properties in the manner you want them to. It looks like you currently have it set to 'Property with backing field'.
Create an interface with a property
Create a class to implement that interface
Move your cursor onto the class declaration line
Press Alt + Enter, and choose 'Implement Missing Members'
On the form that appears, set 'Properties As:' to 'Automatic property'
Press 'Finish'
Bask in your single line Auto Properties.
my boss insisting on the following rule: all variables passed into constructor should be available through a read-only property.
I don't see a real reason why this should be true, because class should do that it's supposed to do and not to provide theirs structure to others. I understand that sometime it's useful, but it isn't general rule.
Are my thoughts correct? Am I missing something? Anyone can add more arguments or oppose to that?
Example of rule:
public class MyClass
{
public MyClass(ISomeProvider someProvider)
{
SomeProvider = someProvider;
}
public ISomeProvider SomeProvider { get; private set; }
public void DoSomeWork()
{
...
}
}
Thank you.
Personally I would say no... I never believe there is one rule that fits all. If the parameters are used internally to the class then there is no need to expose them.
If you passed a 'raw' string password into an encryption class you wouldn't expect the raw string to be accessible throughout the lifetime of the object, in fact doing so may present a security risk.
On the flip side though, sometimes you have to follow the standards set out by the team/manager. If you think the principle is wrong discuss this detailing the arguments for/against the idea.
It may be applied like a rule on some specific part of the some specific projects (should say, sounds very strange design, but..), but it's never, ever can be a generic rule in software design even in the domain of one single project.
The rule decided by your boss can help in debugging to know the properties of object. It's not a rule, you can treat it as design pattern created by your project manager.
public class MyClass
{
private ISomeProvider someProvider;
public ISomeProvider SomeProvider
{
get
{
//logic here
return this._someProvider;
}
}
public MyClass(ISomeProvider someProvider)
{
this._someProvider = someProvider;
}
public void DoSomeWork()
{
}
}