The problem I'm facing might be stupid, but I've never encountered it, so I guess I need some help. I'm learning how to use a Debug Visualizer.
I've created one: DebuggerSide.cs located in CarGarageVisualizer namespace.
I wanted the type of CarGarage<T> to be seen in this visualizer when debugging instance of this, so I've put following attributes to the class:
[DebuggerVisualizer(typeof(CarGarageVisualizer.DebuggerSide))]
[Serializable]
public class CarGarage<T>:IEnumerable<T>
where T : Car,new()
{
...
}
Now, to add first attribute I needed to add reference to CarGarageVisualizer that contains the DebuggerSide class. That's OK. But now, in my DebuggerSide's overriden method Show() I wanted to explicitly cast object gained from the objectProvider argument to the type of CarGarage<T>. But to be able to do this I would need to reference the CarGarageLibrary that contains the definition of this. And as I said I can't do that, because I get the error about recursive reference.
From other post on this subject, I know it's a bad practice. But, I don't want to copy the CarGarage<T> class to my Visualizer namespace (that would solve the problem, but I'm not sure if it's the right thing to do) unless there's not a better option.
Can anybody help me with this?
You should put the CarGarageVisualizer.DebuggerSide in a separate library that will and can be referenced by both.
Didn't get it correctly, I think.
What about, putting the CarGarage<T> in a separate library.
library CarGarage:
[Serializable]
public class CarGarage<T>:IEnumerable<T>
where T : Car,new()
{
...
}
library DebugVis: (uses CarGarage)
DebuggerSide....
library app: (uses CarGarage)
[DebuggerVisualizer(typeof(CarGarageVisualizer.DebuggerSide))]
public class CarGarageImpl<T> : CarGarage<T> { }
You can use the DebuggerVisualizerAttribute constructor overload that takes string containing the fully qualified type name of the visualizer like this
public static class MyVisualizers
{
public const string AssemblyRef = #"MyVisualizers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null";
}
[DebuggerVisualizer("MyVisualizersNamespace.CarGarageVisualizer+DebuggerSide, " + MyVisualizers.AssemblyRef)]
[Serializable]
public class CarGarage<T>:IEnumerable<T>
where T : Car,new()
{
...
}
Related
I want to know if there is any way to limit usage of custom attribute to the specific class.
I read about it and somebody wrote that it's probably impossible in C#. But I have just tried to use AttributeUsage attribute on a class that doesn't derrive from Attribute and Visual Studio has thrown a following error:
Attribute 'AttributeUsage' is only valid on classes derived from System.Attribute
So now I think that there is a pretty smart way to make it. Have you any ideas?
The only way I can think of is by making the attribute class an inner class of the target. I have a hard time coming up with a legitimate reason to use this though.
This will compile:
[InnerAttribute]
public class A
{
private class InnerAttribute : Attribute
{
}
}
But adding this won't:
[InnerAttribute]
public class B
{
}
I'm organizing a library project and I have a central manager class named Scenegraph and a whole bunch of other classes that live in the Scenegraph namespace.
What I'd really like is for the scenegraph to be MyLib.Scenegraph and the other classes to be MyLib.Scenegraph.*, but it seems the only way to do that would be to make all the other classes inner classes of Scenegraph in the Scenegraph.cs file and that's just too unwieldy.
Instead, I've organized it as Mylib.Scenegraph.Scenegraph and MyLib.Scenegraph.*, which sort of works but I find Visual Studio gets confused under some conditions as to whether I am referring to the class or the namespace.
Is there a good way to organize this package so it's convenient for users without glomming all my code together in an unmaintainable mess?
I don't recommend you to name a class like its namespace, see this article.
The Framework Design Guidelines say in section 3.4 “do not use the
same name for a namespace and a type in that namespace”. That is:
namespace MyContainers.List
{
public class List { … }
}
Why is this badness? Oh, let me count the ways.
You can get yourself into situations where you think you are referring
to one thing but in fact are referring to something else. Suppose you
end up in this unfortunate situation: you are writing Blah.DLL and
importing Foo.DLL and Bar.DLL, which, unfortunately, both have a type
called Foo:
// Foo.DLL:
namespace Foo { public class Foo { } }
// Bar.DLL:
namespace Bar { public class Foo { } }
// Blah.DLL:
namespace Blah
{
using Foo;
using Bar;
class C { Foo foo; }
}
The compiler gives an error. “Foo” is ambiguous between Foo.Foo and
Bar.Foo. Bummer. I guess I’ll fix that by fully qualifying the name:
class C { Foo.Foo foo; }
This now gives the ambiguity error “Foo in
Foo.Foo is ambiguous between Foo.Foo and Bar.Foo”. We still don’t know
what the first Foo refers to, and until we can figure that out, we
don’t even bother to try to figure out what the second one refers to.
Giving the same name to the namespace and the class can confuse the compiler as others have said.
How to name it then?
If the namespace has multiple classes then find a name that defines all those classes.
If the namespace has just one class (and hence the temptation to give it the same name) name the namespace ClassNameNS. This is how Microsoft names their namespaces at least.
Even though I agree with other answers in that you should not name your class the same as your namespace there are times in which you cannot comply with such requirements.
In my case for example I was not the person making such a decision therefore I needed to find a way to make it work.
So for those who cannot change namespace name nor class name here is a way in which you can make your code work.
// Foo.DLL:
namespace Foo { public class Foo { } }
// Bar.DLL:
namespace Bar { public class Foo { } }
// Blah.DLL:
namespace Blah
{
using FooNSAlias = Foo;//alias
using BarNSAlias = Bar;//alias
class C { FooNSAlias.Foo foo; }//use alias to fully qualify class name
}
Basically I created namespace "aliases" and that allowed me to fully qualify the class and the Visual Studio "confusion" went away.
NOTE:
You should avoid this naming conflict if it is under your control to do so.
You should only use the mentioned technique when you are not in control of the classes and namespaces in question.
I would suggest that you follow the advice I got on microsoft.public.dotnet.languages.csharp to use MyLib.ScenegraphUtil.Scenegraph and MyLib.ScenegraphUtil.*.
As others have said, it's a good practice to avoid naming a class the same as its namespace.
Here are some additional naming suggestions from an answer by svick to a related question "Same class and namespace name" on the Software Engineering Stack Exchange:
You're right that you shouldn't name the namespace the same as a type
it contains. I think there are several approaches you can use:
Pluralize: Model.DataSources.DataSource
This works especially well if the primary purpose of the namespace is
to contain types that inherit from the same base type or implement the
same interface.
Shorten: Model.QueryStorage
If a namespace contains only a small number of types, maybe you don't
need that namespace at all.
Make enterprisey: Model.ProjectSystem.Project
This can work especially for features that are important part of your
product, so they deserve their own name.
It happens when it's the main class of the namespace. So it's one motivation to put the namespace in a library, then the issue goes away if you add 'Lib' to the namespace name...
namespace SocketLib
{
class Socket
{
CA1724: Type Names Should Not Match Namespaces ...
Basically, if you follow Code Analysis for proper coding this rule says to not do what you are trying to do. Code Analysis is very useful in helping you find potential issues.
Old post, but here I go with another idea that may help someone:
"...but it seems the only way to do that would be to make all the other classes inner classes of Scenegraph in the Scenegraph.cs file and that's just too unwieldy."
This is really the better implementation for a bunch of scenarios. But, I do agree that having all that code on the same .cs file is annoying (to say the least).
You could solve it by making the base class a "partial class" and then, go on creating the inner classes on their own files (just remember that they'll have to declare the base class complement and then go on with the specific inner class for that file).
Something like...
Scenegraph.cs:
namespace MyLib
{
public partial class Scenegraph
{
//Scenegraph specific implementations
}
}
DependentClass.cs:
namespace MyLib
{
public partial class Scenegraph
{
public class DependentClass
{
//DependentClass specific implementations
}
}
}
I do think that this is the closer that you can get to having the clean implementation of inner classes while not having to clutter everything inside one huge and messy file.
Just Adding my 2 cents:
I had the following class:
namespace Foo {
public struct Bar {
}
public class Foo {
//no method or member named "Bar"
}
}
The client was written like this:
using Foo;
public class Blah {
public void GetFoo( out Foo.Bar[] barArray ) {
}
}
Forgiving the error GetFoo not returning the output instead of using the out parameter, the compiler could not resolve the data type Foo.Bar[] . It was returning the error: could not find type or namespace Foo.Bar .
It appears that when it tries to compile it resolved Foo as the class and did not find an embedded class Bar in the class Foo. It also could not find a namespace called Foo.Bar . It failed to look for a class Bar in the namespace Foo. The dots in a name space are NOT syntactic. The whole string is a token, not the words delimited by the dots.
This behaviour was exhibited by VS 2015 running .Net 4.6
I have a lot of static methods in a class, I want to get if a certain method is in the class X, and if it is, I want to invoke it. I checked with this:
if (Type.GetType("Homework.Homework.Functions").GetMethod(methodName) == null)
{
Console.WriteLine("No such method.\nPress any key to restart the program");
Console.ReadKey();
Console.Clear();
Main();
return;
}
else
Type.GetType("Homework.Homework.Functions").GetMethod(methodName).Invoke(null, parametersArray); // Invoking the method.
But it gives me a System.NullReferenceException in the line with the if() in it.
The starting of the program:
namespace Homework
{
class Homework
{
static void Main()
{
Declaration of the class:
public class Functions
{
I probably should say that the class Functions is inside the class Homework.
How do I solve this error?
Thanks.
The problem is that nested types are separated with a + rather than a . in the IL name. If you write:
Console.WriteLine(typeof(global::Homework.Homework.Functions));
then you'll see the fully qualified name as far as the CLR is concerned.
So you want:
Type.GetType("Homework.Homework+Functions")
Assuming you really need to get it by name - avoid this sort of thing where possible. Use typeof wherever you know the type at compile-time (and are happy to have a reference if it's in a different assembly).
That will work if you're calling it from within the same assembly. If you're calling Type.GetType from a different assembly, you'll need to qualify the name with the assembly as well.
I'd also strongly encourage you not to name a class the same as its namespace.
You need to specify an assembly qualified name to GetType(string). Instantiate your Homework class and look at its
GetType().FullName
I tried to code my own serialization dll. The code itself works as expected. Now I want to put the entire code into a dll file.
My problem is the following: how do I tell the dll WHICH class it should serialize?
Example:
public class serialize
{
public static void doSerialization(class serializableClass, string path, string fileName)
{
do code here...
}
}
Ok. I used class serializableClass, you know? Type + Name. Sure It won't work like this. I was afraid it wouldn't. But how do I do it, though? I want the dll to serialize the class settings.cs which is in my main program... I hope the question is clear. Otherwise just ask ;)
Thanks for Your help.
Best Regards.
You need to pass object of class not class it self. Assuming serializableClass is a class. Although the library (dll) does not know your class serializableClass. You can make library of common classes and add reference of that library in main program and library for serialization.
public class serialize
{
public static void doSerialization(serializableClass objSerializableClass , string path, string fileName)
{
do code here...
}
}
I used the OWLGrinder to create the assembly and imported the library into my project. That works fine. Now I want to write my own set of classes. Therefore I extended these with the equivalent of the assembly. But it just doesn't work.
The ontology holds a class named ManagementObject.
I created another Class (C#) called RealWorldObject:
public class RealWorldObject : ManagementObject
{
public RealWorldObject(string uri) : base(uri) { }
public RealWorldObject(string uri, RdfDocument rdfdocument) : base(uri, rdfdocument) { }
public RealWorldObject(RdfDocument rdfdocument) : base(rdfdocument) { }
public String getClassName()
{
return this.OwlClassName;
}
public static RdfDocument addRealWorldObjectIndividualt(RdfDocument rdfDocument)
{
Vehicle vehicle = new Vehicle("vehicle1", rdfDocument);
FixedEvent fxE1 = new FixedEvent("autoGekauft", rdfDocument);
fxE1.agent = new xmlns.com.foaf._01.Person("robert", rdfDocument);
vehicle.hasFixedEvent = fxE1;
return rdfDocument;
}
Which leads to the error:
ObjectManagement.Object.RealWorldObject does declare one (and only one) OwlClassAttribute. This is an implementation bug of the plugin.
How else should I extend the generated classes by the OWLGrinder.
Thx it is a long time ago that I used C#, so I'm kind of rusty.
The auto-generated classes produced by OwlGrinder.exe have not been designed for inheritance in mind. I am not saying it is wrong, it is just not designed for that. The auto-generated classes contain plenty of metadata defined as class attributes and inheritance hides all of that. The infrastructure counts on the presence of these attributes and if they are hidden, you get these runtime error messages.
Using Visual Studio Object Browser, take a look of the attributes over the auto-generated classes. OwlClassAttribute, SubClassOfAttribute, LightVersionAttribute are certainly mandatory. You may simply copy/paste the class attributes of ManagementObject on the top of your RealWorldObject class. I assume, it will work. But again, you might bump into additional show stoppers, as you do not follow the default routes ROWLEX has been designed for. This is a bit living on the edge :)
Instead of inheritance, you might consider reverse engineering your auto-generated assembly to C# using Reflector or other tools. Having the source code in your hand, you may modify the generated classes directly. You might make your ManagementObject class partial, and implement your additional methods in a separate file.