I have a class C which is derived from a generic class D. I referenced the class C in a XAML file. When I build the app, I get the following error:
The tag 'C' does not exist in XML namespace 'clr-namespace:A.B'
I don't understand is this due to C is derived from a generic class. If I remove the base class, it does not give me any error.
How can I get rid of the error? The IInterfaceForE is injected via Unity, so the app works fine. But I can't get rid of the build error.
Code snippet:
namespace A.B
{
public class C : D<InterfaceForE>
{
public C()
{
}
}
}
// Reference in XAML
xmlns:myns="clr-namespace:A.B"
<myns:C x:Key="KeyForC"/>
// Code snippet after commenting out the base class.
// When I build with this code, there is no build error, but the app wont run.
namespace A.B
{
public class C //: D<InterfaceForE>
{
public C()
{
}
}
}
I had to remove the generic being used to make this work.
Related
I am new to dotnetcore so please be patient...
this ASP controller method works if I give back a list of Strings.
[HttpGet]
public List<Contract> Get()
{
return getContracts();
}
meanwhile every thing is public...it's just later where I see the error
If I return a list of very simple objects I get the warning
Inconsistent accessibility: return type 'type' is less accessible than method 'method'
the documentation for that error only shows an example for that. But how to fix it ?
Also thanks for any Link/Hint to understand the issue/rules here !
If your class is defined as:
class Contract
{
}
Then you will get the error because a class is internal by default.
A public method on a public class can't return internal types.
So we make the class public:
public class Contract
{
}
I built a WinRT(Windows phone 8.1) dll with Page.xaml and App.xaml files.
Next, I add reference to this winmd in wp8.1 application project.
And I get following error:
error APPX1706: The .winmd file 'project.winmd' contains type
'?A0x32772d97.project_XamlTypeInfo.XamlMetaDataProvider' outside its root namespace
'project'. Make sure that all public types appear under a common root namespace
that matches the output file name.
A WinMD library is basically a regular library (DLL) with some metadata information. These metadata information will allow it to be used from different languages. You can for example, create a WinMD library in C# and use it from a C++ or JS application.
Since the WinMD Library can be used by different languages, they are all conforming to the Windows Runtime rules.
Your specific problem is that one of the rules for the WinMD files states that all the classes must belong to the same root namespace.
It means that if you have the following code:
A.cs
namespace Foo { class A { ... } }
B.cs
namespace Foo.Sub { class B { ... } }
C.cs
namespace Bar { class C { ... } }
D.cs
namespace Bar.Sub { class D { ... } }
The WinMD linker will return the error you are seeing.
To solve it, you will have to declare all your classes in the same root namespace :
A.cs
namespace Foo { class A { ... } }
B.cs
namespace Foo.Sub { class B { ... } }
C.cs
namespace Foo { class C { ... } }
D.cs
namespace Foo.Sub { class D { ... } }
I've replaced all the "Bar" namespace by "Foo"
I am getting error code C2512 which is no appropriate default constructor available. However it appears to me that everything should be working so I am a bit confused on how to get this to compile.
Here is the header file code:
namespace MyNamespace
{
ref class ForwadDeclaredClass;
public ref class MyClass
{
public:
MyClass();
// ...
private:
ForwadDeclaredClass^ fc;
}
}
Now in my cpp file I define the forwarded class and try to use it in the constructor for MyClass.
using namespace MyNamespace;
//...
public ref class ForwardDeclaredClass
{
public:
ForwardDeclaredClass()
{
}
}
MyClass::MyClass()
{
// Compiler complains with error code here
fc = gcnew ForwardDeclaredClass();
}
I know I have to be missing something simple but I am just not seeing it. Any help would be appreciated.
At first glance, it looks like your namespaces are off.
In the header file, you're declaring ForwardDeclaredClass and MyClass inside MyNamespace.
In the cpp file, you're using MyNamespace, but the code you're writing isn't inside the namespace.
It looks like you need to enclose most of the contents of the cpp file in a namespace MyNamespace { block.
I have a class that looks like this:
public class MyClass {
private class MyInnerClass {
public void someFunc() { }
}
public void usefulMethod() {
... some stuff...
nativeUsefulMethod();
}
private native void nativeUsefulMethod();
}
I need to keep the method names of all native functions, as well as the classes containing them, in order for the native code to work properly. Seems like no problem:
-keepnames class * {
native <methods>;
}
When I look at the resulting jar, I see that MyClass and nativeUsefulMethod() remain, while usefulMethod() has been obfuscated. Good. However, the inner class is still named "MyClass$MyInnerClass". It contains no native methods, so I would expect it to be called "MyClass$a" or just "a".
I tested changing "-keepnames" to "-keepclassmembernames", and the class names of both get obfuscated. It's definitely this directive that's keeping the inner class name. Is there a way to obfuscate the outer, but not the inner class name?
The proper configuration for native methods is:
-keepclasseswithmembernames class * {
native <methods>;
}
See the ProGuard manual > Examples > Processing native methods
I'm trying to make a Script# import library to wrap (parts of) the dojo toolkit--especially the dijit widgets. Unfortunately, dojo uses multiple inheritance, and C# doesn't support that (except for interfaces, which Script# doesn't handle properly--see below).
I'm trying to accomplish something like this:
[Imported]
public class A
{
public void Foo() {}
}
[Imported]
public class B
{
public void Bar() {}
}
[Imported]
public class C : A, B
{
public void Sproing() {}
}
but obviously that's not valid C#, and therefore isn't valid Script#.
Is there a way in Script# to accommodate multiple inheritance of [Imported] classes? I tried using interfaces, since C# supports multiple inheritance of them and I'm not providing implementations anyway:
[Imported]
public interface A
{
void Foo();
}
[Imported]
public interface B
{
void Bar();
}
[Imported]
public interface C : A, B
{
void Sproing();
}
however, when I try to use the library from another Script# project, code such as C c = null; c.Foo(); I just get a "Check that your C# source compiles and that you are not using an unsupported feature. Common things to check for include use of fully-qualified names (use a using statement to import namespaces instead) or accessing private members of a type from a static member of the same type." error on the c.Foo() call.
Any other ideas? The [Mixin] attribute doesn't appear to do what I need either.
The only other option I see at the moment (aside from fixing the interfaces problem in Script#, which I'm not prepared to do) is to ditch inheritance altogether and put all the
"inherited" members in each leaf class. That would look something like this:
[Imported]
public class A
{
public void Foo() {}
}
[Imported]
public class B
{
public void Bar() {}
}
[Imported]
public class C
{
public void Foo() {}
public void Bar() {}
public void Sproing() {}
}
Obviously that would get ugly fast, but I could automate it. Since JavaScript's type system is pretty fast-and-loose anyway, this might even work OK there. And in Script# land, consumers of the import library would simply need to do more explicit casts than they should need to do. Are there other disadvantages that I'm overlooking?
Interface inheritance isn't currently supported. It will be fixed in a future rev.
You could define:
interface A {
}
interface B {
}
class C : A, B {
}
It does mean you'll end up having to define all members, even if stubs in C.
I haven't looked at Dojo in any depth, but potentially a better strategy will be to have a base class with methods shared across many of the widgets, and then derived widget types for each individual widget type. That would be something similar to the jQueryUI stuff that is in the script# repository.