I am working in VS 2008 C# and need to share an instance of an object created in one project with another project. I tried creating a static class in project1 and adding it as a link to project2, but the information wasn't saved. The static class was written in project1.
//object o = new object
//project1.staticObject = o
//project2.object = project1.staticObject
When I tried something like above, project2.object would be null. By adding a class as a link, is it creating a new instance of the static class in project2 or is it referencing the same class? If it is referencing the same class, shouldn't any information saved into the static class from project1 be accessible by project2? I know this isn't the most elegant manner of sharing data, but if anyone would help with this problem or provide a better manner of doing it, I would greatly appreciate it.
Thanks in advance.
Projects run in separate processes, so they can't share data in this manner. You'll need to persist the data in another type of store. I recommend using a database (hey, 20 gazillion websites, stock trading apps, airlines, etc can't be wrong).
If you don't want to use a database, you could open an IP connection between instances of the app and have a thread send packets of data to sync back and forth between the applications. Or, in your "server" app, add a web service that each process would call to update and retrieve information.
If you need really high-speed communication between the processes, sockets with a peer or star topology is a good way to go. If you're okay with some latency, having a web service (which works fine even if these aren't web apps) or a database could be a good solution. The right approach depends on your application.
WCF could also solve this problem. It effectively wraps the IP/socket layer and provides some nice object persistence/remote control capabilities, but I find it overly complex for most applications.
To share a single instance of an object among different processes (that's what I think you are intending to do) you need something that will maintain that object's state. You can look at the WCF and how to set up it's behaviour to act as a singleton so essentially every requester gets the same instance across the board.
http://msdn.microsoft.com/en-us/magazine/cc163590.aspx
Creating the link creates only applies to the source code. When you compile each project, it then has that single class definition available in both projects. The process you took does nothing for instances during runtime for sharing.
You can look at WCF or .NET Remoting, although .NET Remoting is now officially replaced by WCF.
If you are talking about sharing the same object between two processes, you can do that, the concept is called memory-mapped files. Here is some starter docs from msdn.
Though the docs and API use the term "FileMapping" quite a bit, you can use it just for sharing memory between two processes.
In .NET 4.0, you can use the System.IO.MemoryMappedFiles namespace. For your case, looks like .NET 3.5, you'll have to use some sort of interop to use the Win API.
Related
I'm trying to move a Web project from an IIS hosting to a self hosting structure. I'm using Owin and Web API 2.
It appears that this code:
using (WebApp.Start<Startup>(url))
{
bla...
}
creates a AppDomain (with ID == 1).
Edit: This API is a new interface for accessing data for an already existing software ("only" a few millions lines of code), which means that I can't really do what I want. A "user" is actually more of an "account", which means that I technically can have hundreds of clients connected as the same "user".
End of edit
The problem I'm having is the following: when a client logs in, I create an AppDomain to load its static data. As the same account can have several sessions at the same time (or example the same user connected on his smartphone + computer), I have to make a difference between Session and AppDomain.
So, all my Controllers are called within the AppDomain of the user calling the API, all Services too.
BUT, the Web API 2 seems to add a serialization layer after each Controller. And this serialization layer occurs outside the scope of all the AppDomains I have created manually: it is in the AppDomain with ID == 1.
As the serialization sometimes needs access to the staticdata of the user, I end up having quite frequently serialization errors.
I'm looking for a way to either skip the additional serialization induced by Web API 2 or to compel this serialization to occur within a specific AppDomain.
I haven't found any hint for either ideas in the documentation of the .Net packages I'm using nor in the already asked questions.
Any idea (even a workaround) would be greatly appreciated =)
Thanks for any contribution ;)
The problem really came from a static class (thus defined at an AppDomain level) containing A LOT of information, and used in a few getters of properties throughout the code (I know it's a bad practice, but unfortunately I can't change that right now).
The solution I finally come up with is to kind of serialize everything manually in the created AppDomains, thus solving the problem.
I have seen this in multiple questions, but so many of the accepted answers are contradictory.
Some say that only IPC can be used if you want to use a single instance (actually just a synced instance) of an object across applications and domains.
Others say that using a singleton pattern in an assembly in GAC will result in the data being shared because the GAC will share an instance if the DLL is already loaded by another assembly (providing the lib has a singleton pattern).
Somebody help me out and put this to rest, I need to share a Global object across multiple applications in multiple threads and need to know before I get too far into it if its even possible without IPC such as WCF. I would prefer to use the GAC as my library is more like a framework anyway that will be used by a suite of applications both developed by me and other 3rd party developers. Additionally speed is a major concern and serializing/deserializing an object to constantly sync it would probably add too much latency, would much rather it be a single instance referenced from multiple locations.
No, each instance of an application is using it's own memory for all loaded assemblies. It is even possible to separate two singleton instances within one application (by using AppDomains)
A singleton pattern can be used cross assembly, but this will always be within one AppDomain.
So two application doesn't share memory/object instances.
This is desired behavior, because you don't want other applications to access your Thread/Dispatcher/AppDomain(and load a custom assembly in your application)/Application class instances
If you need to 'share' memory or objects between applications, you'll need to serialize the data and 'transport' them over something like a communication layer.
For example:
TCP/IP
'Shared' memory (named pipes)
Files
I create a lot of object classes when I do programming. There are many situations where same object definition will be reused across multiple projects. In windows, I simply build them into .dll file library and include them as the project reference. Therefore, when I need to add additional properties or methods, I just need to do it once and I don't need to worry about go through all projects and manually update the object class definition.
Now, I'm given a project to build an Android application which requires several object classes that's being used within other projects (and must be synced). Of course, I can manually create them within Android and update them every time whenever there's a change, but this is very dangerous because one day in the future, it is very likely to be out-of-synced.
Anyone have suggestions on how to share class library across C# and Android?
Thank you
The only way I know how to do this is to use Xamarin which would allow you to write your entire Android application in C#.
The problem is Android and .Net use completely different runtimes that are not compatible.
I don't have a clear enough view of what your application does, but if you are using the C# objects on a webAPI and looking to keep your objects synced with the client app, you can use Breeze.js - this keeps your client/server biz objects synced. The classes get pulled in dynamically via a meta service call.
I would like to create a Class Library DLL in C#, that will have a Static Class in it.
That static class has 1 private static member(int), with a public static property for it.
What I want is, that for Every C# Application that references this DLL, it will get the same static class.
Meaning If Application1 changes the static member's value to be 5,
and then Application2 tries to get the value of the propery, it will get: 5.
Despite the fact that those are two different applications(EXEs).
In simply words, I want this whole class library to be "static",
so only once will be loaded of it to memory, and then its single value will be shared accross different EXEs that reference it.
Thank you
An attractive solution to shared data amongst all processes on the same computer is shared memory. You will have to rewrite your properties to retrieve the shared value, and the class will be loaded multiple times into each process that uses your library, but it will behave as though there were only one copy, if you do it correctly.
Here is a StackOverflow question to help you get started:
How to implement shared memory in .NET ?
It links to a complete shared-memory library you can use.
What you're looking for is some form of IPC or RPC. One option is .NET Remoting.
I am Omer, I registered so it looks as if I am a different user.
Regarding what Damien_The_Unbeliever said, allow me all to describe what I generally want to do, so you can direct me towards the best solution for that case.
I have created a nice application.
This application has a GUI.
I want to add another way to operate this application, which will be via exposing an API for it - methods and properties that other applications can use, to operate my application.
And what I plan to do is:
Create a DLL with a static class,
put the core of my application in that class,
and then have the GUI, and potentially all other applications, use that class.
please note that this class will hold not only data that can be stored,
but also references to "live" objects(i.e. open coomunication ports, etc etc),
so storing to disk, and reading from it will not be a good solution here.
I need this 1 static class, to be accessible from all applications that want,
and that all of them will get the same static class.
So, I need this class to be static, and I need the library to be "static".
(no such thing in .NET as "static library", I know. please note that I am not talking about static library like in C++ - there it's something else.. I am talking about a DLL that is created once only, for all applications who use it).
I need to create a project for multiple web services using WCF in c#. The web services will be calling other assemblies to perform the core processing. The assemblies will be accessing data from SQL Server. One of the parameters that will be part of every web service method will include the database to use. My problem is how to pass the database parameter to assemblies to use. I can't change all the signatures for all the satellite assemblies to use. I want to reference some kind of variable that the satellite assembles reference. Theses same satellite assemblies are used with a Windows Forms app and an ASP.NET app so I would need to have something that all types of applications could use. Static fields are not good since for one web service call the database could be "X" and for another it would be "Y". Any ideas?
This is the sort of thing that might play nicely with an IoC or DI framework - having some interface that includes the database information, and have it pushed into all the callers for you. Even without IoC, hiding the implementation in an interface sounds like a solid plan.
With your static concept; a [ThreadStatic] might work but is a little hacky (and you need to be religious about cleaning the data between callers), or another option is to squirrel some information away on the Principal, as this is relatively easily configured from both WCF (per-call) and winforms (typically per-process). In either case, be careful about any thread-switching (async, etc). In particular, note that ASP.NET can change threads in the middle of a single page pipeline.