Best method for C in C#

[Guest]

So, I am writing an application in C#, and I have some old C code that I want
to use. Now, i tried to convert it to a DLL, and while I easily got it
working, it didn't work like it was supposed to. The problem, is that there
are global structures, with values that change as you write to certain
functions.

To be less vague, the C code is an old FM Chip emulator, so most of the
structures' values have to be stored in memory, as I make calls to change
them. Then I render the sound wave, based on the structure's values, with
another function call. The DLL idea didn't work, because it's making
seperate calls to the functions, and all data used is reset each call.

So, with DLLs out of the question, I'm asking for people's opinions on what
would be the best way to use the code in C#. I was considering converting it
to managed C, and using multiple file assemblies, but I'm unsure if it would
keep the data in memory between calls.

Any ideas are appreciated.

Thanks

 

[Guest]

I was actually thinking of writing the code into an executable and then
calling the functions from there, but again, I have to make multiple writes
to the emulated "ports" and then get a final write of data. I can only put
command line arguments in. I can't really think of a way, perhaps writing it
as a COM?

 

[Lucian Wischik]

The DLL idea didn't work, because it's making
seperate calls to the functions, and all data used is reset each call.

?? DLLs can have data which persists between calls. I don't know what
you observed, but you shouldn't have, and the idea was fine.

 

[Guest]

Really.

Well, my observation showed it didn't work. Is there any particular way to
make sure of that? The data structs were global, and I was defining and
calling the functions via [DLLImport].

Is there perhaps another way to do it with a DLL that I'm not using, or am I
just going to have to find the problem?

 

[Guest]

Well, I discovered that the DLL shouldn't be unloaded by my app. Mine was
being unloaded, which is why the data did not persist. I know how to do
this, and I wasn't.

Now, would I still call the library the same way in C# (using [dllimport])?

 

[Earl]

Why not store the data in datasets or datatables between calls? This seems
like a good scenario for a .Net app.

 

[Ben Voigt]

Well, I discovered that the DLL shouldn't be unloaded by my app. Mine was
being unloaded, which is why the data did not persist. I know how to do
this, and I wasn't.

Now, would I still call the library the same way in C# (using
[dllimport])?

You can use LoadLibrary to lock the DLL in memory, and then call into it
using DllImport.

 

[Lucian Wischik]

Well, I discovered that the DLL shouldn't be unloaded by my app. Mine was
being unloaded, which is why the data did not persist. I know how to do
this, and I wasn't.

Oh. I always thought that in C#, once a DLL is loaded by a
[dllimport], it remains loaded until the application terminates. Is
this incorrect? When does unloading happen?

 

[Willy Denoyette [MVP]]

Well, I discovered that the DLL shouldn't be unloaded by my app. Mine was
being unloaded, which is why the data did not persist. I know how to do
this, and I wasn't.

Oh. I always thought that in C#, once a DLL is loaded by a
[dllimport], it remains loaded until the application terminates. Is
this incorrect? When does unloading happen?

You are quite right in your thinking, you have to explicitly unload a Library
(FreeLibrary(hModule)), the CLR doesn't care about loaded DLL's.

Willy.