whether .Net Core(CoreCLR) supports C++\CLI (clr\oldsyntax) runtime environment ? As far as I know there is no plan to support C++/CLI with .NET Core. If no, what can be the possible solutions to this application work ? You can (should) provide a C API. Mono e. g. supports P/Invoke and .NET Core also supports P/Invoke … Read more
A Windows program always has at least two heaps in which unmanaged memory is allocated. First is the default process heap, used by Windows when it needs to allocate memory on behalf of the program. The second is a heap used by the COM infrastructure to allocate. The .NET P/Invoke marshaller assumes this heap was … Read more
You shouldn’t. An access violation is a serious problem: it is an unexpected attempt to write to (or read from) an invalid memory address. As John already clarified, the unmanaged DLL might already have corrupted the process memory before the access violation has been raised. This can have unpredicted effects on any part of the … Read more
Google quickly found http://www.pinvoker.com (Wayback) (Compatiblity listed as VS2005, 2008, and 2010; it doesn’t seem to have been updated to work with newer versions) Microsoft’s C++/CLI compiler can also do this, if you use /clr:safe and #include the header file, it will generate p/invoke code which you can extract with e.g. ILSpy (free) or Red … Read more
You cannot add a reference to an unmanaged DLL. Instead, you should make a post-build task to copy the file. Alternatively, you can add a link to the unmanaged DLL as a file in the C# project, and set Build Action to None and Copy to Output Directory to Copy If Newer.
Simple way assuming class Foo: Create a C++/CLI project, call this FooWrapper. Make FooWrapper depend on the unmanaged dll (however you normally would). Create a managed class ManagedFoo which contains a single private instance field of type Foo*. provide public wrapping functions in ManagedFoo which forward on to the underlying instance field. Optionally (though recommended): … Read more
It is all the same physical memory. The difference is who is controlling it. The Microsoft definition is that managed memory is cleaned up by a Garbage Collector (GC), i.e. some process that periodically determines what part of the physical memory is in use and what is not. Unmanaged memory is cleaned up by something … Read more
I had a _cdecl c++ dll that I called without any trouble from Visual Studio 2008, and then the identical code in Visual Studio 2010 would not work. I got the same PInvoke … has unbalanced the stack error as well. The solution for me was to specify the calling convention in the DllImport(…) attribute: … Read more
You must always use the Marshal.GetLastWin32Error. The main problem is the garbage collector. If it runs between the call of SetVolumeLabel and the call of GetLastError then you will receive the wrong value, because the GC has surely overwritten the last result. Therefore you always need to specify the SetLastError=true in the DllImport-Attribute: [DllImport(“kernel32.dll”, SetLastError=true)] … Read more
Native code is the code whose memory is not “managed”, as in, memory isn’t freed for you (C++’ delete and C’s free, for instance), no reference counting, no garbage collection. Managed code, you guessed it, is the code whose memory is free and allocated for you, garbage collection and other goodies. Mixed code is when … Read more