views:

205

answers:

2

When I try to create a class in managed C++ that inherits from ObservableCollection I get the error: error C2039: 'ObservableCollection' : is not a member of 'System::Collections::ObjectModel'

Here's my code:

using namespace System;
using namespace System::Collections;
using namespace System::Collections::Generic;
using namespace System::Collections::ObjectModel;

public ref class DataMatrix : public System::Collections::ObjectModel::ObservableCollection<array<Object^>^> {};

Why can't I use this class from C++. I have no difficulty using it in C#.

+2  A: 

Did you make sure to add a reference to WindowsBase.dll? ObservableCollection<T> lives in this DLL and it is not included on the default references list for a C++ project.

JaredPar
When I tried this initially, it didn't work. I think I needed to rebuild the project. However, it now works fine, thanks.
jumpalongjim
A: 

I had exactly the same problem; VS2010. I had a reference to WindowsBase.dll but I still got the error. I have a C# project in the same solution that uses ObservableCollection and it compiles fine. I eventually figured out that it was related to the fact that I had set the targeted .NET framework to V3.5 (MMC project and MMC does not yet support .NET 4.0). I had set the C# project to use ".NET V3.5 Client" but the managed C++ project was simply set to ".NET V3.5". It seems that the ObservableCollection definition could be found in the "client" version of the WindowsBase.dll but not in the regular version.

Stating things in a different way, the .csproj file contained the following line but the .vcproj did not.

<TargetFrameworkProfile>Client</TargetFrameworkProfile>

When "Client" is specified the DLL comes from:

C:\Program Files\Reference Assemblies\Microsoft\Framework\.NETFramework\v3.5\Profile\Client

When "Client" is not specified the DLL comes from:

C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.0

Adding the "TargetFrameworkProfile" tag to the .vcproj forced the compiler to use the client version of WindowsBase.dll and then the compile would succeed. I can't explain why, but I'm glad to put this head scratcher behind me.

Paul Mead