Develop Reference

Is it possible for two exe's to access the same object in memory from a DLL?

I have a requirement where two separate applications need to access and modify an object contained in a DLL (all control logic for the application is written in C++ and operates from a DLL). A UI exe (with minimal logic, written in C++) consumes this DLL and interacts with the main control logic DLL. I am looking to add an additional exe (written in C#) to run multiple web based services that would also need to access the same object contained in the DLL.

Yes it's called Shared Memory. The dll needs to call CreateFileMapping to allocate the region of memory to be shared. Then call MapViewOfFile to well.. map the file into memory. Then multiple processes can access this mapped memory through its name.

This is not a question about c++ per se but about how your operating system deals with shared libraries. From my experience in looking at the application loader behavior on Solaris systems, the answer is no. I presume the behavior of Solaris is followed by Windows, Linux, etc. but I suppose there could be an exotic operating system that does just want you ask for (I'm looking at you QNX).
Basically if you create a global variable, let's say:
int foo = 5;
and compile your dll and analyze the content of your dll, you would see foo included in some read/write data section.
Since the section is read/write, when the exe starts and loads the dll, the operating system would create a copy of that section for the exe. Now your exe can change the value to any int it wants, but it only changes its copy of foo.
If you start up another exe, it too will load the dll and it too will get a copy of the section. That exe will have it's own copy of foo and it will initially be set to 5.
Read only sections behave differently so if you were to define foo as follows:
static const int foo = 5;
It would end up in a read only section of the dll and every exe would refer to the same foo in memory. It doesn't allow you to do what you're trying to do but it is nice thing to know as it saves memory. A good rule of thumb is to make everything static and const when possible.

static objects / multiple app domains / one process

Ok here is the problem, I have a winform application that relies heavily on static variables and it being a singleton application (only one instance of the process at a time).
I now need to create a wrapping application that would create say 6 of those winform applications and switch between their primary windows. The reason for doing it this way, is that these applications have a lot of static references that must be updated depending on what database they are connected to. Our users need to connect to several databases now and re-engineering the code to get rid of the static issues is NOT an option.
So my question is this, I know I can create new app domains in one process, but do each of those app domains get a new set of static references? Or do I actually have to have separate processes? If so, how could I go about building an new application that would create 6 instances of the old application and communicate data to each one of them (things like Hide/Show, load this object, query this database, etc...) Looking for something simple as this is going to end up being a throw away project.
Thanks!

Each app domain has its own set of loaded assemblies (except domain-neutral assemblies, which are shared between domain) and types. Each type in the app domain has it's own instances of static variables (in case of domain-neutral assemblies CLR provides this in special way).

Is a static object/variable stored on cache/session in a web application on .NET?

I'm having some trouble recently.
On a WebForm I declare a static object, like this :
public static MyObject myobject=new MyObject();
Response.Write(myobject.Title());
now, if I load another page that doesn't contain the declaration of myobject and I do again
Response.Write(myobject.Title());
I see the previosly result. Is the object stored on session during the navigation due to the static? And it's reckon by the VIEWSTATE? Or what's happening?

No it's stored as a static variable in the process, which can be recycled at any point, assuming you use IIS.
In short, try not to use static variables in this situation.
To expand on what is happening. The static variable is stored in the server's process, which is controlled by IIS. It just so happens that the process is still alive when you call back onto the server. IIS can recycle this process at any time.
Update: OK more accurately it is per AppDomain, which sits in a process - substitute the word process with AppDomain in my previous paragraphs :-)

It's just a static variable. It "lives" alongside the type - so it will be shared by all code accessing the same field via the same type in the same AppDomain. It will be lost on AppDomain recycle, and won't be shared across multiple servers, etc.
Basically it's not a good idea to use static variables in webapps other than occasionally for local caching...

Static objects are shared across users. It is not stored in session which is unique to user or view state which is unique to each page.
Read up on ASP .NET State Management Recommendations to find out which type of state management feature to use for which scenario.

If it helps, I tend to take the view that you can declare two separate objects within one class - the dynamic object definition and the static object. Normally, if you are creating these within the same class definition, there is a connection between them, and they work in tandem ( the singleton patten is a prime example ).
What it means is that the object is created based on the dynamic object. There is still a static object unaffected by the creation of the dynamic object(s). Because this can be confusing, you should not combine the two without being careful and understanding the distinction between them.
I realise that this is not a real understanding of what is happening, but it helps me to keep in my head the distinction. Each type has its own use, and should be used appropriately ( I have seen dynamic classes that should have been static, as well as the other way round ).

Singleton class in DLL used on multiple virtual directories

I have the following situation:
multiple virtual directories under same application pool in IIS
copy of same DLL in all those directories (same version number)
a singleton class in one in this DLL
The question is, is this singleton class created only once for all those Virtual Directory instances or is there for each of these directories a separate singleton class.
The code looks something like this:
[
Transaction(TransactionOption.Supported),
ClassInterface(ClassInterfaceType.AutoDispatch),
Guid("7DE45C4D-19BE-4AA4-A2DA-F4D86E6502A8")
]
public class SomeClass
{
private static readonly Singleton singleton = new Singleton();

A singleton will be created for each application using it. Each application is separated from each other, because they each exist in their own application domain.
To have a truly singleton class across different applications, you'll need to have them communicate to a common application holding the information (like through remoting or WCF etc.).
The application pool controls how much memory and processor(s) applications in that pool can access (along with the account the programs run under). They are still separate from each other.

In IIs each virtual directory has a single application associated with it. An application does not share memory space with other applications so there will be a new instance of this class for each virtual directory.
You can create a shared application pool which all these applications will use. However, in this case the memory will be shared but each will get a unique process using that memory and each unique process will load the class.

Loading an Assembly (DLL) from different locations into the .net CLR (even an identical copy of the same file into the same process (*)) the CLR treats each of these as separate Assemblies ... so the types in these assemblies - whilst syntactically identical (even in namespace terms) - are still different types!
So even if they were in the same application context (OS process) the singleton would not be a single common instance across the callers (you would have three separate static instances of the same class). Also: an Application Context is defined as having a base path (in the ASP.Net case this is the virtual directory) ... further evidence that the web applications all run in separate processes (Kevin is right).
Just a general point (perhaps off the topic of your question) about copying DLLs, though: the Global Assembly Cache (GAC) comes with different challenges ... but the CLR response to "DLL hell" is to treat every different file (identical copy or not) as a separate assembly ... use the GAC - I would strongly advise against copying assemblies into multiple places on a single machine. If nothing else: such file copying is a deployment nightmare. The GAC comes with all sorts of powerful version management utilities to boot (check out: GAC binding policies).
Hoping to help with your long term solution ...
Aidanapword
(*) this can be done using Reflection ... not a good idea but it happens.

First a note - when you run under IIS 6 and 7, AppDomains can be in separate worker processes if you allow IIS to use multiple processes per AppPool. To put it in proper historical context, AppDomain just emulates what IIS AppPool mechanism would do to any binary. Allows for a lot of scalability and in many cases it doesn't really matter if you have a few copies of a "singleton" - that can improve perf as well.
If you really, really, and I mean really :-) have the need for a server-level singleton there is a way to do it, without paying the cost of remoting, but only if you know your COM or WinNT API.
WinNT route will be the lightest resource-wise but you'll have to do complete WinNT work to the point that you'll start asking why are you still in C# and not C++ - shared memory, events or WinNT mutexes etc.
COM route will require you to force out of proc invocation (proper registry keys) and you may want to go with AutoDual instead of AutoDispatch - first to buy perf and second to make sure that .NET has the minimal chance of trerating that dll as "it's own". The gola is to make it look and quack like any other out of proc COM
Important question to ask yourself is - why do I actually need it? Very different tactics needs to be used if the purpose is caching, vs. fast event processing (in which case MSMQ will serve well - it's now under WCF umbrella).

How to handle static variables in a library that is used both for desktop and web?

I have some C# library classes that make use of static variables. I use these library classes both for desktop and web applications. Problem is, as I just discovered, static variables don't go down so well on a web server; the values are shared across all sessions using the web site!
How can I preserve the features of a static variable for use in my desktop apps, while making sure that each session on my web server has its own independent values for these variables - but within the session itself, it still really behaves like a static?

Static variable values are shared across all threads in an application domain. In an ASP.NET application the recommended way to store data that's related only to the current user is the Session.
If you can modify the code of this shared library I would advise you to extract an interface out of these static variables that will provide a mechanism to store values. This will allow each application to provide its own implementation. For a windows application you could use an implementation that internally uses a static variable. For an ASP.NET application you could use the Session. But in all cases you expose only an interface. This will also have the positive side effect of rendering your code easier to unit test.