|
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
|
|
|
|
|
In order to code operators for an interface.
In dotNet all operators must be static methods in order to be CLS compliant.
There is no reason interfaces should not have operators just like classes do. If I have some functionality written in terms of interfaces, why should I not be allowed to use operators, where appropriate, instead of member functions ? Here is a simple, trivial example in C++/CLI:
interface class MultiplyTwoIntegers
{
int Multiply(int);
static int operator * (MultiplyTwoIntegers ^ first, MultiplyTwoIntegers ^ second) { return(first -> Multiply(second));
};
ref class MyInteger : MultiplyTwoIntegers
{
// Some functionality...
int Multiply(int other)
{
// ... some functionality return an int
}
}
int DoTheMultiplyAmongOtherThings(MultiplyTwoIntegers ^ one, MultiplyTwoIntegers ^ two)
{
int result(one * two);
// Some processing ...
return result;
}
// Somewhere else we have this code
MyInteger ^ my1(gcnew MyInteger);
MyInteger ^ my2(gcnew MyInteger);
int result(DoTheMultiplyAmongOtherThings(my1,my2));
As I said this is a trivial example but in real world programming much functionality can be created based on interfaces being passed to functionality and operating on those interfaces. Allowing operators for interfaces makes the syntax much nicer than if they are not allowed. This should be no different from classes. In C++/CLI one can code the above without error, since interface operators are allowed. In C# interface operators are not allowed, nor are any static functions, properties, or events for an interface.Edward Diener
|
|
|
|
|
Edward Diener wrote: There is no reason interfaces should not have operators just like classes do.
I agree if .NET allows operator overloads as non-static methods. Unfortunately, .NET requires operator methods to be static and having static members to be part of an interface doesn't make sense. Because interface methods are used through the instance variable and static members are not accessible through instance variable. This is the reason why .NET uses interfaces like IComparable, IEquatable etc to do operations where a operator overload could have made more sense.
Edward Diener wrote: Here is a simple, trivial example in C++/CLI:
If you don't care about your code to be used by other .NET languages, you can ensure the contract with the help of templates. Something like,
template<typename T>
int multiply(T first, T second)
{
return first * second;
}You can pass in any type that has got proper operator overloaded.
Best wishes,
Navaneeth
|
|
|
|
|
If static methods are not accesible through instance variables why do static operators work for class instances ? Your argument makes no sense because it is apparent that static operators work with class instances, so there is no reason why they should not work with interface variables instantiated from class instances. The fact that they do work with interface variables instantiated with class instances also shows that your argument is wrong BTW. Try it in C++/CLI and you will see that they do work as advertised.
The fact that C# does not allow what C++/CLI does allow does not bother me that much. I only wanted to have C# follow the CLI just as C++/CLI. Arguing that it can not work when clearly it does seems fruitless to me.
Somehow I think you are talking about C++/CLI as if it is just native C++. C++/CLI is a superset of C++ but it is not the same language. As far as using templates, I am very much aware of their capabilities but I am currently writing C++/CLI code to be used by other dotNet languages which means following the CLI standard as much as possible.Edward Diener
|
|
|
|
|
Edward Diener wrote: If static methods are not accesible through instance variables why do static operators work for class instances ?
That is a syntactic sugar. When compiler sees expression int result = first * second where first and second are instance variables of type Foo, it checks that operator overload is available and if it is available, this expression will be rewritten like int result = Foo.op_Multiply(first, second).
If you are interested why operator overloads are static, take a look at what Eric Lippert says[^].
Edward Diener wrote: Try it in C++/CLI and you will see that they do work as advertised.
What do you mean by that?
Edward Diener wrote: Somehow I think you are talking about C++/CLI as if it is just native C++
No. I know the difference quite well.
Best wishes,
Navaneeth
|
|
|
|
|
>> Try it in C++/CLI and you will see that they do work as advertised.
> What do you mean by that?
You can currently create a static operator in C++/CLI for an interface and use it when dealing with the interface. It does not have to be only a static operator for a class to work properly. Whether it is syntactic sugar or not means nothing to me as to whether it works or not. Unlike many people I view syntactic sugar as often very important and justified.Edward Diener
|
|
|
|
|
I want to write an application, that monitors a third party application, by examining the properties and values of those properties associated with that application's controls. For example, if the control is a button, I'd like to get a list of all it's properties and their values (e.g. if the button is enabled or disabled). If the application has a grid or spreadsheet component, I'd like to get the number of columns, rows, the column headers, and the values in the individual cells. I know how to get a window/control's text with GetWindowText, however; I need much more info than that.
Can this be done? The internet searches I have done to date, (and I have searched other forums) have come up short. Can anyone give me advice/pointers or point me to resources to help me?
Thanks!Today's Beautiful Moments are
Tomorrow's Beautiful Memories
|
|
|
|
|
| The only suggestion I can offer is to check the type of control when you get a handle to it, and then use the other Win32 calls to check the different styles and states it is using. This will mean checking all the options for every type of control; a fairly tedious task. txtspeak is the realm of 9 year old children, not developers. Christian Graus
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
