|
|
Hi All
How can i use .net dll in vc++?I make dll in .net and want to use in vc++?
Please help me
|
|
|
|
|
| See this article[^]. txtspeak is the realm of 9 year old children, not developers. Christian Graus
|
|
|
|
|
Thanks for reply
Sorry i havn't got any think related to vc++ here?
|
|
|
|
|
MsmVc wrote: Sorry i havn't got any think related to vc++ here?
Well you just follow the article and work out how to use COM from C++ rather than VB; it's not that difficult. Alternatively you convert your C++ code to Managed C++ and use your .NET library directly. Those are the choices I'm afraid.txtspeak is the realm of 9 year old children, not developers. Christian Graus
|
|
|
|
|
Thanks once again.
I try to use Managed C++ and use your .NET library directly.First register dll and then /.tlb file.I use Common Language Runtime Support (/clr).
Now next step i stuck here.
CMyClass1^ c=gcnew CMyClass1();
Then i got error.
error C3699: '^' : cannot use this indirection on type 'CClass1' compiler replacing '^' with '*' to continue parsing
error C2726: 'gcnew' may only be used to create an object with managed type
Now what i do.Please help me
|
|
|
|
|
MsmVc wrote: I try to use Managed C++ and use your .NET library
I've never published any .NET libraries, are you sure this is not in response to some article? I don't have experience of managed C++ but the compiler message suggests:
CMyClass1 c = gcnew CMyClass1(); txtspeak is the realm of 9 year old children, not developers. Christian Graus
|
|
|
|
|
My project is a C++/CLI project that references a C# assembly. Every time I make a change in the C# assembly and build it, I get a message from the compiler, "Cannot inspect myCsharpDll.dll. Assuming significant changes...". The compiler then proceeds to rebuild the entire C++/CLI project too -- which is just excruciating since the main project is about 300 source code files in size.
I did some digging around and found a suggestion that this is could be caused if the ".dll.meta" file is not being generated for the referenced assembly. However, I have verified that the .dll.meta file for my C# assembly IS being created.
Can anyone shed some light on what project settings I need to get this nonsense to stop?
|
|
|
|
|
Update: The .dll.meta file is *NOT* being generated. Before I said it was, but I took a closer look at the file timestamps. It looks like a .meta file was created when I created the library project and has not been updated since. If I open it in a simple text editor, the contents only appear to be a string "No meta available".
How can I get my builds to populate that .dll.meta file with the most recent changes???
|
|
|
|
|
FYI... It looks like I resolved it by cleaning the solution and rebuilding everything. Now all my .dll.meta data file have metadata in them and I can't reproduce the problem when I make additional updates to the class library. Looks like a Visual Studio glitch.
|
|
|
|
|
In C++/CLI if I add an operator to an interface class and implement that interface in a ref class, the operator is not recognized for the ref class. But if I add an operator to a base ref class and inherit from that base ref class in a derived ref class, the operator is recognized for that derived ref class:
#include "stdafx.h"
using namespace System;
interface class Base
{
public:
static int operator * (Base ^ it) { return 3; }
};
ref class Derived : Base
{
};
int main(array<System::String ^> ^args)
{
Derived ^ d(gcnew Derived);
int amt = *d;
Console::WriteLine(L"Hello World");
return 0;
}
The above compiles with an error of:
error C2440: 'initializing' : cannot convert from 'Derived' to 'int'
No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called
But if one changes the line in the code above from 'interface class base' to 'ref class base', the code compiles and runs with no errors.
Does anybody know why this behavior occurs ?Edward Diener
|
|
|
|
|
Could it be because only a ref class can be assigned to a variable declared with the hat ^ operator?
|
|
|
|
|
| I do not understand the reasoning of your answer. What does the hat operator have to do with my OP ? Edward Diener
|
|
|
|
|
I'm not 100% sure about this, but this is what I meant above:
When you declare your variable d, you are declaring it as a reference to a managed object by virtue of the fact that you are declaring it thus:
Derived ^d;
When you declare a class without the ref keyword, it becomes a value class.
You cannot assign a value class to a ref variable.
If you want your Base class without the ref keyword, then you must declare d without the hat ^ operator, thus:
Derived d;
|
|
|
|
|
| A class without the 'ref' keyword in C++/CLI is a native C++ class. Nowhere in my OP did I create variable for the Derived class without the ^ symbol. Please look at my OP again. Edward Diener
|
|
|
|
|
You're right.
But this catches my eye:
Derived ^ d(gcnew Derived);
Change that line to:
Derived ^ d(gcnew Derived());
BTW, why don't you just say:
Derived ^ d = gcnew Derived();
|
|
|
|
|
| Totally irrelevant. They are all exactly the same. Edward Diener
|
|
|
|
|
Edward Diener wrote: Totally irrelevant. They are all exactly the same.
Irrelevant in CLI code, but in standard C++, new T and new T() are different for POD types. The latter version zeroes out the memory before calling the constructor, so if you haven’t initialized a member variable, it’s zero initialized by default.
|
|
|
|
|
Hey Edward,
I believe this is due to a compiler bug. I've just blogged about it here and have also referenced this thread :
C++/CLI bug : Operator overloading in an interface[^]
You can workaround it for now by directly calling the operator :
int amt = Base::operator * (d);
I've reported it to the VC++ team - and if they acknowledge that it is a bug and not by design, I'll open a Connect bug for it.
|
|
|
|
|
Interesting enough one can not even create an operator for an interface in C#. I have suggested to Microsoft that one should be allowed to create an operator for an interface in C# also. In fact in C# one can not create any static members for an interface.
You can view my suggestion at https://connect.microsoft.com/VisualStudio/feedback/details/536835/allow-operators-for-an-interface-in-c[^].
Thanks for reporting this to the VC++ team, especially since if I reported the bug myself Microsoft would have definitely issued "Will not fix" after admitting it is a bug whereas once somebody else reports it there is a faint chance that they will consider fixing it for the 2010 release or beyond.Edward Diener
|
|
|
|
|
Well considering that C# does not permit static methods in interfaces, it would be quite unlikely that they'd permit operator overloading which requires static methods. Some people were hopeful that since C# now supports extension methods, this would be enhanced to support extension operators but apparently that did not happen for VS 2010. Would have been neat. Oh well.
Btw, if you really need to overload the * unary operator, C# does not permit that either, so you'd either have to wait for C++/CLI to get fixed or code it in an msil assembly (assuming you need it that badly) 
|
|
|
|
|
Obviously C# should allow static data, methods, properties, and events in interfaces. But that is not my problem if I code in C++/CLI.
I could substitute another operator which C# does permit in place of the * unary operator. I am not worried about that. I am thinking of using an explicit cast operator for C# compatibility in areas where I would normally use the * unary operator while also keeping the * unary operator for C++/CLI programmers.Edward Diener
|
|
|
|
|
I saw that Wesley Yao has answered you in the MSDN thread. I am not 100% in agreement with the behavior though. Operators are implemented via static methods in .NET and thus for operators, name lookup should (in my opinion) be extended to look up all the way to the base interface (if any). Anyway we at least know now that it is not an official bug and is by design
|
|
|
|
|
Interesting discussion.
BTW, What is the benefit of allowing static methods in an interface? I couldn't think about any good reason of having static methods in an interface.
Nishant Sivakumar wrote: Operators are implemented via static methods in .NET and thus for operators, name lookup should (in my opinion) be extended to look up all the way to the base interface (if any).
Correct. It is happening currently if base type is a class. As I said, I don't know why they allow static member functions in an interface which is making all these confusion.
Best wishes,
Navaneeth
|
|
|
|
|
Edward Diener wrote: Obviously C# should allow static data, methods, properties, and events in interfaces.
Why do you think allowing static members on an interface is required?Best wishes,
Navaneeth
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
