Constructor with no definition - c#

I'm new to .Net and I just saw this code that doesn't make sense to me (slightly abridged):
namespace test
{
public class sub : super
{
public sub(string text);
}
}
As you can see, there is a constructor that takes an argument, but does not implement a definition. How does that work? My guess is that it somehow relates to the super class, but I dont understand how, and I havent been able to find anything on Google.
Edit: Im running this in VS2010, and I just noticed that the tab has [from metadata] in the title. Perhaps this is why?

That's not code.
That's text that looks somewhat like code based on the metadata in the assembly. You'll see this when the IDE doesn't have access to the source code in question (For example, you press F12 on a method in a referenced assembly.) It provides the method signatures, properties, fields, etc from the types, without providing any of the actual implementation.
As written, the code you posted wouldn't even compile in C#.

If from the metadata, it's not going to show you the implementation of the methods.

It looks like code but it is text based on the metadata in the assembly. It means that the IDE is unable to access the source code in question.

Related

Does C# generate separate methods when you use a Generic Parameter with constraints?

I want to implement a WPF function that can raise events on a wide variety of things - from Hyperlinks to Buttons. Both a hyperlink and a button are DependencyObjects that implement IInputElement.
I wrote this function:
private void DoStuff<T>(T element, RoutedEvent anEvent) where T : DependencyObject, IInputElement
{
element.RaiseEvent(anEvent);
}
This works great, but made me wonder if my code would generate a new method for labels, buttons, contentcontrols, hyperlinks, and anything else that I passed into it? Do you know? It seems like that would be a waste of resources in this case because my method does the same thing to all of them.
I found lots of helpful references on how to constrain generic methods, but not much on code generation. I believe C++ does generate entire new classes when using generics, but wasn't sure about C#.
The method definition is compiled in MSIL only once. You can verify the claim by dumping the IL, indeed, this is the designed behaviour because you describe what you want: a method with placeholders.
However, at runtime, things get more difficult: the JIT compiler will emit as many copies as necessary of your generic each time with different object size.
Keep in mind that these are implementation details and are subject to change across versions.
In particular, reference types share the same method as they inner runtime class is the same, while each value types get their own method.
The link posted in the comments, for example, gives you an insight of the process.

compiling a method as if it was part of another class

Im looking for something that can compile a method as if it was in a different class so that i can Inject a method that uses internal fields and types without having to manually change the Operand values.
For instance if we need to get a value for debugging:
class bla{
internal string importantValue;
...
public void onInitialize(){
...
//this is where the compiler should be made to think it is
}
}
and the code that goes into the compiler
public void onInitialize(){ //code to be compiled as if it were in that method
File.WriteAllText("usefulString.txt",importantValue.toString());
}
and then we can get the il of the compiled output and insert it into bla.onInitialize so that we now can get our value
With the example given, making onInitialize() protected, then constructing an override in another class would work.
Alternatively make the body of the method a delegate defined at class level - then set a different delegate in your code to make it do something else.
I really don't get what you want to achive and I think there is a simpler way.
But if I understand from your question title, you want to compile your class bla (for example) and you want that in method onInitialize will be added new code (that doesn't exit there) in compile time. It it true?
For this you have a several ways. I'll describe two of them.
You can use library like StaticProxy.Fody. This lib let you intercept method and inject into it whatever you want. So in your example, you intercept onInitialize method and you add to it this code File.WriteAllText("usefulString.txt",importantValue.toString());
All of this in compile time. After you compile the code your ouput dll will contain this injected code.
Second option is to compile your code regulary and after that you can use Mono.Cecil to read your compiled dll and write code that will add whatever you want to where you want, (in our example, add File.WriteAllText etc. to onInitialize) after you save this dll it will contain the new injected code.
Both of the options are simple way to add code in static manner (aka compile time and not runtime).

What does the syntax seen when decompiling c# dynamic operations actually mean?

I've recently had to make a forray into decompiling a colleague's code while they're away, and found that most of it looks surprisingly nice (thanks ILSpy), with the notable exception of a couple of places where we needed to use dynamic - these got mangled into several parts:
A call site container - i.e. what resembles a class in definition, but let's say the method in which dynamic was used was DoStuff, would have a declaration along the lines of public /* static? I forget */ class <DoStuff>CallSiteContainer_Plus_Some_Weirdness { /* bunch of CallSite fields */ }
A lot of code that checks whether various CallSites within the container have been assigned and assigns them before usage as required using approaches I really don't get yet.
My question is regarding the syntax of the class declaration in the 1st point. It looks like a generic class, but it clearly isn't. Can anyone explain what's going on there?
Please note, I'm not looking for help in working out the original code - I've already managed to do that by judicious use of find and replace, and breaking out the autogenerated code from everything else. But I'd like to understand how the CallSite container syntax is a valid class name!
Here's an example of such auto-generated class:
private static class <>o__0
{
public static CallSite<Action<CallSite, Type, object>> <>p__0;
}
If you are worried about the <>o__0 class name and the <>p__0 field name, then you are right, those are not valid C# names but this doesn't mean that they are not valid IL names which is what the compiler generates. The reason why it uses such special symbols is to ensure that they will never conflict with class names that you as a developer might have written.

How can I declare a method then define it later?

In C# is there a way to declare the class then define it later? I really like in C++ where I can list all the methods at the top like a TOC then define everything later.
Can that be done is C#?
I have used the idea of defining a method that just runs a similarly named method in it then the similar method is at the bottom. but I am thinking there is a better way and googling returns a bunch of basic code on creating classes with no answer.
so here is what I do...
...
public void methodA(){methodAcontent()};
public void methodB()...etc...
...further down...
private void methodAcontent(){
...All the code..
}
is there a better way?
this like Interface http://msdn.microsoft.com/en-us/library/87d83y5b.aspx
Or this an Abstract class with abstract methods.
There's not a good way to do this in the C# language, but the Visual Studio IDE can collapse a file to its definitions which you can then expand individually (see this). This along with code regions helps me organize longer files.
Why would you need that?
C# is using multipass compilation, so it doesn't matter where the function is defined and when used. You can have function defined at end of the class and use it in the beginning and it will still compile fine.
Also IDE helps you with that. You have ability to collapse bodies of all methods, there is list of all methods in one combobox and InteliSense is extremly helpful in finding correct methods.
And using practices from C++ in C# is really bad idea, because both are quite different in how they solve the problems.
If you're doing this as a means to "document" the public interface to a class that's properly encapsulating a concept or object in your problem domain, then use an interface.
If you're doing it as a means to get an "overview" the structure of a class, then Visual Studio has several ways to give you this. You can collapse the code to just its definitions (Ctrl+M, O), or look at the Class View (Ctrl+W, C).

Concrete Implementation of Generic Form Not Working in Designer

I have a base class, defined as below (I'm also using DevExpress components):
public abstract partial class BaseFormClass<R> : XtraForm where R : DataRow
{
...
}
Contrary to what I've read from elsewhere, I'm still able to design this class. I didn't have to create a concrete class from it to do so. But, when I create a concrete class descended from it (as below), that class won't work in the designer.
public partial class ConcreteFormClass : BaseFormClass<StronglyTypedRow>
{
...
}
I get this message:
The designer could not be shown for
this file because none of the classes
within it can be designed. The
designer inspected the following
classes in the file:
ConcreteFormClass --- The base
class
'BaseFormClass'
could not be loaded. Ensure the
assembly has been referenced and that
all projects have been built.
Has anyone seen this before? Any sort of known workaround?
Sorry, but this just isn't going to work (which is a shame -- I've wished in the past that you could do this, too.) The problem is the basic methodology of the designer.
To present you with a model of your form, it doesn't actually try to construct the form itself; if it did that, you'd run into other problems -- what if your form doesn't have a parameterless constructor? Instead, it actually instantiates an instance of the base class of your form. Then it sweeps through your InitializeComponents() method and "layers on" all the controls that you've defined there onto the base form.
So it's obvious why this won't work. You can design an instance of BaseFormClass, because to design that, it creates an instance of XtraForm, which is concrete. But you can't design an instance of ConcreteFormClass, because to do so, it would need to create an instance of BaseFormClass, which is abstract.
The easiest workaround for this is to just make BaseFormClass non-abstract. (If you want to make absolutely sure nobody can create one, perhaps you could make the default constructor private? I'm not sure if the designer can handle that, but I don't see why it couldn't.) Sucks, but such is life. Complain to Microsoft and maybe it'll be better in Visual Studio 2012.
This sounds like a really similar issue to getting the designer to render forms that have an abstract base class. I haven't done any generic multi inheritance but you could at least try my approach and see if it works.
Edit: Yep, ok, just tried it, my solution works for sure. You just have to modify the middle classes definition and the forms definition (wrapped in the #if DEBUG)
Let me know if you're able to try it!

Categories

Resources