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!
Related
I am trying to improve some code to take out initialisations and use of the Service Locator in my View Model, so that the container can create them within the constructor. But there are changes to base classes that have hundreds of descendants and this will take a long time to manually fix everyone.
Is there a way that Visual Studio or any other add-in can do this for you? On the descendant it will need to add it into the main constructor and pass it through to the base constructor also. There is only a single constructor on all.
e.g. I have just added the someNewInjectedClass parameter to the base class constructor below:
public class BaseClass
{
private ISomeNewInjectedClass _someNewInjectedClass;
public BaseClass(ISomeNewInjectedClass someNewInjectedClass)
{
_someNewInjectedClass = someNewInjectedClass;
}
}
And that needs to be added to my descendant which is currently this:
public class OneOfManyDecendants : BaseClass
{
public OneOfManyDecendants()
: base()
{
}
}
To become this:
public class OneOfManyDecendants : BaseClass
{
public OneOfManyDecendants(ISomeNewInjectedClass someNewInjectedClass)
: base(someNewInjectedClass)
{
}
}
If you have Resharper you can use "Change Signature" (Ctrl+R,S) refactoring. When doing it select "Resolve with call tree" option. In a next dialog pick "Create parameter..." option for each subclass.
Not quite an answer to my exact question but I am going to go a long the lines of #sinatr's suggestion with this related post: Use class as a single parameter for base parameters
This seems the best way for us going forward and can more easily change in the future.
I just know I'm being an idiot, so somebody please tell me how.
Setup is simple:
Create a solution with three projects (.Net framework, class libraries) named InherTest, InherTest.Base, and InherTest.Base.Inherited
In InherTest.Base, add the following class:
namespace InherTest.Base
{
public abstract class BaseClass
{
internal abstract string MEMBER_1 { get; }
}
}
Copy the exact same code into InherTest, including the namespace.
In InherTest.Base.Inherited, add the following class:
namespace InherTest.Base.Inherited
{
public class Inherited : BaseClass
{
internal override string MEMBER_1 { get; }
}
}
Add a project reference in InherTest.Base.Inherited to InherTest.Base. Note the errors ("abstract member not implemented" and "no suitable member found to override").
Remove that reference and replace it with one to InherTest. Observe that the inheritance also fails.
Why don't they both work?
Edit: Originally I stated that one test would fail and the other would succeed; however, both inheritance attempts fail in the above scenario.
This is because the string is internal so limited to it's own project
Why don't they both work?
They should both fail if they contain the same code as you claim. If that is not the case then the code is different between the 2 projects, specifically the MEMBER_1 is probably declared as public in InherTest project.
The only way that a reference to InherTest would work with the same code you posted is if you have this assembly level attribute InternalsVisibleToAttribute in the project InherTest
[assembly:InternalsVisibleTo("InherTest.Base.Inherited")]
Inherited Namespaces are in different project. (Name spaces seems like together but they are not in a same assembly). You can read that article.
https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/internal
i want to pass a value from a variable from a project to another after referencing project B to A, after referencing, i still don't know how to read it
//Project A
namespace projectA{
public partial class hello : Form
{
public string value;
}
}
}
and for Project B
using projectA{
namespace projectB{
public string value2 = value;
}
}
please help :(, i already added project A to B through add reference and when i type projectA.... there is only one method shown which is the partial class
It sounds to me like you want to declare a static class member, you can do it like this:
public partial class hello : Form
{
public static string value;
}
And then you access it with hello.value, beware that this is bad design, by doing things like this you are going to make code that is hard to understand and hard to maintain.
Of course maintainable code is not something you will accomplish if you are learning so that's not a big deal, you should first understand the basic concepts and learn what does it mean for something to be "static", what does it mean to "instantiate" a class, what are interfaces, abstract classes, events, delegates, lambda expressions, inheritance, extension methods, properties and so on
--EDIT--
Just noticed how wrong the code in projectB is (not valid C#), see if you can understand the code below:
using projectA;
namespace projectB{
class YouMustHaveAClass { //C# does not allow you to declare variables that belong to no class
public string value2 = hello.value;
}
}
I have come across the following code and am not sure what it means?
public class Countries
{
public Countries();
public static bool AllowInvoice(string pCountryCode);
public static bool IsPostcodeMandatory(string pCountryCode);
}
This code is then called in the following way:
Contact.IncludePostCode = Countries.IsPostcodeMandatory(countryCode);
It seems to me that this is an interface? Where the method is being defined, but the body is being written elsewhere?
If this is the case, I would expect that when I search the whole project, I would find the code for the body of the method, but I do not find it anywhere?
Any suggestions?
This class is defined in a referenced assembly, Visual Studio is showing you the class's metadata.
What you see here are just the method signatures, not their implementation. This code would not compile.
I have a solution with two projects each producing a separate dll that is used by another windows application. Each of those projects has a class called MyActions with only one method like so
Project1
public class MyActions
{
public SomeTypeA DoJob(string str1, string str2)
{
}
}
Project 2
public class MyActions
{
public SomeTypeB DoJob(string str1)
{
}
}
The two return types of these two classes are as below
public class SomeTypeA
{
public string stringA { get; set; }
public int someInt { get; set; }
}
public class SomeTypeB
{
public string someStringA { get; set; }
}
The method DoJob in the both the classes of these individual projects have almost 80% code that is the same. Project1 is the one whose MyActions class's DoJob method has some extra bits specific to only Project1.
Now here is the twist.. Project1 is eventually going to be scrapped and its dll will no longer be used.I want to write the code in the best possible way that ensures there is no repeat of code and so that I dont have to make any modifications to remove any un-required code in Project2 once Project1 is discontinued.
I was thinking of using inheritance and overriding the DoJob method. How would that work if their return types are different and they have different input parameters? Perhaps push one of the parameters from Project1's MyActions class to its constructor? I was also thinking of adding a link to Project2's MyActions class in Project1. But not sure about how to go ahead with implementing that and not repeating myself or possibly running into unforeseen problems later. Any tips, suggestions?
If (and only if) the parameters and the return types of the two methods in the two classes are actually different, factor out the code that is line-for-line identical, assuming it is one block, and just create a static method in a new static class, passing the parameters necessary for the common code.
If there are multiple blocks, just have multiple methods.
Call these methods as appropriate from each of the original methods.
If you wanted to create a hierarchical relationship between these classes, which you should only do if it is logical to do so, just make them both inherit a common type, and make the method above a protected method of that common class. Then just call it from the original methods.
Your thought about inheritance is a good one. From your question in read between the lines that you were considering to let Project 1 inherit from Project 2. That's a possibility but probably not the best solution. Here is what I would suggest.
Create a super class for MyActions that both projects extend. Into this class you can move all the code that is shared across both projects (your 80% code of the method). The specific implementations in your MyAction in each project then implement the DoJob method as needed and make use of the provided methods from the super class.
Once you scrap project 1 there will be no changes that have to be made to project 2's code. You end up with a super class though that you do not really need any more in that case. However you won't be repeating yourself anywhere.
I am not yet familiar with the exact differences between java and C# so bear with me if there are differences. This is what code might look like in java.
abstract class AbstractMyActions {
protected SomeType commonMethodForBothProjects() {
...
}
}
public class MyActionsA extends AbstractMyActions {
public SomeType doJob(SomeParameter ..., SomeParameter ...) {
$this->commonMethodForBothProjects();
// Additional steps
}
}
You get the idea.
public class MyActions
{
public ISomeType DoJob(ISomeParam item)
{
}
}
public class SomeTypeA : ISomeType
public class SomeTypeB : ISomeType