In my Xamarin.iOS binding project's, I have following interface defined in my ApiDefinition.cs
[BaseType(typeof(LSMAHandler))]
[Protocol, Model]
interface LSMAHandlerRegister
It has generated LSMAHandlerRegister.g.cs in my project/obj/Debug/ios/project. This file contains followings
public interface ILSMAHandlerRegister : INativeObject,
IDisposable,SightCallBinding.ILSMAHandler
internal sealed class LSMAHandlerRegisterWrapper : BaseWrapper,
ILSMAHandlerRegister
public unsafe abstract partial class LSMAHandlerRegister :
LSMAHandler, ILSMAHandlerRegister
I have added the generated DLL to my xamarin.ios project. Now I want to call RegisterWithURL method in above class. But the implementation of that method only available in internal wrapper class. How can I call to this method within my Xamarin.iOS project?
Simple anwser - you can't. Internal classes are not visible in dll.
There are some things you can do though.
First of all think why this class is internal. There may be an important reason for this. The things you can do (you have to have access to this project)
make class and interfaces public (maybe there is no reason for it to be internal)
use InternalsVisibleTo https://learn.microsoft.com/pl-pl/dotnet/api/system.runtime.compilerservices.internalsvisibletoattribute?view=netframework-4.8 - note however, that this is considered a bad practice and should not be done. One exception is test project. You can show internals to test project. That maybe sometimes ok.
create other public class that make use of this internal one, for example:
public class MyPublicHelper
{
public void CallMyInternalMethod()
{
MyInternalClass obj = new MyInternalClass();
obj.MyInternalMethod();
}
}
Related
I have a public Library class with all the global variables needed for my program to work. It is structured like this:
public static class Library
{
public static string globalString = "";
}
In other languages, it is possible to use extends to extend a class to another class so the 'Library' prefix is not required on global variables but in C# it works a bit differently. I tried adding it after the colon in the class I wanted to extend to (like this: public partial class Login : Form, Library) and I was told that "Classes cannot have multiple base classes". Apparently, it is possible to use interfaces to extend classes but I do not fully understand how that works or how to implement it.
If you're using one of the newer versions of C#, you can import a static class so that you use its members without fully qualifying their names. In C#, the syntax would be...
using static RootNamespace.Library;
// Provided the class Library is in a namespace called RootNamespace
The above line would be placed at the top of your code file, in this case I'm assuming it's in Login.cs. This will be among the other using statements like using System; and you will be able to use the public static members of Library inside your Login class.
I would recommend using something other than global variables though, such as properties so that you can encapsulate some logic and protect against invalid states by running some validation before these values are changed.
I am working on a class Library and I'm having troubles with accessibility. My class library contains several internal classes which shouldn't be accessed from other applications. Instead I want to create a Singleton Main Class that contains Instances of all the internal classes, so other applications can access the Main class and then use the internal classes from that instance. The picture below explains the hierarchy.
I've tried making the Main Class public and the Internal Classes internal, however this gives me the error Error "Inconsistent accessibility". My Main Class looks like this:
public class Main
{
private static Main Instance;
public static Main GetInstance()
{
if (Instance == null)
Instance = new Main();
return Instance;
}
public Debugging Debugger = new Debugging();
}
And one of my Internal Classes (Debugging) looks like this:
internal class Debugging
{
Content....
}
So I'm hoping that someone can help me to figure out how to make the Internal Classes only accessible through my singleton Main Class.
I'm not positive from your question what your intent is so I'll break it into two options:
You want `Debugging` accessible to external assemblies, but only via `Main`
There are a few ways how to do this, but the simplest right now for you would be to keep Debugging public, but define only internal constructors. This will allow its usage but external assemblies won't be able to instantiate them, thus forcing them to access the instance created on Main
public class Debugging
{
internal Debugging() { }
}
You don't want `Debugging` accessible to external assemblies, and but still accessible within your class assembly via `Main`
Simply update the accessibility modifier for Main.Debugger to be internal
internal Debugging Debugger = new Debugging();
You have to set all of you class public if you have some public access to them (via the Main class).
Otherwise you can set the internal class as internal and provide a set of properties in the Main class (that wrap internal classes' fields/methods) in order to access their field/methods. You can set the constructors of internal class as internal in order to avoid those class instantiations.
In general: Every field/method exposed from a public class should have a public return type.
Some MSDN reference
If you need to access the Debugger class outside the Library you need to change the access modeifier to public. As suggested make the constructor as internal so no one outside the assembly can create an instance of those classes.
In VS 2010 I'm creating a service reference which code generates the WCF client proxy class Refernce.cs. I need the methods in this class to have the Virtual modifier so they can be used in Mock.
Of course I can hand edit the generated code, but every time I update the reference the code is going to be regenerated and wipe out my changes.
Do I have more control of how the WCF client proxy class is generated? Is there any way to have the code generator always add the Virtual modifier? I would like this to be more automated so that when other developers need to update the reference, they don't have to know or remember to hand edit the generated code and add the the virtual modifier.
An alternative is to create an interface. The proxy classes are generated as partial, which means you can create another partial file for that class, and specify that the class implements your interface, even though the actual implementation is in the generated class. You can then mock the interface, and regenerate your proxy to your hearts content.
For instance, your generated class might be:
public partial class SomeService
{
public string GetSomething()
{
return ...
}
}
You can create an interface for this:
public interface ISomeService
{
string GetSomething();
}
And then add an empty partial file for the generated class:
public partial class SomeService : ISomeService
{
}
This is a question for the .NET philosophers:
It is my understanding that Microsoft consciously denied use of private classes in C#. Why did they do this and what are their arguments for doing so?
I, for example, am building a large application that includes a reporting tool. This tool uses a lot of business objects that are used only within the reporting tool and not in other parts of the project. I want to encapsulate them for use only within the reporting tool itself.
Great decision is creating separate project in VS for this tool, and I'll do like that, but I'm interesting, what if I can't do this - for exmple our architecture wasn`t good enough, and we have big single project.
Behind "private class" I mean a class that can't be used in any other namespace, except its own.
My question was not - how can I simulate this, or do in another way. I'm just wondering, why not use private keyword with class keyword without any parent classes. I`m thinking there should be some reason, and I want to know it
Allowing classes to be private to a namespace would achieve no meaningful level of protection.
Any assembly in the world could simply reference your dll, and start writing code in your namespace which accesses your supposedly private classes.
I think that's possibly the answer you'd get from Microsoft.
There's a workaround for this, but you might not like it.
Instead of using a namespace to scope your classes, use a public static partial class:
Before:
namespace MyCompany.Foo {
class Bar { }
public class Baz { }
}
After:
namespace MyCompany {
public static partial class Foo {
private class Bar { }
public class Baz { }
}
}
This construct, like a namespace, can span multiple files in the same project. But unlike a namespace, it cannot "escape" from your project (other projects cannot define other members inside Foo).
There's an added advantage that you can have utility methods that seem to have no class for code inside Foo.
The disadvantage is that, to use your non-private classes outside of your fake namespace, you have to reference them inside Foo:
using MyCompany;
// ...
var baz = new Foo.Baz();
This can be mitigated by using an alias for the class:
using Baz = MyCompany.Foo.Baz;
// ...
var baz = new Baz();
But you'd have to do it for each non-private class that you want to use.
UPDATE
It's interesting to note that C# 6 will have static using statements, which could effectively improve this proposal to use a public static partial class as a "module". You would just "use" the "module" to access its types directly.
Hopefully, it will work like this:
using MyCompany.Foo;
// ...
var baz = new Baz();
Just as if Foo was a namespace.
You can create a private class, as a member of another type:
public class Outer {
// ...
private class Inner {
// ...
}
}
and Inner is only visible to members of Outer.
At the outermost level (i.e. in a namespace) private as per its definition would not make sense (since there is nothing to be private in). Instead use internal (visible to the containing assembly's members only).
You can define a private class, but it can only be used by its containing class.
If you want a class that is only visible within a particular assembly (DLL/EXE/etc.), then you should declare it as internal (Friend in VB)
True but you can get a pretty close simulation of this with internal classes and the internalsvisibletoAttribute if the namespace is split across multiple assemblies.
Also remember that a class within another can be private to the outer class. The outer class can be considered a namespace for this purpose.
So I guess you want to do this
namespace Baz
{
private class foo
{
private int _bar;
}
}
If yes. Then what is the purpose foo will server. At namespace can you be more restrictive than internal , and make any use of the class.If I could do this where will I use this .
That is why you have this compile time validation.
Now Inside a Public Class it makes sense to have a private class. I cannot explain it better this Private inner classes in C# - why aren't they used more often?.
I want to simulate derivation from a base class (which is unaccessible) using just an interface and an instance of the base class (as opposed to just deriving directly from the base class).
Let me try to explain better: I have an exposed interface and a (hidden) class implementation for it.
In another module, I create a 2nd implementation of the interface and pass it an instance of the hidden class from the first module.
What I want the 2nd implementation to do:
it delegates the interface methods to the default implementation
it can override any interface method
it can be derived from
[the tricky part] code from the default implementation that calls virtual methods will call the overridden methods of this class or classes derived from it.
Remember, I can't derive from the default implementation directly!
The best way to describe it is an example.
Assembly A:
internal class DefaultImpl: IMyInterface {
public virtual void MyMethod(){
//call a virtual method vvvv
Console.WriteLine(this.GetString());
}
public virtual string GetString(){
return "default implementation";
}
}
public Interface IMyInterface {
void MyMethod();
string GetString();
}
------
Assembly B:
class BaseExtraImpl: IMyInterface {
public BaseExtraImpl(IMyInterface i_implementation){
/* magic happens here */
}
public virtual void MyMethod(){ /*delegate to implementation*/ }
public virtual string GetString(){ /*delegate to implementation*/ }
}
class ExtraImpl: BaseExtraImpl{
public ExtraImpl(IMyInterface i_implementation): base(implementation) {}
public override string GetString(){
return "extra implementation";
}
}
Usage:
DefaultImpl def;
// ^^^ this is initialized to an instance of DefaultImpl;
// it doesn't matter how.
ExtraImpl extra = new ExtraImpl(def);
extra.MyMethod(); //should print "extra implementation"
What you need is mixin possibilities in c#. Unfortunately c# doesn't have those. May be you can find an answer here: Is it possible to implement mixins in C#?
Humm, this will always output "default implementation". The only option I see is to implement your own version of IMyInterface maybe copying the code from DefaultImpl (if you are allowed) but this was really what you where avoiding to do, I think.
You could see this previous post How To Access Internal Class from External Assembly.
However, the gist of it is that you can either apply the "InternalsVisibleTo" assembly attribute to Assembly A so that Assembly B can view and access the Default implementation but this only works if you have control of both assembly's source code. Otherwise you need to use reflection to create an instance of the Default in Assembly B and then in your methods call the methods on the reflected object.