Re: Shared Assembly DLL Help Please! [modified] - C# Discussion Boards

24-Mar-09 0:34

I am trying to build a DLL that returns a number that increments by one each time it is called by any application - in such a way that if app A and app B are calling the DLL one after another you will see it jump by two in app A and app B. This is not like a normal DLL which is local to each app and has no memory in common. For this I think I need a Shared Assembly in the Global Assembly Cache.

Here is my DLL:

namespace willyhoops
{
// not threadsafe
public sealed class Willyhoops
{
private static Willyhoops instance = null;
int i;

private Willyhoops()
{
}

public static Willyhoops Instance
{
get
{
if (instance == null)
{
instance = new Willyhoops();
}
return instance;
}
}

public int TestFunction()
{
return ++i;
}
}
}

The idea here is a singleton so that every call to TestFunction will return a number that goes up no matter from which application it is called.

And I have got this DLL into the global assembley cache.

Here is my Console Application test:

using System;
using System.Collections.Generic;
using System.Text;
using System.Threading;
using willyhoops;

class Program
{
static void Main(string[] args)
{
App a = new App();
}

}

public class App
{
public App()
{
Willyhoops w = null;
w = Willyhoops.Instance;
while (true)
{
int i = w.TestFunction();
Console.WriteLine(i);
Thread.Sleep(1000);
}
}

}

And I went in project, add reference and pointed it at the willhoops.dll in the release directory from before.

But it does not work... Each time I launch a new app it starts again at zero just like a normal DLL that is local to each app...

I am stuck please can someone help!

It may be that I am barking up the wrong tree and this Shared Assembly method can not help.

I looked on the web for a long time and found just this:

Question: How to share memory between CLR calls to the same C# dll?

Answer: Are you doing this in the same app domain? If so, then a static member is all you need. However, if you want to do this in different application domains, then you can't use shared memory from C#. Rather, you would have to create a service (not a literal one, but one instance which other app domains communicate with) which will host the values and return them to the callers.

But that is too vague to be of much use and I have gone down this shared assembly route... Of course I could use a socket or even the registry or any number of hacks but how to do this properly. This is a common task (eg Drivers, ODBC etc) and must be possible in C#...

<div class="ForumMod">modified on Tuesday, March 24, 2009 6:59 AM</div>

Eddy Vluggen24-Mar-09 1:05

Eddy Vluggen

24-Mar-09 1:05

I believe that "shared" just means that multiple applications share the dll, where each application loads the library local to the app.

You could write the last number to a file from the library, and read that when the function gets called Smile | :)

I are troll Smile | :)

moon_stick24-Mar-09 5:51

24-Mar-09 5:51

But a DLL is a library - not an instance - so it doesn't contain variables that can be amended. When app A calls the Increment() method, it creates an instance of that class in its own AppDomain (unless you specify otherwise). App B would do the same. To solve this you'd need to create a separate app / service, app C which app A and app B can remote to.

It definitely isn't definatley

w.hooper24-Mar-09 7:09

24-Mar-09 7:09

Remote how? Via a socket or something - I want it to be ultra fast.

Look here is some blurb from the Windows Open Services Architecture used by ODBC etc. How can I do this stuff in C#?

-----------

The WOSA model consists of three distinct pieces. Each of these pieces plays an important, and independent, role in providing programming services to your applications. The three WOSA components are

The Client API-the application programming interface used by the program requesting the service.

The Server SPI-the service provider interface used by the program that provides the extended service (for example, e-mail, telephony, speech services, and so on).

The API/SPI Interface-the single module that links the API and SPI calls. This is usually implemented as a separate DLL in the Windows environment.

...

Since a key design aspect of WOSA is the isolation of the client API and the server SPI, a single interface between the two components is required. This single interface is usually implemented as a Windows dynamic link library (DLL) that allows programs to link to existing services at run-time instead of at compile time....

...

Please don't tell me like the last guy who posted here that i should write to a file and then poll it from the server thread etc. This is a common task how is it done properly in C#?

moon_stick24-Mar-09 7:23

Re: Shared Assembly DLL Help Please! [modified]

24-Mar-09 7:23

Obviously there's a number of different solutions you could use. For example, you could have a shared database containing a table with a single column which contains a single value (the value you're tracking). If the database exposes a stored procedure to increment the value (using a transaction of course) and returns the newly updated value, the database transation will take care of the concurrency issue automatically for you. If you've not got a database in your application this would more than likely be overkill.

Sockets would probably be the quickest way to go - a quick google[^] should get you started. I'd also thoroughly recommend getting hold of a decent .NET book - 'Pro C#' by Andrew Troelsen is an excellent reference.

Good luck!

It definitely isn't definatley

w.hooper24-Mar-09 7:30

24-Mar-09 7:30

No I need it very fast I already said that - far far faster than sockets. I want to have a windows service running, working in the background, and I want various clients to be able to call into that service using a DLL that returns in under one microsecond.

I only need access from C# and want to know how to do this interprocess communication.

Does anyone know how to do this properly? Maybe each client can load the DLL into the AppDomain used by my server for example and thus end up with a common instance in a common app domain...

modified on Tuesday, March 24, 2009 3:22 PM

moon_stick24-Mar-09 7:41

Re: Shared Assembly DLL Help Please! [modified]

24-Mar-09 7:41

You never even looked at any of the links, did you?! In .NET, assemblies aren't hosted directly within a process (unlike win32 apps which are). Instead, they're hosted by a partition in a process called an AppDomain. One AppDomain can't access data of any kind (global or static fields) from another AppDomain without using remoting (or resorting to using pinvoke and doing some win32 programming). Maybe you should go and do some research about the topic yourself?

Have you even done any tests to figure out how quick a solution using sockets or a database would be? Didn't think so...

It definitely isn't definatley

modified on Tuesday, March 24, 2009 1:54 PM

w.hooper24-Mar-09 8:05

24-Mar-09 8:05

Now you getting annoyed but it serves no purpose. Here is an article for example:

http://www.dolittle.com/blogs/einar/archive/2007/05/18/cross-appdomain-singleton.aspx[^]

(looks good but i can't figure it out)

here is another:

http://www.codeproject.com/KB/dotnet/XDMessaging.aspx?fid=385377&df=90&mpp=25&noise=3&sort=Position&view=Quick&select=2058982[^]

(uses the windows message que to pass messages but this is async and too slow for me)

these look pretty out there.. but in the normal world pipes or shared memory are better ways of interprocess communication compared to sockets and databases. but i am really trying to find someone who know it very well who can help me understand the possibilities

modified on Tuesday, March 24, 2009 2:35 PM

moon_stick24-Mar-09 22:35

Re: Shared Assembly DLL Help Please! [modified]

24-Mar-09 22:35

I've had a look at the code in the first link you sent - it's not particularly complicated (though I'd still recommend you do some research on AppDomains) but still relies on the scenario I described in my first email where you would need a third app ('app C') which would need to be running (this is the AppDomain you would be searching for).

However, you've still not given any reasoning or scenario behind why you need to do it this way. What sort of load are you expecting? Is this a shared counter for multiple applications on a single box? What makes you think that the other solutions described are too slow for what you need (have you done any benchmarking yourself?).

If you try and give some more detail you might get something more useful in response.

It definitely isn't definatley

w.hooper24-Mar-09 23:21

24-Mar-09 23:21

I think I have said several time that I will have a windows service running which i want to client to talk to. There are no other computers involved, no security issues etc. All I want is the fatest possible performance. The article looks to be doing that but it's very complicated. Another good article is:

http://www.codeproject.com/KB/threads/fast_ipc.aspx?fid=322183&df=90&mpp=25&noise=3&sort=Position&view=Quick&select=2314676[^]

From that article:

IPC (Inter Process Communication) has been covered by many other articles, so there is no real need for 'another' IPC article to show how to implement IPC. However, there was a severe lack of information of how to implement a fast IPC class. This is the purpose of this article.

Due to the availability of information already out there on IPC implementation, I will not dive too deeply on the inner workings of how to implement IPC, but will concentrate on how to make them very fast.

There are several ways to implement an IPC, here are just a few:

Shared memory
Named Pipe
TCP
MSMQ (Microsoft Queue Solution)
File Mapping
Mailslots

With so many choices, how is one to know the fastest? The answer is simple, there is no ideal fastest solution to the problem. Each has its advantages and disadvantages, but one most definitely stands out above the others....... Shared Memory.

---------------

I am just after someone to point me in the right direction. It's pretty obvious what I want... ideally a single instance of the DLL shared by all applications from clients to server... maybe this shared memory example is basically the same thing...

modified on Wednesday, March 25, 2009 6:16 AM

moon_stick24-Mar-09 23:33